Discussion :

[alainyvan]

Dans la mesure où vous ne conservez pas la trace des modifications des prix et quantités, la date de modification de l’annonce intègre l’association VENTE, comme vous l'aviez fait.

Oui. Les attributs d'une vente ne sont pas conservées comme historique. Il représente les valeurs de l'annonce en cours.

Bonsoir alainyvan,
La date participe à l’identification.

Je comprends bien cela, mais qu'elle différence cela aurais fait si j'avais utilisé la date de création en tant qu'attribut de l'association Vente.

Merci.

[alainyvan]

Bonjour fsmrel,

J'essaye PowerAMC mais je ne parvient pas a ajouter dans le model conceptuel un index unique (pour url_entreprise).
De plus lorsqu'il génère le modèle physique, la table DATE est conservé contrairement à votre exemple.
Avez-vous conservé par hasard une sauvegarde de votre exemple ?

Merci.

[fsmrel]

Bonsoir alainyvan,

La date participe à l’identification.

quelle différence cela aurais fait si j'avais utilisé la date de création en tant qu'attribut de l'association Vente ?

Je rappelle la règle RG1 (message #10) :

(RG1) Pour une entreprise, un utilisateur, un produit et une date donnés, il y a exactement une référence, un prix unitaire et une quantité.

Si la date ne participait plus à l’identification, cette règle serait à réécrire ainsi :

Pour une entreprise, un utilisateur, un produit, il y a exactement une référence, un prix unitaire, une quantité et une date de création.

Revenons sur le tableau proposé dans le message #10 :

Entreprise       Utilisateur    Produit                       Réf    Prix     Qté    Date
-------------    -----------    --------------------------    ---    ------   ---    ----------
eBay             Fernand        Samsung SSD 850 PRO 512 Go    123    295,95    10    15/06/2015
PriceMinister    Fernand        Samsung SSD 850 PRO 512 Go    123    295,95    10    15/06/2015
eBay             Fernand        Samsung SSD 850 PRO 512 Go    345    295,95    10    16/06/2015
PriceMinister    Fernand        Samsung SSD 850 PRO 512 Go    234    295,95    10    16/06/2015

La date de création ne participant plus à l’identification, ça change bien des choses : l’identifiant de VENTE étant réduit au triplet {Entreprise, Utilisateur, Produit}, les lignes 3 et 4 du tableau contiennent des valeurs d’identifiant en double par rapport aux lignes 1 et 2, elles sont donc illégales et ne peuvent exister.

lorsqu'il génère le modèle physique, la table DATE est conservé contrairement à votre exemple.

Pour éviter la génération de la table, dans le MCD décochez la case ad-hoc pour l’entité-type DATE :

je ne parvient pas a ajouter dans le model conceptuel un index unique (pour url_entreprise).

Un modèle conceptuel se situe au niveau de l’abstraction tandis qu’un index est du niveau fer à souder, sous le capot...

En fait vous cherchez à définir une clé alternative (symbolisée par un mickey <ai> dan l’entité-type ENTREPRISE). Accédez à l’onglet « Identifiants » de la fenêtre des propriétés de l’entité-type ENTREPRISE :




Faire un clic gauche sur la ligne en dessous de celle qui contient l’identifiant « identifiant_1 », il en résulte une ligne supplémentaire « identifiant_2 », suite à quoi on peut faire « Appliquer » :




Ensuite, faire un double clic gauche sur la ligne « identifiant_2 », ce qui provoque l’ouverture de la fenêtre « Propriétés de l’identifiant » :




Cliquer alors sur l’onglet « Attributs » ce qui fait apparaître l’icône d’ajout d’attributs :




Cliquer sur l’icône, ce qui fait apparaître la liste des attributs de l’entité-type :




Il n’y a plus qu’à cocher la case qui va bien en l’occurrence « Url_entreprise ». Ceci fait, on fait OK et l’on revient à la fenêtre où l’on voit que l’identifiant « identifiant_2 » contient l’attribut « Url_entreprise ».




On peut utiliser le bouton « Appliquer » ou « OK » : c’est bon, l’attribut « Url_entreprise » fait l’objet d’un identifiant alternatif :



Intuitif, non ?

N'oubliez pas de voter pour les messages qui ont pu vous être utiles...

[fsmrel]

Comme votre interrogation concernant la définition d’un identifiant alternatif revient périodiquement, je crée un billet à partir de l’entité-type ENTREPRISE...

[alainyvan]

Merci pour votre aide.

Peut-on envisager le modèle suivant ?

[fsmrel]

Bonjour alainyvan,

Selon votre MLD, la table VENDRE a pour clé primaire :

{id_entreprise, id_utilisateur, id_produit, id_ref}

Autrement dit, les valeurs suivantes sont autorisées, contrairement à ce qu’énonce la règle de gestion RG2 (message #10) :

Entreprise       Utilisateur    Produit                       Réf    Prix     Qté    Date
-------------    -----------    --------------------------    ---    ------   ---    ----------
eBay             Fernand        Samsung SSD 850 PRO 512 Go    123    295,95    10    15/06/2015
eBay             Raoul          Samsung SSD 850 PRO 512 Go    123    295,95    10    16/06/2015

La règle RG2 dit ceci :

Pour une entreprise et une référence données, il y a exactement un utilisateur, un prix unitaire, une quantité et une date.

Selon votre dernière modélisation, RG2 est contredite : entre autres choses, pour une entreprise et une référence données, il peu y avoir plusieurs utilisateurs.

Question : Est-ce possible ?


De même, désormais, pour une entreprise et une référence données, il peut y avoir plusieurs produits :

Entreprise       Utilisateur    Produit                       Réf    Prix     Qté    Date
-------------    -----------    --------------------------    ---    ------   ---    ----------
eBay             Fernand        Samsung SSD 850 PRO 512 Go    123    295,95    10    15/06/2015
eBay             Fernand        SSD Kingston SSD Now V300     123    295,95    10    16/06/2015

Question (Q2) : Est-ce possible ?

[fsmrel]

Bonjour alainyvan,

En attendant votre réflexion quant au remplacement de la date de création par la référence dans l’identification de l’entité-type VENTE, voici un petit vade mecum pour créer des clés candidates dans un MLD.

Je rappelle les règles de gestion des données proposées dans le message #10 (on pourra les compléter au besoin au besoin avec la date de modification de l’annonce) :

(RG1) Pour une entreprise, un utilisateur, un produit et une date donnés, il y a exactement une référence, un prix unitaire et une quantité.

(RG2) Pour une entreprise et une référence données, il y a exactement un utilisateur, un prix unitaire, une quantité et une date.

RG1 donne lieu à un 1er identifiant pour VENTE :

{id_utilisateur, id_produit, id_entreprise, DateCreation} ;

Et RG2 donne lieu à un 2e identifiant :

{Reference, id_entreprise}.

Puisque dans le MCD, VENTE est une association quaternaire, le 1er identifiant est traduit sous forme de clé primaire par PowerAMC. En revanche, comme je l’ai précisé dans le message #12, on se sait pas exprimer dans le MCD le 2e identifiant, en conséquence de quoi on agit seulement au niveau MLD.

Lors de la dérivation du MCD, PowerAMC produit ceci (on passe directement du MCD au MPD) :






On renomme Date en DateCreation, car « Date » est un mot réservé en SQL et il vaut mieux éviter les (mauvaises) surprises...





Pour que la règle RG2 soit prise en compte, il s’agit maintenant d’établir la paire {Reference, id_entreprise} comme clé alternative (ak) de la table VENTE. Pour cela, on ouvre la fenêtre « Propriétés de la table » (VENTE), et on clique sur l’onglet « Clés ». (Pour mémoire, noter qu’est mentionnée la clé primaire de la table VENTE) :





Pour ajouter la clé alternative {Reference, id_entreprise}, on fait un clic gauche sur la ligne en-dessous de la clé primaire (Identifiant_1), apparaît alors le nom d’une clé nouvelle (Cle_2) et on clique sur le bouton « Appliquer » :





Après avoir cliqué sur le bouton « Appliquer », celui-ci devient grisé :





On double-clique alors sur la ligne « Cle_2 », ce qui provoque l’ouverture de la fenêtre « Propriétés de la clé » (Cle_2) :





On clique sur l’onglet « Colonnes », la fenêtre est ainsi transformée (présence d’une icône d’ajout de colonnes) :





On clique sur l’icône « Ajouter des colonnes », ce qui provoque l’ouverture de la fenêtre « Sélection » :





Il n’y a plus qu’à cocher les cases des attributs Reference et Id_entreprise :





On fait « OK », et l’on retrouve la fenêtre « Propriétés de la clé » et cette fois-ci les attributs voulus sont bien là.





On peut changer l’ordre des attributs dans la clé, en utilisant les flèches qui vont bien :





On fait « OK » tant et plus. Manifestement le mickey <ak> (alternate key) accompagne les attributs Reference et Id_entreprise de la clé alternative de la table VENTE :




Et voilà... Comme disent les pubs, modéliser facilement en quelques clics de souris...

[alainyvan]

Bonjour,
J'allais vous proposez le modèle suivant:



Merci encore pour vos réponses.

[fsmrel]

Aïe !

Selon votre MLD, la paire K1 = {id_reference, id entreprise} est clé alternative de la table VENDRE, c'est-à-dire qu’elle est clé candidate.
Mais K1 est un sous-ensemble strict du quadruplet K2 = {id_reference, id entreprise, id_produit, id_utilisateur} :

K1 ⊂ K2

K2 est certes une surclé mais ne constitue pas une clé candidate, car elle ne respecte pas la règle d’irréductibilité, règle respectée par K1 :

Vous la voyez l’embrouille ? K2 n’étant pas clé candidate, votre MLD doit être ainsi transformé :




Et je crains que K1 ne suffise pas à blinder votre système...

[alainyvan]

Bonjour fsmrel,
Désolé de ne oas avoir pu vous répondre plus tôt.

Votre solution est plus intéressante que la mienne (qui est erroné).

Mais il est possible d'avoir le cas suivant (2 références identiques pour 2 annonces):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
ID_REFERENCE | ID_PRODUIT | ID_ENTREPRISE | ID_UTILISATEUR | PRIX    | QUANTITE
1            | 1          | 1             | 1              | 295,00  | 4
3            | 1          | 1             | 1              | 299,00  | 2

[ZenZiTone]

Bonjour,

Petite interrogation par rapport au dernier MLD proposé :

Qu'apporte la liaison REFERENCE-> ENTREPRISE?
QU'apporte la liaison VENDRE -> ENTREPRISE?

Car si je ne me trompe pas, une REFERENCE peut être associée dans la table VENDRE à une ENTREPRISE avec laquelle est n'est pas forcément associée dans la table REFERENCE (fk entreprise). Cela est-il accepté?

[alainyvan]

Bonjour,
Qu'apporte la liaison REFERENCE-> ENTREPRISE?
QU'apporte la liaison VENDRE -> ENTREPRISE?

Les entreprises retourne une référence unique lors de la création d'une vente (ou plutôt d'une annonce).

Bonjour,
Car si je ne me trompe pas, une REFERENCE peut être associée dans la table VENDRE à une ENTREPRISE avec laquelle est n'est pas forcément associée dans la table REFERENCE (fk entreprise). Cela est-il accepté?

Une référence n'existe que si une annonce est créée par un utilisateur auprès d'une entreprise.

[fsmrel]

Bonsoir,

ID_REFERENCE | ID_PRODUIT | ID_ENTREPRISE | ID_UTILISATEUR | PRIX    | QUANTITE
1            | 1          | 1             | 1              | 295,00  | 4
3            | 1          | 1             | 1              | 299,00  | 2

Votre exemple met en évidence la règle de gestion suivante :

(RG4) Pour une entreprise, un utilisateur et un produit donnés, on peut avoir plus d’une annonce.

Autrement dit, l’association VENTE, que pour ma part je préfère renommer en ANNONCE, gagnerait à être représentée sous la forme d’une une entité-type :

MCD





MLD





Où la paire {Id_entreprise, Reference} reste clé alternative.

[alainyvan]

Bonjour fsmrel,

Votre disposition est plus propre. Merci.

J'avais déjà modifié l'entité VENDRE en ANNONCES (correspond mieux à la réalité)

Sous PowerAMC, la transformation d'une association vers un entité créer des cardinalité de type (1,1), ce qui n'est pas le cas sur votre diagramme. Cela apporte t-il une réelle différence.

[fsmrel]

Bonsoir,


Revenons à la situation initiale dans laquelle ANNONCE est une association :






Et demandons à PowerAMC de transformer ANNONCE en entité-type :





En fait, il s’agit d’un déguisement d’ANNONCE en entité-type, mais qui reste une association, c’est pourquoi PowerAMC a utilisé l’identification relative en mettant les cardinalités 1,1 entre parenthèses.

Dans les deux cas de figure, si vous dérivez le MCD en MLD (Barre de Menus > Outils > Générer un modèle physique), vous obtenez le même diagramme, dans lequel la table ANNONCE a pour clé primaire le triplet {Id_utilisateur, Id_entreprise, Id_produit} :






Ajoutons l’attribut Id_annonce à l’entité-type ANNONCE et déclarons-le comme identifiant. En fait, il vient y compléter le triplet implicite {Id_utilisateur, Id_entreprise, Id_produit} :







MLD dérivé :






Dans ce MLD, la clé primaire de la table ANNONCE devient le quadruplet {Id_utilisateur, Id_entreprise, Id_produit, Id_annonce}. Cette clé est pertinente si l’on considère que pour chaque valeur du triplet on peut compter plusieurs annonces. Pour reprendre votre exemple et en le complétant, Id_annonce permet de dédoublonner le triplet <1, 1, 1> grâce aux quadruplets <1, 1, 1, 1>, <1, 1, 1, 2> :

ID_UTILISATEUR | ID_ENTREPRISE | ID_PRODUIT | ID_ANNONCE | REFERENCE | PRIX    | QUANTITE
             1 |             1 |          1 |          1 |         1 | 295,00  |        4
             1 |             1 |          1 |          2 |         3 | 299,00  |        2

La numérotation recommence à 1 pour chaque triplet {Id_utilisateur, Id_entreprise, Id_produit} distinct :

ID_UTILISATEUR | ID_ENTREPRISE | ID_PRODUIT | ID_ANNONCE | REFERENCE | PRIX    | QUANTITE
             1 |             1 |          1 |          1 |         1 | 295,00  |        4
             1 |             1 |          1 |          2 |         3 | 299,00  |        2
             1 |             1 |          2 |          1 |         5 | 500,00  |        4
             1 |             1 |          2 |          2 |         7 | 299,00  |        2

Dans mon message précédent, les cardinalités 1,1 ne sont pas mises entre parenthèses, ce qui revient à dire que j’ai utilisé l’identification absolue et la clé primaire de la table ANNONCE est le singleton {Id_annonce} et l’exemple devient :

ID_UTILISATEUR | ID_ENTREPRISE | ID_PRODUIT | ID_ANNONCE | REFERENCE | PRIX    | QUANTITE
             1 |             1 |          1 |          1 |         1 | 295,00  |        4
             1 |             1 |          1 |          2 |         3 | 299,00  |        2
             1 |             1 |          2 |          3 |         5 | 500,00  |        4
             1 |             1 |          2 |          4 |         7 | 299,00  |        2

Cette solution est plus simple à mettre en oeuvre au stade SQL car il suffit de déclarer Id_annonce comme étant auto-incrémenté. Dans le cas du quadruplet, il faut gérer soi-même l’incrémentation relative, ce qui est un peu plus compliqué.

Si vous préférez l'identification absolue, faites un clic droit sur la patte connectant par exemple ANNONCE et ANN_ENTR et vous décocherez la case « Identifiant » dans la fenêtre « Propriétés du lien d'association » :






Rappel : le MLD de mon message précédent (n’oubliez pas la clé alternative {Id_entreprise, Reference}) :

[alainyvan]

Bonsoir,
Je complète mon schéma mais sous PowerDesigner, et souhaiterai savoir si il est possible, lors de la conception du modèle conceptuel, de définir une colonne comme unsigned et auto-incrémentale.
Merci.

[SQLpro]

Bonsoir,
Je complète mon schéma mais sous PowerDesigner, et souhaiterai savoir si il est possible, lors de la conception du modèle conceptuel, de définir une colonne comme unsigned et auto-incrémentale.
Merci.

UNSIGNED n'existe pas en SQL... C'est une merdouille de MySQL qui est incapable d'avoir des contraintes CHECK !
Pour l'auto incrément sous Power AMC, il suffit d'utiliser le type Séquentiel... Cela se traduira par l'auto incrément propre au SGBDR cible, dont vous n'ave pas encore donné le nom mais dont je soupçonne que c'est cette merde infâme de MySQL !

A +