Occurrence de table_objet éditorial

SPIP modélise les Objets éditoriaux en entités, en accord avec le modèle Merise , et utilise des tables de liens directionnels pour implémenter les relations à enregistrer entre les diverses occurrences de ces entités.
Cette modélisation des données est explicitée dans un article dédié à SPIP 3.

SPIP 3 propose une structure générique pour cette pratique, qui permet donc de systématiser les fonctions de gestions de ces liens, comme expliqué en API editer_liens.

Les informations suivantes vont aborder une réflexion à mener pour organiser des informations avant leur enregistrement, que ce soit sur papier, dans un tableur ou dans une base de données informatiques gérée par SQL ou votre CMS préféré :-).

 Quelques points-clés

 entité : quand on cherche à enregistrer des informations (stocker leur(s) valeur(s) textuelle(s) ou numérique(s) dans un champ), on cherche généralement à regrouper les informations autour d’un objet ou individu identifié, et identifiable par une clé unique, comme un lieu, une automobile, un individu et son unique "numéro de sécu" (n°SS).

Si on prend par exemple un humain, il se caractérise par un lieu et date de naissance, un domicile, un poids et une taille (à quel age ?), souvent un conjoint ou pas (ou plusieurs, successifs ou non), son lieu de travail (mais si on veut garder la succession de ses boulots cela ferait beaucoup), et un nombre possiblement très variable d’enfants (qui sont eux-mêmes des humains)....
Cet exemple montre toute la variété des associations d’informations autour de l’individu identifié, à distinguer selon :
 leur type : correspondant à l’ensemble des valeurs acceptables, qui peut être

• simple : numérique (age, poids), texte (nom, lieu),
• structuré : date (trois nombres pour jour/mois/année), téléphone (indicatif national+nombre de chiffres fixé), automobile(marque, modèle, motorisation, couleur...), coordonnées géographiques, adresses (normalisées...),

 leurs liaisons avec d’autres individus :

• réflexive : lien avec un individu du meme type (mariage, enfant-parent-fratrie),
• orientée ou symétrique : est mère de ou est conjoint(e) de...

 leur nombre de valeurs :

• pour de simples valeurs (pouvant être multiples), on aura une information mono-valuée (exprimée par une seule valeur que l’on pourra mettre dans un champ) ou multi-valuée (qui ne pourra être traité si simplement : exemple d’une palette de couleurs changeante, du genre avec les transsexuels),
• on parle souvent de cardinalité de la liaison,
  ainsi des conjoints ou des enfants, des résidences, téléphones ou automobiles..

 Les questions à se poser

Par exemple, imaginons que vous vouliez rajouter un rendez-vous ou un Champ Extra à un auteur...
 Pour chaque information que vous voulez étudier, posez-vous d’abord la question de la clé d’identification unique, si elle existe : comment savoir l’individualiser ? Quelle clé choisir ?
Posez-vous aussi la question du type ou domaine de valeurs que vous allez gérer : par exemple un nombre entier ne pourra pas compter les enfants à partir de zéro=aucun, mais pas une température (qui peut être négative et/ou avec décimales).
 L’autre question à prendre en compte, c’est la cardinalité de la liaison avec l’individu !
Dans le cas de notre rendez-vous, est-il unique ou multiple... comme le conjoint ou l’âge (donnée datée) ! Doit-on conserver ses diverses réalisations dans le temps ?
Selon les réponses à ces questions, vous aurez deux paradigmes :

• champ dépendant : dans l’enregistrement de l’individu (la couleur d’une rubrique),
• champ lié : dans une autre table (les adresses ou jobs d’une personne) sous hiérarchie,
• valeurs de champs multiples : passer par une table de liaison (les auteurs des articles)
  Et un cas particulier pour la relation réflexive (lien avec un même type d’individu : vos petits enfants sont des humains comme vous, et vous avez des parents humains comme eux) :
• cette liaison est-elle directe ou multi-valuée (un enfant n’a-t-il qu’un père et une mère, ou bien deux parents, sans même parler de genre)
• cette relation est-elle orientée (lien de filiation) ou symétrique (le lien du mariage ;-))
  • dans le premier cas, il s’agit d’une hiérarchie et vous pouvez garder le lien dans le parent unique (c’est le cas de la hiérarchie des rubriques), donc ajouter le champ extra dans la table décrivant l’individu entité de rattachement
  • dans le cas de relation symétrique (comme aussi dans le cas de relation à cardinalité n-m), vous devrez utiliser une table annexe (ces deux approches sont mises en évidence dans les deux plugins Organiser ses contacts avec C&O et Ajouter des coordonnées multiples - C&O suite, à l’origine de ce complément d’explications).
  • vous pourrez même vous interroger pour "typer" cette relation par un "rôle",...

Mais ces deux dernières problématique n’ont pas actuellement de solutions faciles par SPIP, sauf à compléter ou détourner certains plugins...