Discussion :

[Antonitzer]

Dans le bureau d’étude pour une MOD d’une Affaire trois schémas différents sont produits, respectivement dans le sens illustré ci-dessous :
1 Layout -> 1 Synoptique -> 1 Principe -> Plusieurs Wiring

Dans la réalité lorsqu’un schéma Synoptique est créé il contient un certain nombre d’informations qui ont déjà été créé sur le schéma de Layout mais avec plus de détails. C’est le cas des « Équipements » par exemple ; chaque équipement présent sur un schéma Layout sera forcément présent sur le schéma Synoptique associé.

Donc ma première idée était naturellement de créer une table « Équipement » associé à la table « MOD » avec des cardinalités « Equipement »--1,1—« Equi_MOD »--1,n—« MOD » avec tous les attributs nécessaire puis les utilisateurs ont accès à telle ou telle donnée selon qu’il soit en train de dessiner un schéma synoptique ou Layout.

Cependant le client désire que si une modification sur un équipement est apportée sur un schéma Layout ou Synoptique, celle-ci ne soit pas répercutée automatiquement sur l’autre schéma associé. Cette restriction m’impose-t-elle donc de créer deux tables « Equipement » distinctes, une pour Layout et une pour Synoptique et concevoir des mécanismes de vérification entre les deux tables ou y-a-t ’il une façon de procéder autrement pour que ce soit plus propre ?

Par extension il faut que je puisse aussi conserver l’ensemble des modifications qui ont été apportées sur une instance d’ « Équipement », incluant les valeurs de ses attributs à chacun de ses états, la solution est-elle alors d’hériter une classe.

Si je me pose aussi la question c’est parce que si je dois faire plusieurs tables équipements et que pour chacune d’entre elle je dois archiver les modifications de ces objets , ça va devenir une base très vite volumineuse.


Je vous remercie d’avance pour votre aide, là ça devient assez difficile pour moi.





Pour la partie plusieurs tables Equipement








Pour la partie historisation des états d'un objet

[JPhi33]

Bonjour Antonitzer,

Comment l'héritage entre MOD et Layout s'explique-t-il ? Et qu'est-ce qu'un(e) MOD ?

L'historisation consiste à dupliquer la ligne avant modification puis à modifier la ligne "courante". On peut utiliser une ou deux tables :
- une table : elle est identifiée par {idTable, Date} et contient l'historique et les lignes courantes. Remplace la date par un "timestamp" selon la fréquence de modification. La date ou le timestamp prennent la valeur du moment de la création de la ligne.

Equipement(EquipementLayoutId, DateCreation, ...)

- deux tables : même principe pour le mécanisme d'historisation mais la table historique est fille de la table courante et la date ou timestamp prend la valeur du moment de l'historisation, c'est-à-dire de la création de la ligne historique.

[EquipementLayout]--0,n----( )---(1,1)-[EquipementLayoutHisto]

[Antonitzer]

Bonjour JPhi33,

Pour la définition d'un MOD, en faite une Affaire (qui correspond à un avion) se découpe en plusieurs MOD (Modification) qui est identifiée par code. il s'agit d'un travail intellectuel fait au bureau d'étude. C'est une façon de découper le travail sur une affaire. Donc en effet je ne sais pas si je dois réellement faire un héritage ou si une association suffit, d'ailleurs comment choisir quel est le meilleur entre les deux ?

Cette décomposition permet ensuite d'imposer que pour chaque MOD il y aura un seul schéma Layout,un seul schéma Synoptique, un seul schéma de Principe et plusieurs schémas Wiring.

Donc en ce qui concerne [EquipementLayout]--0,n----( )---(1,1)-[EquipementLayoutHisto] ok donc EquipementLayoutHisto hérite de EquipementLayout sauf que la fille est identifiée par le couple (EquipementLayoutId, Timestamp)

Donc ça veut dire que pour chaque schéma (Layout, Synoptique, Principe, wiring) d'une MOD il va y avoir un table EquipementSchéma et une table EquipementSchémaHisto ?



J'ai oublié de préciser aussi que les équipements (identifiés par leurs FIN) son unique à l'Affaire (donc pour une affaire impossible de trouver deux fois le même FIN) MAIS un équipement ne peut être traité que dans une MOD donc il n'est présent que dans un seul Layout, Principe, Wiring, pour le cas du synoptique c'est un peu différent : un equipement peut se trouver dans le synoptique d'une autre MOD à laquelle il appartient mais à titre informatif.

