In primo luogo, l'interfaccia utente: come utente odio per cercare un prodotto in un catalogo organizzato in modo rigorosamente gerarchico strada. Non ricordo mai in quale sub-sub-sub-sub-categoria si trova un prodotto "esotico" e questo mi costringe a perdere tempo ad esplorare categorie "promettenti" solo per scoprire che è classificato in una (per me, almeno ) modo strano.
Cosa Kevin Peno suggerisce è un buon consiglio ed è noto come esplorazione sfaccettata . Come Marcia Bates scritto in Dopo la Dot-Bomb :Ottenere correttamente il recupero delle informazioni Web questa volta , " .. la classificazione a faccette sta alla classificazione gerarchica come i database relazionali stanno ai database gerarchici. .. ".
In sostanza, la ricerca per sfaccettature consente agli utenti di cercare nel tuo catalogo partendo da qualsiasi "sfaccettatura" preferiscano e di filtrare le informazioni scegliendo altre sfaccettature lungo la ricerca. Nota che, contrariamente a come vengono generalmente concepiti i sistemi di tag, nulla ti impedisce di organizzare gerarchicamente alcuni di questi aspetti.
Per capire rapidamente di cosa tratta la ricerca per sfaccettature, ci sono alcune demo da esplorare su The Flamenco Search Interface Project - Cerca interfacce che scorrono .
In secondo luogo, la logica dell'applicazione: cosa Manitra
propone è anche un buon consiglio (a quanto ho capito), ovvero separare i nodes e links di un albero/grafico in diverse relazioni. Quello che chiama "tabella degli antenati" (che è un nome molto più intuitivo, tuttavia) è noto come chiusura transitiva di un grafo aciclico diretto (DAG)
(relazione di raggiungibilità). Oltre alle prestazioni, semplifica notevolmente le query, come ha affermato Manitra.
Ma Suggerisco una vista per tale "tabella predecessore" (chiusura transitiva), in modo che gli aggiornamenti siano in tempo reale e incrementali, non periodici da un lavoro batch. C'è codice SQL (ma penso che debba essere adattato un po' a DBMS specifici) nei documenti che ho menzionato nella mia risposta a linguaggio di query per i set di grafici:domanda sulla modellazione dei dati . In particolare, guarda Mantenimento della chiusura transitiva dei grafici in SQL (.ps - poscritto).
Rapporto tra prodotti e categorie
Vale la pena sottolineare anche il primo punto di Manitra.
Quello che sta dicendo è che tra prodotti e categorie c'è una relazione molti-a-molti. Es.:ogni prodotto può essere in una o più categorie e in ogni categoria possono esserci zero o più prodotti.
Date le variabili di relazione (relvars) Prodotti e Categorie tale relazione può essere rappresentata, ad esempio, come un relvar PC con almeno attributi P# e C#, ovvero numeri di prodotto e categoria (identificatori) in una relazione di chiave esterna con Prodotti e Categorie corrispondenti numeri.
Ciò è complementare alla gestione delle gerarchie delle categorie. Naturalmente, questo è solo uno schizzo di progettazione.
Sull'esplorazione sfaccettata in SQL
Un concetto utile per implementare la "navigazione sfaccettata" è divisione relazionale o, anche, confronti relazionali (vedi in fondo alla pagina collegata). Cioè. dividendo PC (Prodotti-Categorie) per un elenco (crescente) di categorie scelte da un utente (navigazione tramite facet) si ottengono solo prodotti in tali categorie (ovviamente, le categorie si presume non tutte mutuamente esclusive, altrimenti scegliendo due categorie una otterrà zero prodotti).
I DBMS basati su SQL di solito mancano di questi operatori (divisione e confronti), quindi fornisco di seguito alcuni documenti interessanti che li implementano/discutono:
- SUL RENDERE COMPRENSIBILE LA DIVISIONE RELAZIONALE (.pdf da Fie 2003 Session Index );
- Un approccio SQL più semplice (e migliore) alla divisione relazionale (.pdf dal Journal of Information Systems Education - Contents Volume 13, Number 2 (2002) );
- Elaborazione delle frequenti query di rilevamento di set di elementi per divisione e set di contenimento si uniscono agli operatori ;
- Leggi per la riscrittura di query contenenti operatori di divisione ;
- Algoritmi e applicazioni per la quantificazione universale nei database relazionali;
- Ottimizzazione delle query con quantificazione universale in oggetti orientati e Database relazionali a oggetti ;
- (Richiesto l'accesso ad ACM) Sulla complessità della divisione e degli insiemi nella relazione algebra ;
- (Accesso ACM richiesto) Algoritmi veloci per la quantificazione universale in database di grandi dimensioni;
e così via...
Non entrerò nei dettagli qui, ma l'interazione tra le gerarchie di categorie e la navigazione dei facet richiede un'attenzione particolare.
Una digressione sulla "piattezza"
Ho esaminato brevemente l'articolo collegato da Pras , Gestione dei dati gerarchici in MySQL , ma ho smesso di leggere dopo queste poche righe nell'introduzione:
Per capire perché questa insistenza sulla piattezza delle relazioni è solo una sciocchezza , immagina un cubo in un sistema di coordinate cartesiane tridimensionale :sarà identificato da 8 coordinate (triplette), diciamo P1(x1,y1,z1), P2(x2,y2,z2), ..., P8(x8, y8, z8) [qui non ci occupiamo di vincoli su queste coordinate in modo che rappresentino realmente un cubo].
Ora metteremo questo insieme di coordinate (punti) in una variabile di relazione e chiameremo questa variabile Points . rappresenteremo il valore di relazione di Points come tabella qui sotto:
Points| x | y | z |
=======+====+====+====+
| x1 | y1 | z1 |
+----+----+----+
| x2 | y2 | z2 |
+----+----+----+
| .. | .. | .. |
| .. | .. | .. |
+----+----+----+
| x8 | y8 | z8 |
+----+----+----+
Questo cubo viene "appiattito" per il semplice atto di rappresentarlo in modo tabulare? Una relazione (valore) è la stessa cosa della sua rappresentazione tabulare?
Una variabile di relazione assume come valori insiemi di punti in uno spazio discreto n-dimensionale, dove n è il numero di attributi di relazione ("colonne"). Cosa significa, per uno spazio discreto n-dimensionale, essere "piatto"? Solo sciocchezze, come ho scritto sopra.
Non fraintendetemi, è certamente vero che SQL è un linguaggio mal progettato e che i DBMS basati su SQL sono pieni di idiosincrasie e carenze (NULL, ridondanza, ...), specialmente quelli cattivi, i DBMS-as- tipo dumb-store (nessun vincolo referenziale, nessun vincolo di integrità, ...). Ma questo non ha nulla a che fare con le limitazioni immaginate dal modello di dati relazionali, anzi:più se ne allontanano e peggio è il risultato.
In particolare, il modello dei dati relazionali, una volta compreso, non pone problemi nel rappresentare qualsiasi struttura, anche gerarchie e grafici, come ho spiegato in dettaglio con i riferimenti agli articoli pubblicati sopra menzionati. Anche SQL può, se sorvoli sulle sue carenze, perdersi qualcosa di meglio.
Sul "Modello del set annidato"
Ho passato in rassegna il resto di quell'articolo e non sono particolarmente colpito da tale disegno logico:suggerisce di confondere due diverse entità, nodi e link , in una relazione e questo probabilmente causerà imbarazzo. Ma non sono propenso ad analizzare quel design in modo più approfondito, mi dispiace.
MODIFICA: Stephan Eggermont ha obiettato, nei commenti sottostanti, che " Il modello flat list è un problema. È un'astrazione dell'implementazione che rende le prestazioni difficili da raggiungere. ... ".
Ora, il mio punto è, precisamente, che:
- questo "modello flat list" è una fantasia :solo perché si dispongono (rappresenta) relazioni come tabelle ("liste piatte") non significa che le relazioni siano "liste piatte" (un "oggetto" e le sue rappresentazioni non sono la stessa cosa);
- una rappresentazione logica (relazione) e dettagli di archiviazione fisica (scomposizioni orizzontali o verticali, compressione, indici (hash, b+tree, r-tree, ...), clustering, partizionamento, ecc.) sono distinti; uno dei punti del modello di dati relazionali (RDM ) consiste nel disaccoppiare il modello logico dal modello "fisico" (con vantaggi sia per gli utenti che per gli implementatori di DBMS);
- Le prestazioni sono una conseguenza diretta dei dettagli dell'archiviazione fisica (implementazione) e non di rappresentazione logica (il commento di Eggermont è un classico esempio di confusione logico-fisica ).
Il modello RDM non vincola in alcun modo le implementazioni; uno è libero di implementare tuple e relazioni come meglio crede. Le relazioni non sono necessariamente file e tuple non necessariamente record di un file. Tale corrispondenza è una stupida implementazione dell'immagine diretta .
Sfortunatamente, le implementazioni DBMS basate su SQL sono , troppo spesso, implementazioni di immagini dirette stupide e subiscono scarse prestazioni in una varietà di scenari - OLAP /ETL esistono prodotti per coprire queste carenze.
Questo sta lentamente cambiando. Esistono implementazioni software/open source commerciali e gratuite che finalmente evitano questa fondamentale trappola:
- Vertica , che è un successore commerciale di..
- C-Store:un DBMS orientato alle colonne ;
- MonetDB ;
- LucidDB ;
- Kdb in un certo senso;
- e così via...
Naturalmente, il punto è non che deve esistere un progetto di archiviazione fisica "ottimale", ma che qualsiasi progetto di archiviazione fisica può essere astratto da un bel linguaggio dichiarativo basato su algebra/calcoli relazionali (e SQL è un cattivo esempio) o più direttamente su un linguaggio di programmazione logica (come Prolog, ad esempio - vedi la mia risposta a "prologo al convertitore SQL " domanda). Un buon DBMS dovrebbe essere modificare al volo il design dell'archiviazione fisica, in base alle statistiche di accesso ai dati (e/o ai suggerimenti degli utenti).
Infine, nel commento di Eggermont l'affermazione " Il modello relazionale si sta schiacciando tra il cloud e il prevayler. " è un'altra sciocchezza ma qui non posso dare una confutazione, questo commento è già troppo lungo.
