Partie 7: Définir les relations entre les informations

Partie 7: Définir les relations entre les informations


Aperçu de l’article

Notions clés

La définition des relations est souvent un point qui peut vous causer des ennuis lors de la construction de vos futures requêtes de récupération de l’information. C’est pourquoi il est important de comprendre les problématiques à ce niveau et d’adapter votre architecture pour la rendre flexible aux changements futurs.

Cardinalités 1 :1, 1 : N et N : N
Colonnes de recherche
Colonnes de taxonomie
Ensembles de documents

 


Quelles sont les relations entre ces informations?

Dans l’étape précédente, nous avons abordé les relations d’héritage qui permettent de préciser un type particulier définissant ainsi la hiérarchie d’informations.
Une fois cette hiérarchie des informations complétée, il faut définir les relations qui les lient, en particulier des cardinalités. Ici, pas de miracle, l’UML, MERISE ou toute autre modélisation entité-relation peuvent fortement vous aider à mener ce genre de réflexion.

Rappel sur les cardinalités

Les relations qui nous intéressent particulièrement dans un système SharePoint sont les suivantes :

  • L’héritage : Dans quelle mesure un type hérite des propriétés d’un autre (étape précédente).
  • L’association : Dans quelle mesure un type est lié aux informations provenant d’un autre.

Avec les cardinalités possibles suivantes :

Type

Cardinalité minimum

Cardinalité maximum

Exemple

Un à Un

0

1

(0 :1) ou (1 :1)

Un à plusieurs

0

N

(1 : N) ou (0 : N)

Plusieurs à plusieurs

N

N

(N : N)

 Note : Une cardinalité possède toujours un minimum et un maximum. Cela déterminera par si vos champs seront optionnels ou obligatoires dans SharePoint.

En regardant le schéma existant, voici les relations identifiées :

  • Projet
    • Un projet possède au minimum 0 et au maximum N documents
    • Un projet fait intervenir au minium 1 et au maximum N membres de projet
  • Document de projet
    • Un document de projet est attaché au minimum et maximum à 1 projet
  • Membre de projet
    • Un membre de projet peut intervenir au minium dans 0 et au maximum N projets

Ce qui donne le schéma suivant :

Traduction du besoin "Rechercher un projet" en types de contenu

Gestion des relations dans SharePoint

Pour gérer maintenant des relations de type un à plusieurs ou même plusieurs à plusieurs dans SharePoint, il existe plusieurs possibilités (les mêmes pour SharePoint 2010 ou 2013 soit dit en passant) :

  • La colonne de type recherche
  • Les métadonnées gérées
  • Les ensembles de documents
  • Les dossiers

La colonne de type recherche

La colonne de type « Recherche » (ou Lookup Field en anglais) est une colonne permettant de lier un élément de liste à un autre et ainsi d’obtenir une relation 1:N ou N : N si on choisit l’option valeurs multiples.

Il est important de souligner que les colonnes de type « Recherche » comportent des avantages, mais aussi des  inconvénients, qu’il est important de connaître avant toute implémentation de par leur impact sur la conception de l’application:

  • Créer un lien fort entre deux listes
  • Permet de gérer des relations 1 : 1, 1 : N et N : N.
  • Création et modèles de requêtes assez simples (voir Le langage de requête structurée)
  • Permet une gestion des suppressions des éléments de la relation à la manière d’une base de données relationnelle. Il est possible de spécifier si la relation est de type « Suppression en cascade » (si un élément cible de la colonne est supprimé alors les éléments sources associés le sont aussi) ou « Suppression restreinte » (les éléments source ne sont pas supprimés).
  • Pas de relations entre types mais entre listes physiques. Rien ne garantit que la relation soit cohérente d’un point de vue fonctionnel. Cela oblige généralement à créer une liste ou une bibliothèque associée à un type particulier.
  • Il n’est pas possible de faire nativement des colonnes de recherche filtrées avec une condition sur une liste cible (sauf avec SharePoint Designer). Par exemple pour filtrer sur un type de contenu particulier.
  • La colonne de recherche est une simple liste déroulante montrant tous les éléments de la liste cible (conséquence directe du point précédent). Imaginez une liste avec 500 éléments, l’expérience utilisateur risque d’être fortement amoindrie lors de la sélection des valeurs depuis un formulaire.
  • La portée d’une colonne de recherche n’excède pas la collection de sites ce qui impose que les types concernés par les relations soient implémentés dans des listes ou bibliothèques à l’intérieur (ce qui vous impose un choix architectural dès le départ).

Les métadonnées gérées

Les métadonnées gérées apparues avec SharePoint 2010 permettent également de créer des liens entre les éléments même si cela est quelque chose que l’on rencontre (très) peu souvent.

/* Mode SharePoint Outlaw ON */

SPCowboy

/* Mode SharePoint Outlaw OFF*/

  • Possibilité de créer des relations au-delà de la collection de sites
  • Permet de gérer des relations 1 : 1, 1 : N et N : N.
  • Adapté au langage de requête de recherche
  • Problème connus de requête avec le modèle de langage structuré de type CAML
  • Pas de lien fort entre les types.
  • Pas de gestion des suppressions.
  • Difficile à maintenir si nous avons beaucoup de valeurs. Nécessite de créer un terme pour chaque élément de la bibliothèque ou de la liste.

Les ensembles de documents

Les ensembles de documents sont une nouveauté apparue avec SharePoint 2010. Ils permettent de regrouper de l’information physiquement, agissant comme un « super dossier » ou même comme un classeur physique.