Pour aller encore plus loin je dois préciser aussi que les versions de mes schémas doivent être sauvegardée, selon les règles suivantes :
_Un changement d'un attribut visible sur le schéma entraîne changement d'indice du schéma
_Un changement d'un attribut non visible sur le schéma entraîne un changement de versionnement du schéma.

Pour un schéma on peut appeler version un couplet (Indice, versionnement) ; par exemple le couplet (A,1) donne A.1
Pour un équipement on peut appeler version d’un équipement un objet de HistoriqueEquipement

En conclusion : Si je modifie l'attribut d'un équipement dans un schéma création d’une nouvelle version de cet équipement rattaché à ce schéma.
puis
si cette modification touche un attribut NON VISIBLE de mon équipement alors mon schéma garde le même indice mais change de versionnement (incrémentation de 1)
si cette modification touche un attribut VISIBLE de mon équipement alors mon schéma change d'indice et retrouve un niveau du versionnement d'origine (0) dû au changement d'indice

Au final le nombre de versions dont je dispose d'un équipement est égal à la somme des versions des schémas d’une MOD

Je voudrais bien proposer le MCD global de l'application mais j'ai peur qu'il fasse mal aux yeux...et je réfléchis encore à une solution pour l'historisation des schémas

[JPhi33]

Bonjour Antonitzer,

Donc en effet je ne sais pas si je dois réellement faire un héritage ou si une association suffit, d'ailleurs comment choisir quel est le meilleur entre les deux ?

Une entité B "hérite" d'une entité A, lorsque B "est une sorte" de A. On dit formellement que B est une spécialisation de A (et que A est la généralisation de B). Par exemple, considérons les entités Véhicule, Vélo et Moto. On pourra dire que Vélo et Auto héritent de Véhicule puisque Vélo et Auto sont des sortes de Véhicule. Ces 3 entités partagent plusieurs propriétés (poids, couleur, etc.) mais Vélo et Auto ont aussi chacune des propriétés ou des associations spécifiques : cylindrée et type de carburant ne s'appliquent qu'à Auto, par exemple.

Donc dire que Schéma (Layout, Synoptique, Principe ou Wiring) hérite de MOD, c'est dire qu'un Schéma est une sorte de MOD. A toi de décider.

Donc en ce qui concerne [EquipementLayout]--0,n----( )---(1,1)-[EquipementLayoutHisto] ok donc EquipementLayoutHisto hérite de EquipementLayout sauf que la fille est identifiée par le couple (EquipementLayoutId, Timestamp)

Non, EquipementLayoutHisto est ce qu'on appelle une "entité faible" (ou fille). C'est ce que veulent dire les cardinalités 1,1 entre parenthèses. Cela signifie qu'elle est identifiée "relativement à" EquipementLayout qui est donc une entité forte (ou mère). Outre la différence sémantique, on a une différence technique en terme d'identification puisque dans le cas de l'héritage, l'identifiant est le même alors que l'entité faible possède un identifiant composé de l'identifiant de l'entité forte complété de son propre identifiant.

Exemple :

[ Personne ]<===[ Parent ]--1,n----( )---(1,1)-[ Enfant ]

(la flèche <=== est le symbole de la généralisation / spécialisation)

Un Parent "est une" Personne. Supposons que Personne soit identifiée par IdPersonne. Alors l'entité Parent est aussi identifiée par IdPersonne. Parent hérite de toutes les propriétés de Personne, y compris son identifiant. Une Personne n'est pas forcément un Parent.
Enfant est une entité faible de Parent, identifiée par Numéro_enfant. En conséquence, Enfant est identifiée par {IdPersonne, Numéro_enfant}.



A suivre

[Antonitzer]

D'accord je me suis un petit peu emmêlé les pinceaux...

Alors vu que HistoriqueEquipement est une sorte d'Equipement avec en plus une notion d'antériorité dans ce cas il est préférable que j'opte pour l'héritage

J'associe ma table Equipement avec ma table Affaire étant donné que mes Equipement sont unique à l'affaire.

donc si je créer deux tables LayoutBlocEquipement et SynoptiqueBlocEquipement (éléments graphiques appartenants aux schémas Layout et Synoptique) est-ce que je dois associer ces tables à Equipement ou a HistoriqueEquipement ?

Merci pour l'aide

Bon après-midi

[JPhi33]

Bonsoir Antonitzer,

Alors vu que HistoriqueEquipement est une sorte d'Equipement avec en plus une notion d'antériorité dans ce cas il est préférable que j'opte pour l'héritage

