Si vous aviez manqué la première partie, elle est disponible ici : https://infobioco.com/biologiste-formuler-un-cahier-des-charges-partie1/
Nous nous étions attardés sur les principaux éléments à prendre en compte dans la rédaction de ce dernier, avec notamment un focus sur la partie des fonctionnalités. Nous allons dans cette deuxième partie attaquer la base de données !
La base de données
Prévoir l’organisation de la base de données est l’étape incontournable lors de la lecture d’un CDC. Réussir à établir cette base de données permet d’optimiser le développement futur. En effet, prévoir la base de données en amont évite de nombreuses modifications ou adaptations de cette dernière lors du développement, la mise en place de scripts de migrations …, qui peuvent également demander des modifications de fonctionnalités existantes.
De plus, une base de données établie clairement aide grandement à la compréhension du fonctionnement de l’application, nous permettant, dans notre accompagnement/développement, de proposer les solutions toujours les plus adaptées.
L’établissement de la base de données se fait régulièrement à partir des différentes fonctions présentes dans l’application.
Afin de prévoir son organisation, IBC cherche dans un premier temps à obtenir la liste de l’ensemble des données de l’application et leur description. La manière la plus optimisée de décrire les données de l’application est de les présenter sous forme d’entités et de leurs attributs. Une entité correspond à une table de la base de données. Chaque table correspond à un tableau en deux dimensions dans lequel les lignes sont des enregistrements et les colonnes des attributs.
Ex : Dans une application avec connexion, l’utilisateur est une entité (table « utilisateur »). Cependant un utilisateur possède plusieurs informations (attributs) comme un login, un mot de passe, un nom, un prénom, une entreprise, une adresse mail et un numéro de téléphone.
Pour optimiser le développement de l’application avant même de commencer à coder, IBC cherche ensuite, pour chaque attribut, à déterminer les informations suivantes :
· Type de données (chaine de caractère, nombre, nombre à virgule…)
· La longueur maximum de l’attribut (dans le cas d’un nombre à virgule, préciser le nombre de chiffre avant et après la virgule)
· Est-il obligatoire ou facultatif ?
· Description de l’attribut si besoin
Ces informations sont directement corrélées au fonctionnement de l’application. Par exemple, savoir qu’un attribut est obligatoire pour une entité nous permet de savoir qu’à la création de cette entité lors de l’utilisation de l’application, il sera obligatoire pour l’utilisateur de remplir cette information pour valider le formulaire.
Ex : Inscription d’un utilisateur : Nous savons qu’un utilisateur a besoin d’un login et d’un mot de passe pour se connecter à l’application (= attributs obligatoires pour l’entité utilisateur). De ce fait, lors de l’inscription, à minima, ces deux informations seront obligatoires.
Dans un second temps, IBC cherche à comprendre quels sont les liens éventuels entre les tables de la base de données. Dans l’exemple un « utilisateur » fait partie d’une entreprise mais d’autres utilisateurs font également partie de la même entreprise. Cela signifie que dans la base de données en plus de la table utilisateur il existe une table entreprise et ces deux tables sont liées. Enfin, il faut préciser le type d’association. Un utilisateur doit faire partie d’une seule entreprise et à l’inverse une entreprise regroupe aucun, un ou plusieurs utilisateurs. De manière concrète, dans notre exemple nous dirons qu’un « utilisateur » fait partie d’une seule « entreprise » et une « entreprise » regroupe un à plusieurs « utilisateurs ».
Avec cet ensemble d’informations, il nous est possible de créer un schéma de la base de données relationnel.
Ex :
Les Id sont des attributs uniques nommées clé primaire présents dans chaque table et attribués automatiquement. Ici l’attribut « Entreprise » de la table utilisateur est ce que l’on appel une clé externe. Il correspondra à un Id_entreprise et permettra de faire le lien entre les deux tables.
Optimiser les relations entre les tables permet d’une part de créer une base de données la moins lourde possible (une information est présente une seule fois dans une seule table) et d’autre part, lors du développement de l’application, de créer des requêtes de récupération et d’envoi de données vers la base de données les moins lourdes possibles optimisant ainsi la vitesse d’exécution.
Après vous avoir donné certaines des clés pour bien appréhender votre base de données dans la rédaction d’un cahier des charges, nous étudierons les pages de votre application dans notre prochain article. Le design et les fonctions qu’elles doivent comporter permettront aux utilisateurs de l’application/logiciel d’en utiliser tout le potentiel ! Stay tuned !