Discussion :

[desi]

Je n'arrive pas à obtenir de définition exacte de la nature des attributs d'une entité
On me dit qu'un attribut peut être
Soit élémentaire
soit concaténé
soit calculé
soit signalétique
soit de situation
soit de mouvement

dans quel cas utilisé tel ou tel nature d'atribut?
que signifie exactement élémentaire, signalétique...?

[CinePhil]

On me dit qu'un attribut peut être

Qui te dit ça ?

Soit élémentaire

Jusque là ça me va.
Exemples : nom, prénom, numéro de téléphone, date de naissance... sont à mon sens des attributs élémentaires.

soit concaténé

Ça commence à poser problème ! Qui dit concaténé dit plusieurs informations rassemblées en une seule et ça c'est contraire aux règles de construction d'une BDD !
Chaque attribut d'une entité (chaque colonne d'une table) doit porter une information atomique, élémentaire !

soit calculé

Là aussi il faut se l'interdire en première approche.
N'enregistrer un attribut calculé que :
- en cas avéré de problèmes de performances lié à la répétition du calcul de certaines données ;
- en cas d'archivage de données.

Par exemple, si le volume de données est important et que le taux de remise accordé à un client est lié au montant des commandes qu'il a passées durant les trois dernièrs exercices comptables, il peut être intéressant pour les performances d'avoir une procédure, lancée chaque année, qui calcule ce montant et le stocke dans une colonne de la table des clients.

Ne pas confondre ce principe avec celui qui consiste à enregistrer le prix de vente d'un produit dans la ligne de commande. C'est effectivement un attribut calculé à un instant T mais c'est aussi une information figée qui peut ne plus être calculable par la suite car elle dépend de la valeur de paramètres (tarif, remise, taux de TVA...) qui peuvent changer après le calcul, rendant ainsi cette information non calculable avec exactitude après ces changements.

soit signalétique
soit de situation
soit de mouvement

Là, je ne vois pas de quoi il s'agit !

[desi]

OK mille merci de te pencher sur ma question.
je suis tout à fait d'accord avec tes remarques.
j'étais tranquille dans mon coin avec toutes mes conceptions de BDR jusqu'à ce que je lise le doc en pièce jointe
tu peux aller directement à la page 9.

[CinePhil]

Donc ces notions interviennent, selon ce professeur, au niveau du dictionnaire de données.

Comme j'ai déjà dit récemment dans une autre discussion, je ne fais jamais de dictionnaire de données. Et ce distinguo entre les différentes familles de données ne m'apporteraient à vrai dire rien. Mais je veux bien faire l'effort d'expliquer ce que je comprends...

L'exemple donné est celui d'écritures dans un journal comptable.
La caractérisation des données dites "élémentaires" est évidente, à l'exception selon moi des Cumul débit et crédit qui, il me semble, sont plutôt des données calculées. Ou alors c'est l'appellation Cumul qui est inappropriée.
Quant au distinguo entre donnée signalétique et de situation, je trouve que le libellé est aussi une donnée signalétique plutôt que de situation.

Mais bon, je ne trouve pas très utile de passer du temps sur ces considérations quand on conçoit une BDD.

EDIT :
Par curiosité, je jette un oeil à la suite du document (MCD) et je trouve un peu bizarre de mélanger les notions d'entité et d'objet ainsi que de relation et d'association.
Pour moi, un MCD est composé d'entités et d'associations.

Et en principe, dans un MCD on parle plutôt d'attribut que de propriété qui est plus un terme UML.

Bizarre aussi que le document s'arrête au MCD alors que dans la première partie il parle de tous les autres schémas.

Bref, document à prendre avec des pincettes !

[ok.Idriss]

Bonjour.

Donc ces notions interviennent, selon ce professeur, au niveau du dictionnaire de données.

Comme j'ai déjà dit récemment dans une autre discussion, je ne fais jamais de dictionnaire de données

Je n'en fait que lorsque l'on est plusieurs à travailler sur une bdd conséquente (ou lorsqu'on me l'exige) ...

Mais de toute façon, il ne doit comporter que les données figurant dans le MCD (ni plus ni moins). Autrement dit : pas de données composées, seulement quelques rares données calculées (comme le montant TTC d'un achat pour éviter de le recalculer surtout si la TVA change après l'achat ), dans un dictionnaire (comme pour le MCD).

Enfin, je ne sais pas pourquoi la discussion comporte le tag MCT ...

Cordialement,
Idriss

[MacFly58]

Citation:
soit concaténé

Ça commence à poser problème ! Qui dit concaténé dit plusieurs informations rassemblées en une seule et ça c'est contraire aux règles de construction d'une BDD !
Chaque attribut d'une entité (chaque colonne d'une table) doit porter une information atomique, élémentaire !

Une information atomique n'est pas toujours la même en fonction du sujet.
Par exemple le numéro de compte bancaire peut ou non être décomposé en code guichet, n° compte, etc (qui eux-mêmes peuvent être décomposés ou non). Donc cette donnée peut rester "concaténée" dans certains MCD. L'utilisateur n'aura jamais besoin de la décomposer (ce qui pourra être précisé dans le cahier des charges).
Ceci dit l'intérêt de préciser dans le dictionnaire qu'une donnée est "concaténée" ou non me semble superflu.

Comme j'ai déjà dit récemment dans une autre discussion, je ne fais jamais de dictionnaire de données.

L'intérêt majeur du dictionnaire de donnée est de fournir un libellé à une donnée codée. Toutes les données d'une BDD sont codées. Par exemple la donnée CMTC signifie quoi ?
Dans ce cas on se reporte au dictionnaire de données qui indique qu'il s'agit du "Cumul des Montants Hors Taxe".
De plus le libellé permet de fournir un complément d'informations sur des noms de données qui pourraient avoir plusieurs sens, ou qui ne sont pas forcément clair.
Mais bon je trouve également que l'intérêt du dictionnaire de données est très limité.

Par curiosité, je jette un oeil à la suite du document (MCD) et je trouve un peu bizarre de mélanger les notions d'entité et d'objet ainsi que de relation et d'association.
Pour moi, un MCD est composé d'entités et d'associations.

Et en principe, dans un MCD on parle plutôt d'attribut que de propriété qui est plus un terme UML.

Je ne suis pas choqué personnellement, en fonction des ouvrages sur Merise, on parle d'objet ou d'entité, d'association ou de relation, d'attribut ou de propriété, etc...
Le chapitre sur le MCD est le copier/coller d'un livre qui parle d'objet et non d'entité. Personnellement je préfère le terme entité-type, mais aucune norme n'existe (malheureusement pour les étudiants).

Il me semble très important de connaître tout ce vocabulaire (et les nombreux et très courant abus de langage que nous utilisons) pour comprendre tous les informaticiens.

[colonel098]

je voudrais savoir quand on parle de signalétique quoi ça veux dire de situation et de mouvement