Euh... non . HistoriqueEquipement est une entité faible de Equipement :

Non, EquipementLayoutHisto est ce qu'on appelle une "entité faible" (ou fille).

En effet, Pour une occurrence de l'entité Equipement, il y a plusieurs occurrences de l'entité EquipementHisto, laquelle est identifiée par le couple {Equipement_Id, Date historique Equipement}. Puisque tu choisis une historisation au moyen de deux tables, voici un exemple théorique.
Supposons que l'équipement 1 ait été modifié 3 fois. EquipementHisto contiendra 3 occurrences :

Code :

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

1
2
3
4
5
6
Equipement_Id Date_Histo_Equipement
------------- ---------------------
            1 31/03/2015            <-- Occurrence originale
            1 03/04/2015            <-- 1e modification
            1 07/04/2015            <-- 2e modification

La 3e modification a produit l'occurrence courante qui se trouve dans Equipement.

Un point important pour le niveau physique. Selon le SGBD utilisé, il peut ne pas être judicieux qu'une date fasse partie de la clé. Dans ce cas, il est préférable d'identifier la table historique au moyen d'un numéro et de placer la date en attribut.

Code :

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

1
2
3
4
5
6
Equipement_Id Numéro_histo Date_Histo_Equipement
------------- ------------ ---------------------
            1            1 31/03/2015            <-- Occurrence originale
            1            2 03/04/2015            <-- 1e modification
            1            3 07/04/2015            <-- 2e modification

[Antonitzer]

Bonsoir Antonitzer,


Euh... non . HistoriqueEquipement est une entité faible de Equipement :

Sûr, sûr ? Parce que je ne veux pas juste reporter toutes les dates auxquelles il a été modifiée mais je veux pouvoir restaurer les anciennes versions d'un Equipement.

Un point important pour le niveau physique. Selon le SGBD utilisé, il peut ne pas être judicieux qu'une date fasse partie de la clé. Dans ce cas, il est préférable d'identifier la table historique au moyen d'un numéro et de placer la date en attribut.

Par défaut je mets toujours en identifiant primaires des attributs non significatifs, comme me l'a appris votre collègue fsmrel dans un autre post.


Merci pour le conseil.

[ZenZiTone]

Sûr, sûr ? Parce que je ne veux pas juste reporter toutes les dates auxquelles il a été modifiée mais je veux pouvoir restaurer les anciennes versions d'un Equipement.

HistoriqueEquipement n’hérite pas d'Equipement car il n'en est pas un spécialisation. L'exemple souvent utilisé pour l'héritage : une entité "Employé" qui hérite de l'entité "Personne". Un employé est une Personne (nom, prénom, etc) ayant des propriétés en plus (entreprise, poste, salaire, etc).

Je ne suis même pas sur qu'il faille modéliser les entités de type "historique" dans un MCD.

[Antonitzer]

Je ne suis même pas sur qu'il faille modéliser les entités de type "historique" dans un MCD.

J'avais vu sur d'autre post que l'historisation se note avec un "(H)" dans le nom de la table au niveau du MCD. Mon problème est que ces historisations ont des impacts forts sur d'autres entités de ma base (historisation d'autres objets), je dois donc faire apparaître de manière plus détaillée cette possibilité dans mon MCD afin de pouvoir évaluer si la base que je propose au final permet de répondre aux besoins du client.

Dans le cas ou l'historisation n'apparaît pas encore dans un MCD, à partir de quand est-ce qu'on la représente ??

Merci pour exemple

[ZenZiTone]

J'avais vu sur d'autre post que l'historisation se note avec un "(H)" dans le nom de la table au niveau du MCD. Mon problème est que ces historisations ont des impacts forts sur d'autres entités de ma base (historisation d'autres objets), je dois donc faire apparaître de manière plus détaillée cette possibilité dans mon MCD afin de pouvoir évaluer si la base que je propose au final permet de répondre aux besoins du client.

Dans le cas ou l'historisation n'apparaît pas encore dans un MCD, à partir de quand est-ce qu'on la représente ??

Merci pour exemple

Je dirais dans le MPD (Modèle Physique des Données), quand tu modélises la base de données tel qu'elle sera crée physiquement. Après, si tu estimes qu'il est intéressant de le montrer à ce niveau, il faut le faire. Du coup il faut regarder du coté des entités faibles mentionnées par JPhi33.

[Antonitzer]

Ok dans ce cas je vais voir pour modéliser cela avec mes entités faibles. Je reviens dés que j'ai une proposition aboutie

Merci pour tes conseils ZenZiTone