Eerst de gebruikersinterface: als gebruiker haat om een product te zoeken in een catalogus die is georganiseerd in een strikt hiërarchische manier. Ik herinner me nooit in welke sub-sub-sub-sub...-categorie een "exotisch" product zich bevindt en dit dwingt me tijd te verspillen aan het verkennen van "veelbelovende" categorieën om te ontdekken dat het is gecategoriseerd in een (voor mij tenminste ) vreemde manier.
Wat Kevin Peno suggereert is een goed advies en staat bekend als gefacetteerd browsen . Als Marcia Bates schreef in Na de Dot-Bomb :Deze keer goed ophalen van webinformatie , " .. facetclassificatie is tot hiërarchische classificatie zoals relationele databases zijn tot hiërarchische databases. .. ".
In wezen stelt gefacetteerd zoeken gebruikers in staat om uw catalogus te doorzoeken vanaf elk "facet" dat ze verkiezen en laat ze informatie filteren door andere facetten te kiezen tijdens het zoeken. Merk op dat, in tegenstelling tot hoe tagsystemen gewoonlijk worden bedacht, niets u ervan weerhoudt sommige van deze facetten hiërarchisch te organiseren.
Om snel te begrijpen wat faceted search inhoudt, zijn er enkele demo's te verkennen op The Flamenco Search Interface Project - Search Interfaces that Flow .
Ten tweede, de toepassingslogica: wat Manitra
voorstelt is ook een goed advies (zoals ik het begrijp), d.w.z. het scheiden van nodes en links van een boom/grafiek in verschillende relaties. Wat hij "vooroudertabel" noemt (wat echter een veel betere intuïtieve naam is) staat bekend als transitieve afsluiting van een gerichte acyclische graaf (DAG)
(bereikbaarheidsrelatie). Naast de prestaties vereenvoudigt het zoekopdrachten enorm, zoals Manitra al zei.
Maar Ik stel voor een weergave voor een dergelijke "vooroudertabel" (transitieve afsluiting), zodat updates in realtime en incrementeel zijn, niet periodiek door een batchtaak. Er is SQL-code (maar ik denk dat deze een beetje moet worden aangepast aan specifieke DBMS'en) in artikelen die ik noemde in mijn antwoord op zoektaal voor grafiekensets:vraag over gegevensmodellering . Kijk vooral naar Transitieve afsluiting van grafieken behouden in SQL (.ps - naschrift).
Product-Categorieën relatie
Het eerste punt van Manitra verdient ook de aandacht.
Wat hij zegt is dat er tussen producten en categorieën een veel-op-veel relatie bestaat. Dat wil zeggen:elk product kan in een of meer categorieën zitten en in elke categorie kunnen er nul of meer producten zijn.
Gegeven relatievariabelen (relvars) Producten en Categorieën kan een dergelijke relatie worden weergegeven, bijvoorbeeld als een relvar-pc met ten minste de attributen P# en C#, d.w.z. product- en categorienummers (identifiers) in een refererende-sleutelrelatie met bijbehorende Producten en Categorieën nummers.
Dit is een aanvulling op het beheer van de hiërarchieën van categorieën. Dit is natuurlijk maar een ontwerpschets.
Over gefacetteerd browsen in SQL
Een handig concept om "facetten browsen" te implementeren is relationele divisie , of zelfs relationele vergelijkingen (zie onderaan de gelinkte pagina). D.w.z. door PC (Product-Categorieën) te delen door een (groeiende) lijst van categorieën gekozen uit een gebruiker (facetnavigatie) verkrijgt men alleen producten in dergelijke categorieën (natuurlijk worden categorieën verondersteld niet ze sluiten elkaar allemaal uit, anders krijg je door het kiezen van twee categorieën nul producten).
Op SQL gebaseerde DBMS hebben deze operators meestal niet (verdeling en vergelijkingen), dus ik geef hieronder enkele interessante artikelen die ze implementeren / bespreken:
- OVER HET BEGRIP MAKEN VAN RELATIONELE DIVISIE (.pdf van FIE 2003-sessie-index );
- Een eenvoudigere (en betere) SQL-benadering van relationele verdeling (.pdf van Journal of Information Systems Education - Contents Volume 13, Number 2 (2002) );
- Veelvoorkomende zoekopdrachten voor itemset-detectie verwerken per divisie en operators voor join-insluiting instellen ;
- Wetten voor het herschrijven van query's met divisieoperators ;
- Algoritmen en toepassingen voor universele kwantificering in relationele databases;
- Zoekopdrachten optimaliseren met universele kwantificering in objectgeoriënteerde en Object-relationele databases ;
- (ACM-toegang vereist) Over de complexiteit van deling en set-joins in de relationele algebra ;
- (ACM-toegang vereist) Snelle algoritmen voor universele kwantificering in grote databases;
enzovoort...
Ik zal hier niet in details treden, maar de interactie tussen hiërarchieën van categorieën en browsen op facetten vereist speciale aandacht.
Een uitweiding over "vlakheid"
Ik heb even gekeken naar het artikel dat is gelinkt door Pras , Hiërarchische gegevens beheren in MySQL , maar ik stopte met lezen na deze paar regels in de inleiding:
Om te begrijpen waarom deze nadruk op vlakheid van relaties gewoon onzin is , stel je een kubus voor in een driedimensionaal Cartesiaans coördinatensysteem :het wordt geïdentificeerd door 8 coördinaten (drietallen), zeg P1(x1,y1,z1), P2(x2,y2,z2), ..., P8(x8, y8, z8) [hier houden we ons niet mee bezig beperkingen op deze coördinaten zodat ze echt een kubus vertegenwoordigen].
Nu zullen we deze set coördinaten (punten) in een relatievariabele plaatsen en we zullen deze variabele de naam Points geven. . We zullen vertegenwoordigen de relatiewaarde van Points als een tabel hieronder:
Points| x | y | z |
=======+====+====+====+
| x1 | y1 | z1 |
+----+----+----+
| x2 | y2 | z2 |
+----+----+----+
| .. | .. | .. |
| .. | .. | .. |
+----+----+----+
| x8 | y8 | z8 |
+----+----+----+
Wordt deze kubus 'afgeplat' door hem louter in tabelvorm weer te geven? Is een relatie (waarde) hetzelfde als de representatie in tabelvorm?
Een relatievariabele neemt als waarden sets van punten in een n-dimensionale discrete ruimte aan, waarbij n het aantal relatieattributen ("kolommen") is. Wat betekent het voor een n-dimensionale discrete ruimte om "plat" te zijn? Gewoon onzin, zoals ik hierboven schreef.
Begrijp me niet verkeerd, het is zeker waar dat SQL een slecht ontworpen taal is en dat op SQL gebaseerde DBMS'en vol eigenaardigheden en tekortkomingen zijn (NULL's, redundantie, ...), vooral de slechte, de DBMS-als- dumb-store type (geen referentiële beperkingen, geen integriteitsbeperkingen, ...). Maar dat heeft niets te maken met relationele datamodel gefantaseerde beperkingen, integendeel:ze keren zich er meer van af en erger is de uitkomst.
In het bijzonder vormt het relationele datamodel, als je het eenmaal begrijpt, geen probleem bij het weergeven van welke structuur dan ook, zelfs hiërarchieën en grafieken, zoals ik heb beschreven met verwijzingen naar hierboven genoemde gepubliceerde artikelen. Zelfs SQL kan, als je de tekortkomingen verdoezelt, iets beters missen.
Op het "Het geneste set-model"
Ik heb de rest van dat artikel doorgenomen en ik ben niet bijzonder onder de indruk van zo'n logisch ontwerp:het suggereert om twee verschillende entiteiten, knooppunten te verwarren en links , in één relatie en dit zal waarschijnlijk onhandigheid veroorzaken. Maar ik ben niet geneigd om dat ontwerp grondiger te analyseren, sorry.
BEWERKEN: Stephan Eggermont maakte in onderstaande opmerkingen bezwaar dat " Het platte lijstmodel een probleem is. Het is een abstractie van de implementatie die prestatie moeilijk te bereiken maakt. ... ".
Nu, mijn punt is precies dat:
- dit "platte lijstmodel" is een fantasie :alleen omdat men relaties opmaakt (representeert) als tabellen ("platte lijsten") betekent niet dat relaties "platte lijsten" zijn (een "object" en zijn representaties zijn niet hetzelfde);
- een logische representatie (relatie) en fysieke opslagdetails (horizontale of verticale decomposities, compressie, indexen (hashes, b+tree, r-tree, ...), clustering, partitionering, etc.) zijn verschillend; een van de punten van een relationeel datamodel (RDM ) is om logisch los te koppelen van "fysiek" model (met voordelen voor zowel gebruikers als uitvoerders van DBMS'en);
- prestaties zijn een direct gevolg van fysieke opslagdetails (implementatie) en niet van logische representatie (Eggermonts opmerking is een klassiek voorbeeld van logisch-fysische verwarring ).
Het RDM-model beperkt op geen enkele manier implementaties; men is vrij om tupels en relaties naar eigen inzicht te implementeren. Relaties zijn niet noodzakelijk bestanden en tuples zijn niet noodzakelijk aantekeningen van een bestand. Dergelijke correspondentie is een domme direct-image-implementatie .
Helaas op SQL gebaseerde DBMS-implementaties zijn , te vaak, domme direct-image-implementaties en ze lijden onder slechte prestaties in verschillende scenario's - OLAP /ETL producten bestaan om deze tekortkomingen te dekken.
Dit is langzaam aan het veranderen. Er zijn commerciële en gratis software/open source-implementaties die deze fundamentele valkuil eindelijk vermijden:
- Vertica , een commerciële opvolger van..
- C-Store:een kolomgeoriënteerde DBMS ;
- MonetDB ;
- LucidDB ;
- Kdb op een bepaalde manier;
- en ga zo maar door...
Het punt is natuurlijk niet dat er een "optimaal" fysiek opslagontwerp moet bestaan, maar dat welk fysiek opslagontwerp dan ook kan worden geabstraheerd door een mooie declaratieve taal gebaseerd op relationele algebra/calculi (en SQL is een slechte voorbeeld) of meer direct op een logische programmeertaal (zoals Prolog, bijvoorbeeld - zie mijn antwoord op "prolog naar SQL-converter " vraag). Een goed DBMS moet het fysieke opslagontwerp on-the-fly wijzigen, gebaseerd op gegevenstoegangsstatistieken (en/of gebruikershints).
Tot slot, in Eggermont's commentaar de uitspraak "Het relationele model wordt tussen de cloud en prevayler geperst. " is weer een onzin, maar ik kan hier geen weerwoord geven, deze opmerking is al te lang.