L’avantage ou l’inconvénient (au choix) de ce genre de solution est qu’elle permet de combiner la visualisation des relations en plus du stockage.

  • Propose par défaut une visualisation intégrée et personnalisable des relations entre les éléments.
  • Permet de propager des métadonnées dans les différents documents contenus.
  • Agit comme agrégateur des relations indirectes pour les éléments contenus (exemple plus bas).
  • Gère les relations de type 1:N, le « 1 » étant le conteneur (l’ensemble de document) et le « N », les documents contenus.
  • « Recherchable » et manipulable unitairement, au même titre qu’un document.
  • Ne gère que des types de contenu de documents.
  • Vous impose de centraliser tous les types de documents dans la même bibliothèque de stockage.
  • Un seul niveau d’arborescence (oubliez la création de sous dossiers).
  • Difficulté à sortir du cadre de l’ensemble de document pour la visualisation des relations entre les informations = Couplage fort entre la visualisation et le stockage.
  • Approche de type système de fichiers classique (ouvre possiblement la porte à une gestion par dossiers classique).
  • Impossible de créer des vues personnalisées uniquement pour le contenu de l’ensemble de documents

 A noter que les ensembles de documents sont activables au niveau de la collection de sites pour pouvoir être utilisés.

Les dossiers

Le dernier moyen dans SharePoint et celui à éviter le plus possible : les dossiers.

En utilisant ce principe, vous obtenez certes, une gestion des relations, mais vous vous privez grandement des possibilités de SharePoint. Si vous êtes amenés à utiliser des répertoires pour classer vos données, vous raisonnez toujours en termes de système de fichiers classique et SharePoint n’est peut-être pas le bon outil pour vous.

 Je le répète souvent : SharePoint n’est pas un système de fichiers en ligne!

Si vous souhaitez construire des applications fiables et optimales, raisonnez en termes de métadonnées et non en termes d’emplacement de stockage (dossiers).

Note: Il existe toutefois des situations où l’utilisation des dossiers est pertinente. Cependant, ce que je souligne ici est qu’ils ne devraient JAMAIS être utilisés pour matérialiser des relations entre informations.

  • La voie de la simplicité
  • Possibilité d’appliquer des permissions unitairement par dossier
  • Peu maintenable
  • Pas de lien concret entre les éléments. Si un élément est sorti du dossier, la relation est brisée.

Exemples d’implémentation de relations

Soit la relation suivante (un projet possède un ou plusieurs documents):

 

Exemple de relation 1:N

 Avec une colonne de recherche

Avec une colonne de type recherche, cette relation sera implémentée de la manière suivante dans SharePoint:

Principe de la colonne de recherche pour une relation 1:N

 

 Avec les métadonnées gérées

En utilisant les métadonnées gérées, le lien se fait en réalité sur la base des métadonnées de la banque de termes (qui peut être aussi bien au niveau des applications que de la collection de sites seulement). Il suffit simplement de créer un connecteur sur l’entité à lier puis de sélectionner le bon terme pour les deux types par l’intermédiaire d’une colonne de métadonnée gérée.

Principe de la correspondance de métadonnées gérées 1:N

 

 Avec un ensemble de documents

En utilisant un ensemble de documents, on se retrouve dans la situation d’un dossier « classique » contenant les éléments liés:

Gestion des relations 1:N avec un ensemble de documents

Ceux-ci se retrouvent dans la même bibliothèque que l’élément parent.

Agrégateur de relations indirectes

Je parlais tout à l’heure de la capacité d’un ensemble de documents à agir en tant qu’agrégateur de relation indirecte:

Ajoutons à l’exemple une autre entité avec la cardinalité suivante:

Principe de l'agrégation indirecte de relations

Avec cette modélisation, si je souhaite par exemple récupérer les documents pour un client spécifique, ceux-ci ne ressortiront pas car ils ne possèdent aucune métadonnée contenant cette information. En revanche avec un ensemble de document et le mécanisme d’héritage de métadonnées, il m’est maintenant possible de réaliser cette requête directement pour faire ressortir les documents car la propriété a été « partagée » par le type parent:

Recherche par un lien indirect

Soit la relation suivante (un projet possède un ou plusieurs membres et un membre peut appartenir à plusieurs projets):

Exemple de relation N:N

 Avec une colonne de type recherche

La gestion des relations multiples peut s’implémenter de deux manières différentes dans SharePoint. Premièrement, si l’on en suit une modélisation de type MERISE, voici ce qui est préconisé pour ce genre de relations :

Si le type de relation est n:m, alors les attributs de l’association deviennent des attributs de la table de jointure.

En d’autres termes, une table intermédiaire apparait avec des attributs supplémentaires (si c’est le cas) caractérisant la relation. Sous SharePoint, cette table s’implémente sous forme de liste ou bibliothèque selon le cas.

En appliquant la règle ci-dessus, on obtient une nouvelle liste dite de jointure:

Principe de la colonne de recherche pour une relation N:N

Cependant, il est également possible de modéliser cette relation avec une seule colonne de recherche mais à valeurs multiples:

Colonne de recherche multiple

A choisir, préférez la première solution avec table de jointure qui ne garde que des liaisons simples. Cette approche est plus facile à maintenir et à requêter et permet d’ajouter des caractéristiques à la relation (pratique pour une éventuelle évolution, d’autant plus qu’on ne modifie pas les entités de base).

De même, pour avoir été confronté à ce problème. La colonne de recherche à valeurs multiples pose problème avec le modèle objet client de SharePoint 2010.

 Astuce : Il peut être intéressant de définir un type de contenu particulier représentant la relation entre les entités sur votre liste de jointure.

Entitié issue de la relation

 

 Avec les métadonnées gérées

La relation fonctionne de  la même façon que pour une liaison 1 : N. Il suffit de spécifier la colonne du type cible comme étant multiple:

Principe de la correspondance de métadonnées gérées N:N


+ There are no comments

Add yours