Discussion :

[merise_lover]

Je vais poser la question autrement : a une date donnée, un customer a combien de role au maximum ?

1

[hed62]

Donc la cardinalité maximale de la relation est 1, et si tu désire historiser la chose, la relation doit porter la date.

[merise_lover]

La date de l'appel ne suffit t'elle pas ?

[JPhi33]

Au niveau MCD, inutile de préfixer tous les attributs afin de rendre chaque nom unique, c'est une étape pour le MLD(MPD?).

J'ai appris l'inverse, à savoir que, dans un MCD, un nom de propriété doit être unique et que l'une des étapes de la normalisation d'un MCD est justement l'élimination des polysémies qui sont des concepts différents nommés de la même manière.

[hed62]

Nos enseignements divergent donc ^^.
Pour moi le MCD est là pour exposer les concepts. La normalisation se faisant progressivement, selon ce que l'on m'a dit la traque des polysémie se fait à un niveau plus bas, pour que le MCD soit lisible. Maintenant, il est sur que si le MLD est généré automatiquement, il se peut qu'il faille enlever tous les homonymes au niveau du MCD.

[merise_lover]

Donc la cardinalité maximale de la relation est 1, et si tu désire historiser la chose, la relation doit porter la date.

Ne peut on pas retrouver cette date grâce à la date de l'appel ?

[hed62]

Alors il faut peut être que call entre en relation entre le customer et le role?

[merise_lover]

Donc la cardinalité maximale de la relation est 1, et si tu désire historiser la chose, la relation doit porter la date.

En fait je vais reformuler la rêgle :

A un UUN peux correspondre plusieurs Rôles, Lorsque un Customer devient Applicant, on lui attribut un UUN, ensuite sont statut change en Student, mais il garde le même UUN. la relation serait donc :

[Customer] ---(1,N)---(IS+Date)---(0,N)---[Role]

et non

[Customer] ---(1,1)---(IS+Date)---(0,N)---[Role]

Est-ce correct ?

[merise_lover]

Quelqu'un pour confirmer svp ?

[merise_lover]

Salut à tous,

plus personne pour m'aider alros ?

maintenant que ç'est presque abouti, je dois rédiger les dependances fonctionnelles (rapport de stage) mais je ne l'ai jamais fait avec de l'héritage.
Quelqu'un pourrait-il corriger ce qui suit svp.



Merci.

[fsmrel]

Ave,


Au sujet des dépendances fonctionnelles (DF)


Dans ce qui suit, je me situe dans le contexte du Modèle Relationnel de Données (niveau logique) et non pas de Merise (niveau conceptuel).

Rappel : Une dépendance fonctionnelle est une relation entre deux ensembles, chaque ensemble étant composé de tout ou partie des attributs composant l’en-tête d’une table (un ensemble peut être vide).

Ainsi, concernant l’association Is (laquelle est mal nommée, car un customer n’est pas un rôle, mais a un rôle ou joue un rôle), il existe la dépendance fonctionnelle (notez l’emploi des accolades) :

{customer_id, date_role} → {role_id}

DF dans laquelle {customer_id, date_role} est le déterminant et {role_id} le dépendant. On lit ainsi la contrainte :

"{customer_id, date_role} détermine {role_id}", ou "{role_id} est fonctionnellement dépendant de {customer_id, date_role}", ou plus simplement : "{customer_id, date_role} flèche {role_id}".

Notez l’emploi du symbole "→" à la place de "⇒" qui sert plutôt pour symboliser le conditionnel ou l’implication.

Toujours dans le cadre du Modèle Relationnel de Données, si vous dressez l’inventaire des DF, table par table, précisez si vous faites figurer celles qui sont triviales (concernant Merise, je ne sais pas si l’on traite de ces DF) ; par exemple, {customer_id, date_role} → {customer_id} et {customer_id, date_role} → {date_role). Il est vrai que l’on a tendance à ne pas faire figurer ces DF, car la liste devient vite impressionnante et indigeste (même chose pour les DF transitives). Dans le jargon, on dit que l'on préfère fournir une couverture irréductible, plutôt qu'une fermeture.

