2.2 Identifier les attributs

Une fois les classes définies, vous devez déterminer les caractéristiques partagées par les objets ou concepts de la classe.

Caractéristiques vs données

Attention : il ne s'agit pas ici de déterminer les données. Par exemple, pour un étudiant, on pourrait avoir les caractéristiques nomfamille et prenom, et non Gagnon et Annie. Pour une catégorie, on pourrait avoir la caractéristique description plutôt que Annuelles, Vivaces et Arbustes.

Règles à respecter

Voici quelques règles à respecter lors de la détermination des attributs. Lorsque vous suivez ces règles, votre application pourra plus facilement rechercher des informations dans la base de données et effectuer les manipulations de données requises.

Informations élémentaires

Dans la mesure du possible, tous les attributs doivent être élémentaires, c'est-à-dire qu'il ne doit pas être possible de les décomposer.

• Plutôt que d'avoir un attribut nomcomplet, on aura deux attributs : nomfamille et prenom
• Plutôt que d'avoir un seul attribut pour l'adresse, on aura plusieurs attributs : adresse, rue, ville, codepostal, province, pays

Pas d'informations calculées

Il n'est pas utile d'ajouter un attribut pour stocker une information pouvant être calculée.

Par exemple, l'attribut total d'une facture n'est pas nécessaire. Nous devrons cependant nous assurer d'avoir la quantité et le prix unitaire de tous les items vendus.

Informations constantes dans le temps

Les informations stockées dans les attributs ne doivent pas varier dans le temps. Par exemple, l'attribut age d'une personne sera avantageusement remplacé par sa date de naissance. Ceci assure que l'application pourra en tout temps calculer l'âge et obtenir une information exacte.

Identifiants

Afin de faciliter la programmation ainsi que la maintenance des applications qui utilisent la base de données, il est d'usage d'employer un attribut nommé id comme identifiant dans chaque classe.

Il n'est pas nécessaire d'ajouter les identifiants dans le diagramme de classes. Il s'agit d'une information qui n'apporte rien de concret à la représentation.

Notez qu'un diagramme de classe qui représente les identifiants nommés id est tout de même considéré correct. Si vous le faites, il faudra souligner l'identifiant dans le diagramme de classes.

Exercice en groupe

Toujours dans notre cas de voyages organisés, vous devez maintenant définir les attributs de chaque classe. Pensez aux informations qui devront être enregistrées pour chaque classe.

Voici quelques questions à vous poser pour y parvenir :

• Quelles informations a-t-on besoin de conserver sur chaque personne ? 
• Est-il nécessaire de séparer le nom du prénom ? Dans l'avenir, est-ce que ça pourrait être important ?
• Quelles sont les caractéristiques d'un voyage ?
• Comment les gens pourront-ils effectuer leur paiement ?
• Désire-t-on conserver l'historique de tous les voyages ? Désire-t-on plutôt conserver seulement la liste des voyages sans conserver les inscriptions ?
• Les commentaires doivent-ils être formulés pour un voyage en particulier ou être généraux ?
• Est-il important de connaître la date du commentaire ? L'heure ?
• Comment fera-t-on le lien entre un commentaire et une personne ?
• Quelles autres questions vous poseriez-vous ?

Attention : lorsque vous modélisez une base de données, vous le faites en fonction d'un projet particulier. Vous devez donc vous poser les questions en fonction de ce projet et non de tous les projets de ce type.

Par exemple, la modélisation que nous ferons de ces voyages organisés pourrait être passablement différente de la modélisation faite pour les voyages organisés par une autre personne.

Il en va de même lorsque vous effectuez la modélisation pour une application sur un sujet différent. Un programme développé pour une épicerie donnée pourra utiliser une base de donnée modélisée différemment de celle utilisée pour une autre épicerie puisque chacune possède des particularités qui lui sont propres.