Bonsoir Femtozaza,
Envoyé par
Femtozaza
Si TypeOptique est lentille, je n'ai aucune raison de demander de quel type de miroir il s'agit. Par contre pour la suite j'ai besoin de savoir si elle est cylindrique ou sphérique (focalisation sur un axe ou un point).
De même pour les miroirs car il est possible d'avoir des optiques qui sont des miroirs sphériques qui donc réfléchissent et focalisent la lumière.
Je me rend compte en l'écrivant que du coup peut-être qu'il serait plus judicieux de regrouper les champ TypeOptique et TypeLentille et TypeMiroir, il me suffirait de faire la séparation dans TypeOptique (Miroir, Miroir Sphérique, Miroir Cylindrique,...), ça simplifierai sans doute l'ensemble.
Vous pouvez faire au plus simple et conserver dans la table FOURNISSEUR_CATALOGUE les attributs caractérisant les optiques (Dimensions, Epaisseur, Traitement, etc., en supposant qu’ils ont un sens pour tous les types d’optiques), et y supprimer les attributs TypeLentille, TypeMiroir. C’est l’attribut TypeOptiqueId qui, par référence à une table de types (appelons-la par exemple TYPE_OPTIQUE), permettra de savoir s’il s’agit d’une lentille ou d’un miroir (voire d’un biglotron, si tant est qu’un biglotron puisse faire l’objet d’un type d’optique...)
D’où le diagramme :
Vous pouvez aussi avoir une représentation moins basique de la table TYPE_OPTIQUE puisque vous distinguez les miroirs sphériques des miroirs cylindriques et autres raffinements :
Notez que j’ai ajouté un attribut TypeOptiqueCode au cas où l’utilisateur souhaiterait disposer comme il l’entend d’une nomenclature des types d’optique. Vous noterez aussi en passant que, dans mes diagrammes, tous les attributs qui se terminent par « Id » (FournisseurId, CommandeId, OptiqueCatid, etc.) sont doublés d’un attribut dont les valeurs ont un sens pour l’utilisateur : FournisseurRef, CommandeNumero, OptiqueReference, etc.) A la suite d’Yves Tabourier, J’applique ici une règle fondamentale qu’il a développée dans son ouvrage (De l’autre côté de MERISE, page 80), et c’est une règle d’or qui reste malheureusement trop souvent méconnue, malgré ses plus de 25 ans d’âge :
« ... la fonction d’une propriété est de décrire les objets (et les rencontres), alors que l’identifiant ne décrit rien. Son rôle fondamental est d’être sûr de distinguer deux jumeaux parfaits, malgré des descriptions identiques.
L’expérience montre d’ailleurs que l’usage des “identifiants significatifs” (ou “codes significatifs”) a pu provoquer des dégâts tellement coûteux que la sagesse est d’éviter avec le plus grand soin de construire des identifiants décrivant les objets ou, pis encore, leurs liens avec d’autres objets... »
Pour avoir effectué bien des audits de SI (systèmes d’information), j’ai pu constater ces dégâts, entraînant souvent la refonte des SI, victimes de la non application de cette règle de bon sens. Ainsi un identifiant n’est porteur d’aucune signification et donc est invariant.
Envoyé par
Femtozaza
Si je dépliais il s'agirait de relier à un type d'optique un certain nombre de caractéristiques utiles pour cette optique, c'est ça?
L’utilisation du verbe « relier » est certes possible, mais il faut viser le niveau sémantique. Dans l’exemple que j’ai donné, une prime de bilan ne vaut que pour les collaborateurs qui sont directeurs, ainsi c’est le verbe être qu’il faut employer : un directeur est un collaborateur, un employé est un collaborateur, et un collaborateur est soit un directeur, soit un employé. On peut dire qu’on a spécialisé plutôt que déplié 
l’entité-type COLLABORATEUR en DIRECTEUR d’une part et EMPLOYE d’autre part, parce qu’il se trouve que s’ils ont des caractéristiques communes (un matricule, un nom, un prénom, etc.), directeurs et employés ont néanmoins des caractéristiques qui les différentient radicalement, telles que la prime de bilan, ou le profil.
Il en va des collaborateurs comme des tiers (lesquels, incidemment ne sont pas des personnes physiques, mais des personnes morales, au moins dans l’exemple) : ces derniers ont un numéro Siret, une raison sociale, et sans doute d’autres caractéristiques communes. Par contre on les spécialise en clients et fournisseurs car certaines caractéristiques diffèrent là aussi : les rabais que l’on consent aux clients sont sémantiquement différents des paliers de remise négociés avec les fournisseurs.
Notez encore que le pendant de la spécialisation est la généralisation. Ainsi, constatant par exemple que les collaborateurs ont une adresse, tout comme les tiers (qui peuvent en avoir plusieurs), on peut très bien envisager de mutualiser ce genre de caractéristiques, en inventant une entité-type PERSONNE qui sera la généralisation des entités-types COLLABORATEUR et TIERS, alors que celles-ci sont a priori indépendantes. Désormais, un collaborateur est une personne, un tiers est une personne, tandis qu’une personne est soit un collaborateur, soit un tiers. Une fois cette généralisation effectuée, on rattachera une entité-type ADRESSE à l’entité-type PERSONNE : cette fois-ci c’est le verbe avoir qui évidemment s’impose : une personne a une (ou plusieurs adresses) :
Ainsi, on a mutualisé la gestion des adresses des directeurs, des employés, des clients, et des fournisseurs. C’est du meccano, mais c’est rentable.
Je ne sais pas si ça vaut le coup de procéder à la spécialisation/généralisation des optiques, intellectuellement, ou plutôt sémantiquement, c’est certainement un jeu intéressant, mais quant à la mise en oeuvre ça peut se discuter, il ne faut pas non plus monter une usine à gaz qui laisserait perplexes les papous (à spécialiser en papous papas et papous pas papas comme tout monde sait... 
)
Encore bon courage...
(Et n'oubliez pas de voter quand une réponse pu vous aider...)
Débutant-Validation modélisation BDD inventaire d'optique
Répondre avec citation
si la réponse donnée vous a été utile et 
pour une réponse pertinente.
des tables de la base de données, clés qui jouent un rôle essentiel sous le capot (opérations de jointure entre tables). En revanche, d’un point de vue sémantique, métier, ils n’apportent rien à l’utilisateur qui n’en a cure, ils ne font pas l’objet d’une description particulière, leur présence dans l’en-tête des entités-types (donc des tables dans le contexte ACCESS) suffit largement avec peut-être d’un bref rappel à la Tabourier quant à leur rôle, pour que le lecteur découvrant le dossier de conception ne se perde pas en conjectures quant à la présence de ces choses-là...
)
Partager