Je rappelle qu’une DF concerne une table et une seule. Si donc Quick_call fait l’objet d’une table, les attributs de celle-ci sont les suivants :

call_id (par héritage), quick_call_category_id (du fait de la traduction de l’association-type quick_graded avec sa cardinalité 1,1).

Dans ces conditions, on a la DF suivante : {call_id} → {quick_call_category_id}.

De la même façon, du fait de l'existence de la table Full_call, on aura {call_id} → {full_call_category_id}.

En notant que si vous décidez que la table Call absorbe les tables Quick_call et/ou Full_call, peu importe, le principe reste le même.

En poursuivant la tournée des DF, on découvre que :

{call_id} → {status_id} /* Table Full_call */
{call_id} → {priority_id} /* Table Full_call */
{call_id} → {browser_id} /* Tables Full_call | Concern_browser */
{call_id} → {hardware_id} /* Tables Full_call | Hardware */
{call_id} → {customer_id} /* Table Call */
{call_id} → {person_id}/* Table Call */

J’en ai peut-être oubliées.

Pou ce qui concerne le niveau conceptuel (MCD), je ne suis pas le mieux placé pour vous répondre, interrogez par exemple TheLeadingEdge.

[merise_lover]

Ainsi, concernant l’association Is (laquelle est mal nommée, car un customer n’est pas un rôle, mais a un rôle ou joue un rôle)

Pourtant dans Rôle on a {Student, Applicant, Enquierer, Staff, Other}

Ce qui donne :
the Customer is a Student
ou
the Customer is an Applicant

C'est peut être le libellé Role qui est mal choisi mais il existait déjà une entité status donc..

(notez l’emploi des accolades)

ok merci j'avais oublié !

Notez l’emploi du symbole "→" à la place de "⇒" qui sert plutôt pour symboliser le conditionnel ou l’implication.

Compris !

Toujours dans le cadre du Modèle Relationnel de Données, si vous dressez l’inventaire des DF, table par table, précisez si vous faites figurer celles qui sont triviales

Je ne pense pas les décrire en effet.

Je rappelle qu’une DF concerne une table et une seule. Si donc Quick_call fait l’objet d’une table, les attributs de celle-ci sont les suivants :

call_id (par héritage), quick_call_category_id (du fait de la traduction de l’association-type quick_graded avec sa cardinalité 1,1).

Dans ces conditions, on a la DF suivante : {call_id} → {quick_call_category_id}.

De la même façon, du fait de l'existence de la table Full_call, on aura {call_id} → {full_call_category_id}.

Puis je écrire ces deux dépendances à la suite telles quelles ?

{call_id} → {quick_call_category_id}.
{call_id} → {full_call_category_id}.

Ou dois-je être plus précis comme vous l'avez fait ci-dessous ?

En poursuivant la tournée des DF, on découvre que :

{call_id} → {status_id} /* Table Full_call */
{call_id} → {priority_id} /* Table Full_call */
{call_id} → {browser_id} /* Tables Full_call | Concern_browser */
{call_id} → {hardware_id} /* Tables Full_call | Hardware */
{call_id} → {customer_id} /* Table Call */
{call_id} → {person_id}/* Table Call */

J’en ai peut-être oubliées.

Justement, les expressions en gras sont-elles standards ? Ou est-ce juste votre propre notation ?

Merci.

[fsmrel]

Pourtant dans Rôle on a {Student, Applicant, Enquierer, Staff, Other}

Ce qui donne :
the Customer is a Student
ou
the Customer is an Applicant

Vous projetez ce que vous avez en tête et qui est vrai, mais malheureusement votre représentation graphique exprime autre chose, c'est-à-dire littéralement ceci : "un Customer_Details est un Rôle (voire plusieurs)".

