Discussion :

[JeromeCo1111111]

Bonjour,

Est-il possible avec Looping de représenter un attribut dérivé ?

Je n'ai pas trouvé comment.

Merci pour votre aide !
Jérôme

[Paprick]

Bonjour,

Afin de bien comprendre votre demande, merci de donner un exemple précis de ce que vous attendez.

[JeromeCo1111111]

Par exemple si j'ai une entité voiture, qui contient un attribut "kilomètres parcourus" et "essence consommée", j'aimerais avoir un attribut dérivé "consommation", qui est le résultat du calcul avec les deux premiers attributs.

Peut-être est-ce moi qui fait erreur mais dans un MCD, j'avais l'habitude de placer devant un tel attribut le symbole (c).

Autre exemple : une bibliothèque possède plusieurs exemplaires d'un livre. L'entité Livre contient un attribut dérivé "est disponible" qui est calculé au moyen d'une requête qui vérifie s'il reste des exemplaires non-empruntés de ce livre à la bibliothèque.

J'espère avoir été ainsi plus clair.

Merci !
Jérôme

[fsmrel]

Par exemple si j'ai une entité voiture, qui contient un attribut "kilomètres parcourus" et "essence consommée", j'aimerais avoir un attribut dérivé "consommation", qui est le résultat du calcul avec les deux premiers attributs.

Hum... Il existe une dépendance fonctionnelle {kilomètres parcourus, essence consommée} → {consommation}.
Si la paire {kilomètres parcourus, essence consommée} n’est pas identifiante (clé candidate selon la théorie relationnelle), alors la forme normale de Boyce Codd n’et pas vérifiée, donc l’entité-type n’est pas normalisée. Il et alors préférable de définir l’attribut "consommation" dans une vue.

[Paprick]

Bonjour,

D'une façon générale, si j'ai bien compris, ces attributs dérivés correspondent à ce que j'appelle des rubriques "calculables".
Par définition, une rubrique calculable peut donc être recalculée à partir de rubriques dites "primaires", et le fait de les stocker dans la base de données est donc redondant et rend le système d'information incohérent entre le moment de la modification des rubriques primaires impliquées dans le calcul et la mise à jour de la rubrique calculable en question (ce qui rejoint les remarques de fsmrel).
Ca, c'est la théorie ! En pratique, pour des raisons de performance en consultation, bon nombre de bases de données intègrent des rubriques calculables, laissant le développeur ou/et le DBA assurer la cohérence (gestion de transactions, ...).
Donc, malgré mon aversion pour ces rubriques calculables, on peut admettre qu'elles soient utilisées.

Pour revenir à Looping, aucun signe distinctif n'est prévu pour ces rubriques : personnellement, j'utilise la zone "Commentaire" des rubriques concernées pour, d'une part, signaler que la rubrique est calculable et, d'autre part, indiquer son mode de calcul.
On peut également aller plus loin pour assurer la cohérence de la base de données avec l'outil "Règle" de Looping qui apparaît visuellement dans le MCD, mais qui permet également d'associer du code SQL spécifiant le calcul et qui rajoute la contrainte correspondante au DDL.

En espérant que cela vous aide, bonne continuation !

[escartefigue]

Dans la mesure où ce qui prend du temps, c'est la recherche de la ligne dans la base de données (calcul du chemin d'accès puis parcours effectif de celui-ci si la donnée n'est pas dans le cache), on ne gagnera rien à stocker une donnée calculée : le temps de calcul représente un pouillème quasiment non mesurable.
Dans ce cas de figure, je plaide également pour une restitution au moyen d'une vue si le besoin est récurrent ou directement par requête si le besoin est ponctuel.

[JeromeCo1111111]

Merci beaucoup pour vos réponses et vos éclaircissements !