Primero, la interfaz de usuario: como usuario odio para buscar un producto en un catálogo organizado en un estrictamente jerárquico camino. Nunca recuerdo en qué sub-sub-sub-sub...-categoría se encuentra un producto "exótico" y esto me obliga a perder el tiempo explorando categorías "prometedoras" solo para descubrir que está categorizado en (para mí, al menos ) manera extraña.
Qué Kevin Peno sugiere es un buen consejo y se conoce como navegación por facetas . Como Marcia Bates escribió en Después del Dot-Bomb :Obtener la recuperación de información web correcta esta vez , " ... la clasificación por facetas es a la clasificación jerárquica lo que las bases de datos relacionales son a las bases de datos jerárquicas. .. ".
En esencia, la búsqueda por facetas permite a los usuarios buscar en su catálogo a partir de cualquier "faceta" que prefieran y les permite filtrar la información eligiendo otras facetas a lo largo de la búsqueda. Tenga en cuenta que, al contrario de cómo se suelen concebir los sistemas de etiquetas, nada le impide organizar algunas de estas facetas jerárquicamente.
Para entender rápidamente de qué se trata la búsqueda por facetas, hay algunas demostraciones para explorar en Proyecto Flamenco Search Interface - Search Interfaces that Flow .
Segundo, la lógica de la aplicación: qué Manitra
propone también es un buen consejo (según lo entiendo), es decir, separar nodes y links de un árbol/grafo en diferentes relaciones. Lo que él llama "tabla de antepasados" (que, sin embargo, es un nombre intuitivo mucho mejor) se conoce como cierre transitivo de un gráfico acíclico dirigido (DAG)
(relación de accesibilidad). Más allá del rendimiento, simplifica enormemente las consultas, como dijo Manitra.
Pero Sugiero una ver para dicha "tabla antepasada" (cierre transitivo), de modo que las actualizaciones sean en tiempo real e incrementales, no periódicas por un trabajo por lotes. Hay código SQL (pero creo que debe adaptarse un poco a DBMS específicos) en los documentos que mencioné en mi respuesta a lenguaje de consulta para conjuntos de gráficos:pregunta de modelado de datos . En particular, mire Mantener el cierre transitivo de gráficos en SQL (.ps - posdata).
Relación Productos-Categorías
También vale la pena enfatizar el primer punto de Manitra.
Lo que está diciendo es que entre productos y categorías hay una relación de muchos a muchos. Es decir:cada producto puede estar en una o más categorías y en cada categoría puede haber cero o más productos.
Dadas las variables de relación (varrel) Productos y Categorías, dicha relación puede representarse, por ejemplo, como un PC varrel con al menos los atributos P# y C#, es decir, números de producto y categoría (identificadores) en una relación de clave externa con los Productos y Categorías correspondientes números.
Esto es complementario a la gestión de jerarquías de categorías. Por supuesto, esto es solo un boceto de diseño.
Sobre la navegación por facetas en SQL
Un concepto útil para implementar la "navegación por facetas" es división relacional , o, incluso, comparaciones relacionales (ver la parte inferior de la página vinculada). Es decir. al dividir PC (Productos-Categorías) por una lista (creciente) de categorías elegidas de un usuario (navegación por facetas), se obtienen solo productos en dichas categorías (por supuesto, se presume que las categorías no todas mutuamente excluyentes, de lo contrario, al elegir dos categorías, una obtendrá cero productos).
Los DBMS basados en SQL generalmente carecen de estos operadores (división y comparación), por lo que a continuación presento algunos artículos interesantes que los implementan/discuten:
- SOBRE HACER COMPRENSIBLE LA DIVISIÓN RELACIONAL (.pdf de Índice de sesiones de la FIE 2003 );
- Un enfoque SQL más simple (y mejor) para la división relacional (.pdf de Journal of Information Systems Education - Contents Volume 13, Number 2 (2002) );
- Procesamiento de consultas frecuentes de detección de conjuntos de elementos por división y operadores de combinación de contención de conjuntos ;
- Leyes para reescribir consultas que contienen operadores de división ;
- Algoritmos y aplicaciones para cuantificación universal en bases de datos relacionales;
- Optimización de consultas con cuantificación universal en orientación a objetos y Bases de datos relacionales de objetos ;
- (Se requiere acceso a ACM) Sobre la complejidad de la división y las uniones de conjuntos en el relacional álgebra ;
- (Se requiere acceso a ACM) Algoritmos rápidos para la cuantificación universal en grandes bases de datos;
y así sucesivamente...
No entraré en detalles aquí, pero la interacción entre las jerarquías de categorías y la navegación por facetas necesita un cuidado especial.
Una digresión sobre la "planitud"
Miré brevemente el artículo vinculado por Pras , Administración de datos jerárquicos en MySQL , pero dejé de leer después de estas pocas líneas en la introducción:
Para entender por qué esta insistencia en la planitud de las relaciones es simplemente una tontería , imagina un cubo en un sistema de coordenadas cartesianas tridimensional :será identificado por 8 coordenadas (tripletes), digamos P1(x1,y1,z1), P2(x2,y2,z2), ..., P8(x8, y8, z8) [aquí no nos preocupa restricciones en estas coordenadas para que representen realmente un cubo].
Ahora, pondremos este conjunto de coordenadas (puntos) en una variable de relación y llamaremos a esta variable Points . Nosotros representaremos el valor de la relación de Points como una tabla a continuación:
Points| x | y | z |
=======+====+====+====+
| x1 | y1 | z1 |
+----+----+----+
| x2 | y2 | z2 |
+----+----+----+
| .. | .. | .. |
| .. | .. | .. |
+----+----+----+
| x8 | y8 | z8 |
+----+----+----+
¿Este cubo está siendo "aplanado" por el mero hecho de representarlo de forma tabular? ¿Es una relación (valor) lo mismo que su representación tabular?
Una variable de relación asume como valores conjuntos de puntos en un espacio discreto n-dimensional, donde n es el número de atributos de relación ("columnas"). ¿Qué significa, para un espacio discreto n-dimensional, ser "plano"? Simplemente tonterías, como escribí anteriormente.
No me malinterpreten, ciertamente es cierto que SQL es un lenguaje mal diseñado y que los DBMS basados en SQL están llenos de idiosincrasias y deficiencias (NULL, redundancia, ...), especialmente los malos, los DBMS-as- tipo de almacenamiento tonto (sin restricciones referenciales, sin restricciones de integridad, ...). Pero eso no tiene nada que ver con las limitaciones fantasiosas del modelo de datos relacionales, al contrario:más le dan la espalda y peor es el resultado.
En particular, el modelo de datos relacionales, una vez que lo comprende, no presenta ningún problema para representar cualquier estructura, incluso jerarquías y gráficos, como detallé con las referencias a los artículos publicados mencionados anteriormente. Incluso SQL puede, si pasa por alto sus deficiencias, perderse algo mejor.
Sobre el "Modelo de conjuntos anidados"
Leí el resto de ese artículo y no estoy particularmente impresionado por un diseño tan lógico:sugiere mezclar dos entidades diferentes, nodos y enlaces , en una relación y esto probablemente causará incomodidad. Pero no me inclino a analizar ese diseño más a fondo, lo siento.
EDITAR: Stephan Eggermont objetó, en los comentarios a continuación, que " El modelo de lista plana es un problema. Es una abstracción de la implementación que hace que el rendimiento sea difícil de lograr. ... ".
Ahora, mi punto es, precisamente, que:
- este "modelo de lista plana" es una fantasía :solo porque uno presenta (representa) las relaciones como tablas ("listas planas") no significa que las relaciones sean "listas planas" (un "objeto" y sus representaciones no son lo mismo);
- una representación lógica (relación) y detalles de almacenamiento físico (descomposiciones horizontales o verticales, compresión, índices (hashes, b+tree, r-tree, ...), agrupamiento, partición, etc.) son distintos; uno de los puntos del modelo de datos relacionales (RDM ) es desacoplar el modelo lógico del "físico" (con ventajas tanto para los usuarios como para los implementadores de DBMSes);
- el rendimiento es una consecuencia directa de los detalles de almacenamiento físico (implementación) y no de representación lógica (el comentario de Eggermont es un ejemplo clásico de confusión lógico-física ).
El modelo RDM no restringe las implementaciones de ninguna manera; uno es libre de implementar tuplas y relaciones como mejor le parezca. Las relaciones son no necesariamente los archivos y las tuplas son no necesariamente registros de un archivo. Tal correspondencia es una tonta implementación de imagen directa .
Desafortunadamente, las implementaciones de DBMS basadas en SQL son , con demasiada frecuencia, implementaciones tontas de imagen directa y sufren un bajo rendimiento en una variedad de escenarios:OLAP /ETL existen productos para cubrir estas deficiencias.
Esto está cambiando lentamente. Existen implementaciones comerciales y de código abierto/software gratuito que finalmente evitan este escollo fundamental:
- Vertica , que es un sucesor comercial de..
- C-Store:un DBMS orientado a columnas ;
- MonetDB ;
- LucidDB ;
- Kdb en cierto modo;
- y así sucesivamente...
Por supuesto, el punto es no que debe existir un diseño de almacenamiento físico "óptimo", pero que cualquier diseño de almacenamiento físico puede abstraerse mediante un agradable lenguaje declarativo basado en álgebra/cálculo relacional (y SQL es un malo ejemplo) o más directamente en un lenguaje de programación lógico (como Prolog, por ejemplo; vea mi respuesta a "convertidor prólogo a SQL " pregunta). Un buen DBMS debe cambiar el diseño de almacenamiento físico sobre la marcha, en función de las estadísticas de acceso a los datos (y/o las sugerencias del usuario).
Finalmente, en el comentario de Eggermont, la afirmación " El modelo relacional se está comprimiendo entre la nube y el predominio. " es otra tontería, pero no puedo dar una refutación aquí, este comentario ya es demasiado largo.