"Is" exprime le fait qu’un type jour le rôle de surtype par rapport à un autre (qui joue donc le rôle de sous-type), ce qui est le cas de Call qui se comporte en surtype vis-à-vis de Quick_call et de Full_call.

les expressions en gras sont-elles standards ? Ou est-ce juste votre propre notation ?

C’est ma propre notation (enfin que je partage avec d’autres), ces expressions ne sont que des commentaires, à votre seule intention.

Puis je écrire ces deux dépendances à la suite telles quelles ?

{call_id} → {quick_call_category_id}.
{call_id} → {full_call_category_id}.

Au niveau du MLD, la question ne se pose pas, puisque ces DF sont attachées à la table Quick_call.

Au niveau Merise, je n’ai pas d’opinion car, pour diverses raisons, je n’y traite pas des DF. Maintenant, si vous ne mentionnez pas les entités-types et associations-types porteuses virtuellement des attributs impliqués dans les DF, peut-être pouvez-vous rester neutre en ajoutant effectivement à votre liste :

{call_id} → {quick_call_category_id}
{call_id} → {full_call_category_id}

et bien sûr le paquet des DF faisant l’objet des commentaires. Voyez avec TheLeadingEdge pour confirmation.

[TheLeadingEdge]

Bonjour,

Il manque une bonne partie des DF. En fait tu n'as représenté que les DF élémentaires directes. Sauf 1 mais elle est inversée par rapport à ce que dit ton MCD . {Customer, Date}--> Role devrait être {Customer, Role}--> Date. Le graphe obtenu d'après celles que tu as renseigné est celui-ci :

Pour correspondre à ton MCD il devrait ressembler à celui-ci :

J'ai encadré manuellement les entités sur le graphe pour ''coller'' au MCD que tu as posté. Je te laisse le soin de traduire le graphe en tenat compte des remarques de fsmrel.
2 petites choses concernant la sémantique de ton MCD.
L'héritage Call quick_call me semble pas justifié. 1 seule spécialisation full_call est suffisante. D° pour les 2 entités call_category. 1 seule devrait suffire ?

Au niveau MCD, inutile de préfixer tous les attributs afin de rendre chaque nom unique, c'est une étape pour le MLD(MPD?).

J'ai appris l'inverse, à savoir que, dans un MCD, un nom de propriété doit être unique et que l'une des étapes de la normalisation d'un MCD est justement l'élimination des polysémies qui sont des concepts différents nommés de la même manière.

Tt à fait. Il y a une vie avant le MCD.
On établi le MCD à partir d'un dictionnaire de données épuré.

A +

[merise_lover]

Bonjour,

Merci à tous pour votre aide.

1) Bon voilà le résultat.

2) Questions

2 petites choses concernant la sémantique de ton MCD.
L'héritage Call quick_call me semble pas justifié. 1 seule spécialisation full_call est suffisante.

C.A.D ? Du fait d'avoir séparé Call en 2 tables sous-jacentes ? Ou juste le fait que Quick_call hérite de Call ?

D° pour les 2 entités call_category. 1 seule devrait suffire ?

C'est en effet ce que j'avais fait au départ, mais les 2 tables ne comporteront pas les mêmes valeurs (Plus restreint pour Quick call et intitulés différents) Celà permet donc d'éviter des valeurs nulles me trompe-je ?

3) Bon alors c'est bon c'est fini là oh ??

[TheLeadingEdge]

C.A.D ? Du fait d'avoir séparé Call en 2 tables sous-jacentes ? Ou juste le fait que Quick_call hérite de Call ?

Full_call c'est bon. Mais d'après ton modèle il n'y a pas de différence entre call et quick_call. La spécialisation en Quick_call ne se justifie pas.

C'est en effet ce que j'avais fait au départ, mais les 2 tables ne comporteront pas les mêmes valeurs (Plus restreint pour Quick call et intitulés différents) Celà permet donc d'éviter des valeurs nulles me trompe-je ?

