Structure des données de l'application

Votre application Kentika vous est proposée avec un profil de base de données. Cependant, il arrive que l'on ait besoin de compléter les informations qui vont être gérées, ou encore de compléter son paramétrage afin de prendre en charge une nouvelle application.

Afin de mener à bien ces interventions sur la structure des données, il convient de bien prendre connaissance du modèle relationnel et de respecter un certain nombre de règles.

Les tables (ou fichiers) de la base de données

Les "entités" de base

Kentika comporte trois grandes familles de fiches (ou enregistrements) qui vont permettre de décrire ce que vous voulez gérer : les objets (ou documents), les personnes physiques (ou auteurs) et les sociétés (ou références). Chacune de ces familles va ensuite pouvoir se redécomposer. Exemple : les documents sont répartis en livres, photos, articles, DVD...

Règle 1

- Identifiez les types d'information que vous allez devoir gérer dans votre base de données en respectant les grandes familles (ie : évitez de déclarer un "éditeur" dans la table des "auteurs").

- Limitez le nombre de types, vous pouvez créer des rubriques complémentaires pour affiner l'information (exemple : au lieu de créer les 2 types "Editeur scientifique" et "Editeur littérature générale", on préférera "Editeur" puis une rubrique complémentaire "Domaine").

Le thesaurus

Le thesaurus est une structure arborescente de descripteurs (ou mots clés) qui vont être utilisés pour qualifier vos informations.

Règle 2

- Evitez de détourner le thesaurus et de l'utiliser à la place d'une autre table pour sa structure hiérarchique, les tables indiquées ci-dessus permettent de créer également des relations entre les entités.

Exemple : une société et des filiales. La place naturelle se situe dans la table des références.

Les utilisateurs

Les personnes autorisées à s'identifier au sein de l'application sont gérées dans la table (ou fichier) "Personnes". Ces dernières peuvent recevoir des autorisations leur permettant d'effectuer des saisies dans la base de données ou encore d'utiliser certains outils.

La table des utilisateurs peut cependant être également utilisée pour qualifier certaines informations des tables ci-dessus.

Exemple : "le commentaire sur une fiche a été saisi par Mr X."

Gérer une bibliothèque

Les fonctions de gestion d'une bibliothèque prennent en charge l'aspect opérationnel de ce qui incombe à une telle organisation, à savoir : la gestion des emprunts, des abonnements et des achats. Tout cet ensemble est prêt à l'emploi et ne nécessite pas d'analyse de données particulière.

Les rubriques

Les tables correspondant aux entités de base (documents, auteurs, références) ainsi que les tables personnes et revues (si votre application les gère) sont proposées avec des rubriques préfinies que vous allez pouvoir compléter. Si une rubrique pré-définie existe, évitez d'en créer une nouvelle à la place car l'accès aux données sera toujours plus rapide avec ces rubriques qu'avec les rubriques complémentaires.

Règle 3

La création et la suppression de rubrique est simple. Cependant, dans une base déjà bien remplie, cela peut nécessiter de passer en revue toutes vos fiches pour les compléter ou les adapter. N'hésitez pas à faire des simulations avec des données caractéristiques de ce que vous voulez gérer afin de valider le modèle de données que vous mettez en place.

Propriétés des rubriques

Nature

Les rubriques peuvent être de neuf natures différentes.

Code : les valeurs que peut recevoir la rubrique sont vérifiées par rapport à une liste de valeurs possibles.

Exemple : langue du document, valeurs possibles : FR pour français, EN pour anglais...

Valeur thesaurus : seuls les descripteurs appartenant au thesaurus peuvent être utilisés.

Exemple : zone géographique, ce qui permet de retrouver ce qui concerne une ville à partir d'une recherche sur une région.

Valeur format libre : peut recevoir des valeurs de longueur illimité (exemple : un résumé). L'autocomplétion peut être proposé pour des facilités de saisie.

Date : peut être précise (exemple : 25 juin 2008) ou bien floue (exemple : 1958-1960)

Exemple : date de publication, période concernée...

Nombre : ne peut recevoir que des valeurs numériques.

Exemple : nombre d'employés.

Adresse email : permet d'envoyer un email en utilisant l'adresse indiquée.

Exemple : adresse email du service commercial.

URL : permet de recevoir une URL, possibilité de contrôle de sa validité et d'archivage de la page correspondante.

Exemple : URL de la société, archivage et surveillance de sa page d'accueil.

Lien : permet d'établir un lien avec la même table ou une autre table.

Exemple : appartient à -> lien sur la table des personnes ; est une filiale / a pour filiale -> lien entre deux sociétés.

Adresse : permet d'envoyer un courrier en utilisant l'adresse indiquée.

Ce type de rubrique a été maintenu pour des raisons de compatibilité. En effet, les communications s'effectuant quasi-exclusivement par voie électronique, une adresse postale bien structurée ne présente plus d'intérêt.

Attributs

Les attributs d'une rubriques sont : Valeur multiple vs valeur unique.

Obligatoire : la saisie d'une fiche ne peut être validée si la rubrique est laissée vide.

Clé de dédoublonnage : lors de la saisie d'une nouvelle fiche, permet de vérifier si l'information existe déjà dans la base de données.

Indexé : permet d'effectuer des recherches sur le contenu de la rubrique.

Intégrer aux alertes si modifications : si la valeur de la rubrique a été modifiée alors que la fiche existait déjà dans la base de données, permet à la fiche d'être à nouveau identifiée comme une nouveauté.

Inscrire les modifications au log : permet de garder trace de toute modification (ancienne valeur, date et auteur de la modification).

D'autres attributs, propres à chaque nature d'information peuvent être affectés (voir la saisie des rubriques).

Vous pouvez masquer certaines rubriques à certains utilisateurs en utilisant les autorisations.

Rubriques groupées

Il arrive que l'on ait besoin de gérer des groupes d'informations répétables.

Exemple 1

Pour chaque auteur, vous voulez connaître ses domaines de compétences avec, pour chacun de ces domaines, le niveau. Les domaines de compétence devant être des mots clés du thesaurus.

Domaine : rubrique de type valeur thesaurus

-> Niveau : rubrique de type nombre

Exemple 2

Vous voulez suivre le parcours professionnel de personnes. Pour chaque expérience, vous avez besoin de gérér :

Entreprise : rubrique lien sur la table référence

-> Poste occupé : rubrique de type valeur thesaurus

-> Date de début : rubrique de type date

-> Date de fin : rubrique de type date

-> Commentaire : rubrique de type texte

Ces deux exemples seront traités par l'utilisation de données groupées.

Rubriques codées interdépendantes

Les rubriques autorisées pour une rubrique de type code peuvent être liées à la valeur saisie dans une autre rubrique.

Exemple

Dans une base comportant des données sur des automobiles, vous pouvez créer une rubrique "marque" puis une rubrique "modèle" et ne proposer, lors de la saisie que les modèles de la marque sélectionnée.

Des rubriques... qui n'en sont pas

Si vous avez besoin d'afficher des informations (dans une maquette, dans une liste...) que vous pouvez déterminer à partir d'informations de la base de données, vous pouvez créer un script (ou une fonction) affecté à "Explorateur-Rubrique". Le résultat de l'exécution de la fonction pourra alors être utilisé comme n'importe quelle autre rubrique d'une fiche.

Exemples

Voici quelques exemples de rubriques qu'il peut être intéressant de calculer :

• - Nombre de pièces archivées attachées à une fiche ;
• - Date de dernière modification ;
• - Nombre de consultations au cours des 7 derniers jours.