Infrastructures d’un réseau de télécoms

Besoin de votre avis. :arf:

J’essaie de modéliser une application pour suivre la gestion (pas la maintenance) des équipements utilisés pour le fonctionnement (alimentation, etc…) des infrastructures d’un réseau de télécoms… En clair il faut suivre (traçabilité) l’utilisation des équipements en question.
Le réseau est réparti en zones de compétence (secteurs). Chaque zone de compétence abrite au moins un site d’exploitation.
[On considère (bien que ce ne soit pas le plus important) que les infrastructures du réseau sont de plusieurs types (ADM, BTS, URAD, Antennes SAT, etc…) et que type d’infrastructure est déployé une et une seule fois sur un site tandis qu’on peut retrouver plusieurs types sur un site. Par ailleurs, un site peut faire l’objet d’un incident (incendie, panne, coupure, …)]
On considère également le tableau suivant des équipements qui font l’objet de l’application :

Ateliers d’Energie	Equipements	Pièces et Composants
Energie Primaire	Compteurs ENEO	…
Energie Primaire	Systèmes Solaires	…
Energie Primaire	Groupes Electrogènes
Energie secondaire	Batteries Stationnaires	…
Energie secondaire	Bâti redresseurs	…
Energie tertiaire	Onduleurs	…
Energie tertiaire	Convertisseurs	…

Lorsque du matériel est acquis (soit un équipement, soit un composant), il est soit stocké en [magasin] soit installé sur un [site]. Il est lié à un fournisseur.

De façon plus explicite, un équipement (respectivement un composant lié à un équipement) est [situé] en magasin, en fonction (installé sur un site), en dépannage, au rebut (hors d’usage). Il peut aussi provenir (origine) soit d’un magasin (car il y a plusieurs sites de stockage), soit d’un autre site, soit du dépanneur.
Par ailleurs, un équipement peut remplacer ou être remplacé par un autre. On doit pouvoir en conserver la trace; on doit toujours savoir l’état d’un équipement, son statut de fonctionnement, ce qu’il est devenu depuis son acquisition.

Mon schéma (MCD) est le suivant:

Pièce jointe 208848

Merci pour votre aide!

Bonjour,

Votre modèle semble OK si ce n'est que vous avez mis très peu d'attributs et défini aucun format de données.

Dans les entités types qui font l'objet de sous-type, vous devriez ajouter une attribut de typage, par exemple dans le sur-type "equipement" ajouter "type_equipement"

Par contre, comment comptez vous vérifier qu'un type d'infra n'est installé qu'une seule fois pour une site ?

Citation:

---

Envoyé par escartefigue

Dans les entités types qui font l'objet de sous-type, vous devriez ajouter une attribut de typage, par exemple dans le sur-type "equipement" ajouter "type_equipement"

---

Pas du tout d'accord. Ce serait redondant !
En effet, la seule présence ou absence d'une jointure donne l'information. Il suffit donc de faire une vue avec des jointures externes de toutes les filles pour savoir de quoi on prale !

A +

Citation:

---

Envoyé par SQLpro

Pas du tout d'accord. Ce serait redondant !
En effet, la seule présence ou absence d'une jointure donne l'information. Il suffit donc de faire une vue avec des jointures externes de toutes les filles pour savoir de quoi on prale !

A +

---

Soit une jointure de 8 tables dans le cas des équipements et de leurs sous-type !
Alors qu'un attribut de typage ne requiert qu'un indicateur, char(1) par exemple

Citation:

---

Envoyé par escartefigue

Votre modèle semble OK si ce n'est que vous avez mis très peu d'attributs et défini aucun format de données.

---

Les données sont bel et bien formatées j'ai juste adapté la présentation pour tenir compte de l'espace.

Citation:

---

Envoyé par escartefigue

Dans les entités types qui font l'objet de sous-type, vous devriez ajouter une attribut de typage, par exemple dans le sur-type "equipement" ajouter "type_equipement"

---

N'y a-t-il pas un risque de redondance de données? Quoiqu'il en soit le schéma en lui-même me pose des problèmes de redondance...

Mon nouveau modèle est celui qui suit. Des idées de corrections s'il vous plait?

Pièce jointe 209950

J'ai considéré qu'un "device" ("équipement", "composant") peut "être transféré sur" un "emplacement" ('site', 'store',...), la date du transfert serait conservée et dans ce cas il serait "transféré de" un "emplacement", mouvement dont on conserverait également la date.

Par ailleurs, il est possible que le "composant" génère des tables filles tout comme l'"equipement". Comment gérer le double héritage "devices"----"equipement"----"equipement-fille"...?

Citation:

---

Envoyé par escartefigue

Soit une jointure de 8 tables dans le cas des équipements et de leurs sous-type !
Alors qu'un attribut de typage ne requiert qu'un indicateur, char(1) par exemple

---

Serait-ce même avec un char(1) cette solutions serait parfaitement incorrecte et cela pour plsuieurs raisons....

Comme invoqué ici :
http://www.developpez.net/forums/d15...e/#post8641204

je répète ce que j'ai déjà dit :

Si vous ajoutez votre colonne vous aurez 2 problèmes :
1) REDNDANCE vous augmentez le volume des données pour rien. Ceci sera contre performant
2) si vous avez fait une erreur de saisie (mettre un plat dans la catégorie vin), vous allez avoir, soit une "désynchronisation" des données, soit l'obligation de rajouter des déclencheurs supplémentaire pour gérer tous les cas de figure. Donc soit des données fausse, soit d’énorme pertes de performances !

Pensez juste au nombre de déclencheurs : 7 déclencheurs INSERT/UPDATE/DELETE sur les tables filles !
Bonjour les performances lors des insertions et changement de filles....
Enfin un code n'est pas un libellé. Si demain il à 27 filles quelle lettre utiliser ?

Au pire si c'est juste pour savoir la branche à prendre à la place d'une jointure externe à gauche on peut mettre un EXISTS das la vue.

A +

Nous avons déjà échangé sur ce point et mon point de vue est que :
- il faut évidemment adapter la taille du code, au nombre d'entrées distinctes possibles, une colonne smallint non signée par exemple permet déjà de stocker plus de 65000 valeurs
- dans le cas d'héritage où la mère ne peut exister sans une fille et inversement, on ne risque pas de déphasage entre le code entité et l'insertion dans la fille concernée (sauf en phase de mise au point du code SQL bien sur), et si le nombre de sous-type est important, il est quand même beaucoup plus performant de gérer un ou deux octets de typage, que de faire autant de jointures que de types de filles possible pour savoir à qui l'on a à faire.

J'ai pris en compte toutes vos remarques et je dois dire que j'ai bien évolué. Mais je reviens sur une inquiétude...

Citation:

---

Envoyé par escartefigue

Par contre, comment comptez vous vérifier qu'un type d'infra n'est installé qu'une seule fois pour une site ?

---

Comment structurer les triggers pour s'assurer qu'un type infrastructure ou d'emplacement n'est déjà utilisé?