Si le nombre d'attributs utilisés varie selon le type d'appel va pour 2 entités. Sinon 1 seule.

pour les DF (btw ce ne serait pas ''dependencies'' ? la norme c'est d'utiliser --> et pas ==>.
D'autre part il me semble qu'il en manque encore 1, non ? Je n'ai pas vu celle entre tag et full_call. (nb : d'ailleurs je me suis planté de sens sur le graphe pour celle-là. Les flêches sont inversées.).

A +

[merise_lover]

Full_call c'est bon. Mais d'après ton modèle il n'y a pas de différence entre call et quick_call. La spécialisation en Quick_call ne se justifie pas.

C'est comme cela que cela sera géré au niveau du MLD. Niveau MCD, il faut modéliser un héritage. Les appels sont sousclassés selon qu'ils sont résolus immédiatemetn ou non.

Quick_call possédant une catégorie qui lui est propre, je dois donc le traiter à part non ? Pour plus de détails sur la manière dont j'ai procédé je vous invite à consulter les messages 8, 9 et 10

Si le nombre d'attributs utilisés varie selon le type d'appel va pour 2 entités. Sinon 1 seule.

Oui ce sera le cas.

pour les DF (btw ce ne serait pas ''dependencies'' ?

Oups erreur de traduction merci

D'autre part il me semble qu'il en manque encore 1, non ? Je n'ai pas vu celle entre tag et full_call.

C'est mieux comme ça ?

[TheLeadingEdge]

Re,

C'est mieux comme ça ?

Euh non ... Mais l'assoce est ''vacharde''
Telle que tu l'écrit

call_id -> {[...], tagid}

elle se traduirait par

<full_call> --1,1--<identified_by>--0,n--<tag>

En fait il ne s'agit pas d'une DF, mais d'une DM (dépendance multivaluée) qui s'écrit :

{call_id, tag_id} ->-> call_id | tag_id

@fsmrel : si vous passez, pouvez-vous valider le formalisme ?

[merise_lover]

En fait il ne s'agit pas d'une DF, mais d'une DM (dépendance multivaluée) qui s'écrit :

{call_id, tag_id} ->-> call_id | tag_id

Oui petite erreur de ma part !
Du coup pas besoin de la noter si ? (A vrai dire on n'a pas approfondi ça en cours) Ou dans ce cas je dois noter également celle de l'association rôle !

Sinon concernant l'héritage Quick Call pouvez-vous expliciter celà ?

Full_call c'est bon. Mais d'après ton modèle il n'y a pas de différence entre call et quick_call. La spécialisation en Quick_call ne se justifie pas.

Et en parlant de ça, petites modifications de dernière minute (à la demande du chef de projet)
Il souhaite permettre à plusieurs personnes de traîter un même appel lorsqu'il s'agit d'un Full Call
Un Quick Call possède alors le statut de "répondu par"
Tandis qu'un Full Call est "traité par"
Ainsi pour retrouver qui à répondu le premier à l'appel 'full Call', on ajoute une date. Ce qui permet également de créer un historique des personnes ayant traité l'appel.
Voici les modifications.

[TheLeadingEdge]

Re,

Sinon concernant l'héritage Quick Call pouvez-vous expliciter celà ?

Jusqu'à ton dernier post, je ne voyais pas l'utilité de créer une entité spécialisée ''quick_call'' qui se comportait exactement comme son ancêtre ''call''. (1er modèle)

Un Quick Call possède alors le statut de "répondu par"
Tandis qu'un Full Call est "traité par"
Ainsi pour retrouver qui à répondu le premier à l'appel 'full Call', on ajoute une date.

D'aprés ce qui est demandé, l'association ''répondre'' est entre les entités ''quick_call'' et ''support'' et pas entre ''call'' et ''support''comme sur ton MCD. Maintenant on peut envisager 1 entité ''quick_call''. (2nd modèle)