Une base de données relationnelle est une base qui range les données dans des tables à deux dimensions, faites de lignes et de colonnes, reliées entre elles par des identifiants communs et interrogées par un langage de requête normalisé.
Le modèle a été formalisé par Edgar F. Codd dans l’article « A Relational Model of Data for Large Shared Data Banks », publié en 1970 dans la revue Communications of the ACM. L’adjectif « relationnel » ne désigne pas les liens entre tables. Il vient de la notion mathématique de relation : chaque table est une relation, dont chaque ligne décrit un élément et chaque colonne un attribut. Codd visait l’indépendance des données : l’utilisateur décrit ce qu’il cherche sans connaître la façon dont les données sont rangées physiquement.
Trois éléments structurent une base relationnelle. La clé primaire identifie chaque ligne de façon unique, par exemple le numéro client. La clé étrangère reprend dans une table la clé primaire d’une autre table : la table des commandes contient le numéro du client qui a commandé. La normalisation répartit les informations pour qu’un même fait ne soit stocké qu’une fois : l’adresse du client figure dans la table des clients, pas dans chaque commande. Les requêtes s’écrivent en SQL, langage normalisé par la série de normes ISO/IEC 9075.
La base relationnelle se distingue des bases dites non relationnelles, qui stockent des documents, des paires clé-valeur ou des graphes sans schéma de tables imposé. Elle se distingue aussi du datawarehouse, qui repose souvent sur la même technologie mais sert l’analyse de l’historique plutôt que l’enregistrement des opérations courantes. En marketing, ce modèle sous-tend notamment les outils de gestion de la relation client, de facturation et de commerce en ligne.
On présente souvent la base relationnelle comme un sujet d’informaticien. C’est une erreur de lecture. Le schéma des tables fixe ce que l’entreprise pourra mesurer pendant des années. Décider qu’un client est une personne, un foyer ou un compte d’entreprise change le calcul de la valeur à vie du client, du taux de réachat et de toute segmentation. Nous recommandons que le marketing valide ces définitions avant le développement, et non après la mise en production.
Une base relationnelle peut être techniquement saine et inexploitable. Nous proposons quatre repères de pilotage, qui ne sont pas des normes :
Ces mesures relèvent du data quality management et gagnent à être suivies chaque mois.
Le modèle relationnel reste à notre avis la référence pour les données transactionnelles : clients, commandes, contrats, factures. Il devient contraignant pour des volumes massifs d’événements de navigation, des contenus à structure variable ou des données brutes conservées avant tout usage. Un data lake ou une base orientée documents répond alors mieux. Rien n’oblige à choisir : les deux modèles peuvent coexister dans un même système d’information.
Pour votre projet CRM, Advalians formalise le besoin avec vos équipes, vous aide à choisir les prestataires sur des critères explicites, tient le budget et mesure l’usage.
Advalians, cabinet de conseil indépendant en marketing et communication, vous aide à clarifier vos choix et à décider.
La base relationnelle de production enregistre les opérations courantes, alors que l’entrepôt de données sert l’analyse. La première est optimisée pour écrire et modifier vite des enregistrements : une commande, un changement d’adresse. Le second reçoit des copies de plusieurs bases, conserve l’historique et facilite les calculs sur de longues périodes.
Un datawarehouse utilise souvent lui aussi des tables relationnelles. Critère pratique : si vos analyses ralentissent l’outil de vente ou exigent de croiser plusieurs sources, il est temps de les déporter vers un entrepôt.
Partez des questions que le marketing doit pouvoir poser, puis déduisez-en les tables. Une structure minimale comprend une table des clients, une table des commandes, une table des lignes de commande et une table des produits. Ajoutez une table des interactions (courriels, appels, visites en magasin) reliée au client par sa clé.
Fixez un identifiant client unique, attribué par le système. Placez les nomenclatures dans des tables de référence. Vérifiez enfin que la structure permet de calculer une segmentation RFM sans retraitement manuel.
Mesurez la qualité des contenus, pas seulement le bon fonctionnement technique. Suivez quatre indicateurs : le taux de doublons dans la table des clients, le taux de remplissage des champs de ciblage, le nombre d’enregistrements orphelins et la part des valeurs hors des listes de référence.
Établissez une mesure initiale, fixez un seuil d’alerte pour chaque indicateur, puis comparez chaque mois. Une hausse soudaine des doublons signale souvent un nouveau point de saisie ou une importation mal contrôlée : remontez à la source avant de lancer un nettoyage de fichier.
La plus coûteuse est de stocker la même information à plusieurs endroits. Les copies finissent par diverger et personne ne sait laquelle est juste. La deuxième consiste à prendre comme identifiant une donnée qui change, comme l’adresse électronique.
Évitez aussi les colonnes numérotées pour des éléments répétés et la saisie libre dans les champs servant à segmenter. Avant toute mise en production, faites relire le schéma par un utilisateur métier : il repère les définitions ambiguës qu’un développeur ne voit pas.
Choisissez une base relationnelle lorsque les données ont une structure stable et que leur cohérence est critique : clients, commandes, contrats. Préférez une base non relationnelle pour des volumes massifs d’événements, des contenus à structure variable ou un stockage brut en attente d’usage.
Posez trois questions avant de trancher. La structure des données changera-t-elle souvent ? Une erreur de cohérence aurait-elle un coût financier ou juridique ? Les équipes savent-elles interroger le modèle choisi ? Rien n’empêche de combiner les deux dans un même système.
Modèles, grilles et guides prêts à l’emploi pour vos projets marketing et communication.
