Continuons dans notre série d’articles sur la modélisation Cassandra (lire Factures et commandes et Recherche multicritère). Avant de pouvoir passer une commande et plus encore de produire une facture, votre client va devoir lister les articles qu’il souhaite acheter. Pour cela, l’application propose généralement d’utiliser un panier, liste remplie au fur et à mesure par l’utilisateur. C’est de cet objet particulier et important que nous allons parler aujourd’hui.
Panier
Les paniers ne se limitent pas aux sites marchands. On les retrouve dans la plupart des applications où les utilisateurs sont conduits à faire une sélection de plusieurs éléments, sur lesquels ils effectuent une opération en masse par la suite. Ce peut être une liste d’articles qui seront achetés en fin de navigation. Dans un logiciel de facturation, ce pourrait être une sélection de factures sur lesquelles on veut envoyer une relance. On peut aussi penser aux listes de préférences ou aux listes de souhaits.
Dans sa forme classique, un panier est donc une liste qui est remplie progressivement par ajout et retrait d’éléments. Souvent, le contenu sera exploité par une action qui provoquera son vidage.
Les éléments d’un panier ne sont pas classés. Il est fréquent que l’affichage classe les éléments, éventuellement triés par catégorie. Le classement et le tri sont des règles d’affichage qui sont réalisées par le tiers de présentation.
Par ailleurs, un panier doit pouvoir être manipulé de façon concurrente. On imagine souvent une personne seule devant son ordinateur en train de sélectionner deux livres, l’un après l’autre, puis de les commander. Mais ce n’est pas le seul cas d’usage. Vous rencontrerez aussi le cas d’un couple qui effectue ses courses en ligne chacun avec son ordinateur connecté sur le même compte. Madame réduit le nombre de packs de bières à un, parce que cinq c’est trop. Pendant ce temps, Monsieur en rajoute, parce qu’il en faut au moins trois pour la soirée foot de vendredi soir avec les copains. Les deux appuyant simultanément l’un sur le bouton [+], l’autre sur le bouton [-]. À partir du moment où l’on travaille sur le web, il faut partir du principe que les requêtes vont s’exécuter en parallèle.
Modèle fonctionnel
Le modèle fonctionnel du panier est donc simple : c’est un sac, c’est-à-dire un ensemble qui peut contenir plusieurs fois le même élément. Le nombre de répétitions de l’élément étant conservé. Pour traiter le cas général, nos paniers seront nommés pour être distingués entre eux.
Le modèle conceptuel est donc le suivant :
Modèle logique
Avec une base relationnelle, le modèle de base se décline très simplement par l’utilisation de deux tables : l’une représente l’entité panier et l’autre la jointure N-N entre les entités Panier et Produit. La modélisation de l’entité Produit ne sera pas traitée ici. On simplifiera le propos en considérant qu’il est représenté par une table unique.
On obtient le schéma suivant :
Modèle naïf
Prenons le cas de Dave Lopernahif. Il connait bien les bases de données relationnelles avec lesquelles il travaille régulièrement. Il utilise Cassandra depuis peu de temps, mais pense en avoir compris le fonctionnement. D’ailleurs, le modèle n’est-il pas proche ? Cassandra stocke les données dans des tables et CQL ressemble à s’y méprendre à SQL. Bien sûr, il faut s’adapter aux spécificités de la base et à l’absence de jointure. C’est pourquoi Dave sait qu’il doit stocker toutes les informations concernant le panier et sa jointure avec les produits dans une seule table. Heureusement, il a déjà lu un excellent article sur la modélisation Java où une relation de composition 1-N était modélisée grâce au mécanisme de partition. Ici, la relation n’est pas une relation de composition, les lignes ne représenteront pas l’entité Produit, mais le lien vers l’entité.
En suivant ce principe, Dave modélise sa table ainsi :
- La clé de partition est l’identifiant du panier.
- Le nom du panier est contenu dans une colonne statique (attribut de la partition).
- L’identifiant du produit est utilisé comme l’unique colonne de clustering.
- La quantité est une colonne normale.
- Le libellé du produit et son prix peuvent être dénormalisés sous la forme de colonnes normales.
Modélisation naïve
