Discussion :

[BlueBeery]

Bonjour,

Je suis actuellement en stage et je dois mettre en place un schéma permettant de servir de base à la mise en place d'une base de données de gestion de parc digital chez des clients. Cet exercice étant nouveau pour moi j'ai effectué plusieurs recherches (notamment sur le forum) et utilisé lucidchart afin de créer un premier schéma :



J'aimerais avoir des retours, critiques et conseils afin d'amiliorer / compléter celui-ci !
Je suis à votre disposition pour toute question.

[fsmrel]

Bonjour BlueBeery,

Votre diagramme est lisible, mais attention, vous vous mélangez les pinceaux avec les clés étrangères. Par exemple dans la table SITE, {batiment_id} est à tort clé étrangère et fait référence à BATIMENT : ça va coincer dans la réalisation…
Par ailleurs la définition des concepts serait la bienvenue, par exemple qu’est-ce qu’un SLA ? Et plus généralement fournir les règles de gestion.

Je vous engage à modéliser au niveau conceptuel, et pour ça à utiliser Looping, gracieusement proposé par le professeur Patrick Bergougnoux (encore grand merci Paprick !)

[BlueBeery]

Bonjour BlueBeery,

Votre diagramme est lisible, mais attention, vous vous mélangez les pinceaux avec les clés étrangères. Par exemple dans la table SITE, {batiment_id} est à tort clé étrangère et fait référence à BATIMENT : ça va coincer dans la réalisation…
Par ailleurs la définition des concepts serait la bienvenue, par exemple qu’est-ce qu’un SLA ? Et plus généralement fournir les règles de gestion.

Je vous engage à modéliser au niveau conceptuel, et pour ça à utiliser Looping, gracieusement proposé par le professeur Patrick Bergougnoux (encore grand merci Paprick !)

Bonjour fsmrel,
En effet, j'ai un peu de mal à saisir le concept de clé étrangère. Dans l'exemple que vous citez, dans la table SITE, en quoi la présence de la clé étrangère batiment_Id est t'elle problématique ?
La table BATIMENT étant parent de la table SITE (site dans le sens géographique du terme), un bâtiment pouvant exister sans site, mais un site ne pouvant exister sans au moins un bâtiment.

[fsmrel]

en quoi la présence de la clé étrangère batiment_Id est t'elle problématique ?

Une valeur de clé étrangère (FK) fait référence à une et une seule valeur de clé (primaire ou alternative, mais disons primaire pour faire court). Dans la table SITE, la clé étrangère {batiment_Id} fait référence à la clé primaire {batiment_Id} de la table BATIMENT : pour un site il n’y a donc qu’un et un seul bâtiment, ce qui est contradictoire avec ce qui est représenté dans votre diagramme, selon lequel un site fait l’objet de un à plusieurs bâtiments. Notez que je mets le terme batiment_Id entre accolades, car {batiment_Id} est un ensemble au sens de la théorie des ensembles, laquelle utilise les accolades.


En passant, chaque table doit être dotée d’une clé candidate (primaire pour faire court), sinon c’est mathématiquement non pas un ensemble mais un sac (bag). C’est le cas des sacs SLA, TYPE_ASSEMBLAGE, ETAT, TYPE_MAT, DETAIL_MAT, DETAIL_STATUT, etc.


Je vais continuer à examiner votre diagramme, mais pensez à passer à Looping !

[fsmrel]

Examinons l’association entre la table SOCIETE et le sac STATUT_SOCIETE :

Vous utilisez le verbe ÊTRE pour qualifier cette association, mais une société n’est pas un statut (pas plus qu’un statut n’est une société) : c’est plutôt le verbe AVOIR qui est de mise, en effet une société a un statut.

Par ailleurs, selon votre diagramme une société aurait au moins un statut, et au plus plusieurs. Ceci est contestable dans la mesure où, que je sache, à un instant donné une société n’a qu’un statut.

STATUT_SOCIETE doit devenir une table, et sa clé primaire (non significative, invariante) doit être référencée par une clé étrangère mise en oeuvre dans la table SOCIETE. La clé primaire de la table STATUT_SOCIETE doit être accompagnée d’une clé alternative (significative, modifiable) hébergeant les valeurs "Holding", "Filiale", "Indépendante" dont vous faites mention.

La table STATUT_SOCIETE est du genre de ce qu’on qualifie traditionnellement et informellement de « table de codes ». Les sacs que vous avez représentés doivent devenir à leur tour des tables de codes…

A suivre

[escartefigue]

Bonjour BlueBeery

Faute de règles de gestion explicites, de nombreuses questions se posent.

Est-il normal qu'un site puisse appartenir à plusieurs sociétés ? Si c'est le cas, alors la FK société ne peut pas faire partie de la table site, il faut une table de correspondance entre site et société
Est-il normal qu'un bâtiment puisse n'appartenir à aucun site : bâtiment "hors sol" , de quoi s'agit il ?
Les cardinalités entre pièce et type de pièces semblent inversées
Toute la partie qui unit utilisateur, pièce et assemblage nécessite des explications.
Liste non exhaustive

Et comme l'a indiqué Fsmrel, un schéma conceptuel (le MCD) est autrement plus parlant qu'un modèle tabulaire.
Commencer par le MCD est fortement recommandé, le MLD qui en découle s'obtient en un clic avec un logiciel Ad hoc (tel que Looping que je recommande sans retenue )

[BlueBeery]

Je vais continuer à examiner votre diagramme, mais pensez à passer à Looping !

Merci de vos réponses ! je ne peux pas passer sur looping pour le moment, travaillant sur des ordinateurs d'entreprise (droit d'administrateur, etc.) et lucidchart me permet de réaliser n'importe quel type de schéma.

Je vais donc me pencher sur la mise en forme MCD de mon schéma ainsi que revoir certaines cardinalités afin de repartir sur une base saine. Tout cela étant nouveau pour moi, je m'y suis mélangé les pinceaux en voulant aller trop vite !


Je reviens vers vous une fois cela tiré au clair.

[fsmrel]

je ne peux passer sur looping pour le moment, travaillant sur des ordinateurs d'entreprise (droit d'administrateur, etc ...

Comme Laurent, vous êtes empêché puisque vous utilisez des ordinateurs de l’entreprise, et c'est bien dommage :

Malheureusement, pas possible d'installer Looping sur mon PC de boulot, donc je continue avec Workbench

Mais Laurent est arrivé à utiliser Looping, qu’il qualifie même d’« outil génial » et en est devenu un fan ! Et il a découvert la modélisation conceptuelle en étudiant l’ouvrage de Paprick. A votre tour n’hésitez pas à en faire autant, tranquillement, chez vous, et même dans le métro (c’est là et dans le bus, en me rendant au boulot, que je me suis plongé dans la théorie relationnelle, il y a quarante ans...)

[Jipété]

HS

Bonjour,

le titre m'a heurté et, en grand redresseur des torts, je ne peux m'empêcher d'intervenir, histoire de rétablir la vérité et défendre notre français bien mal en point au fur et à mesure que le temps passe :

source
L'article n'est pas long et on y trouve des informations intéressantes.

Et pour ceux qui sont allergiques à Wikipédia, le Robert précise la "recommandation officielle" de cet anglicisme mal venu et de plus en plus utilisé à tort et à travers :

source

PS : encore 24 h environ pour éditer le 1^er post et son titre erroné, après, c'est fichu…

/HS

[BlueBeery]

PS : encore 24 h environ pour éditer le 1^er post et son titre erroné, après, c'est fichu…

/HS

Titre modifié même si je reste largement en désaccord, la langue française est vivante, les mots et définitions ne sont pas gravés dans le marbre

[BlueBeery]

Bonjour,

Je reviens enfin vers vous après une mise au propre sous forme MCD du schéma :



Quelque précisons :
-Le but est la création d'un modèle de base de données permettant la gestion de parc numérique existant chez plusieurs clients.
-Le modèle comportera plus tard une partie gestion d'incident.
-Le contenu de chaque table est relativement volatile (je rajoute/ change leurs contenus aux grès des discussions avec mon maître de stage, cependant je suis ouvert à toutes propositions de rajout ! )
-Je n'arrive pas à intégrer la table "DETAIL_STATUT" qui viens détailler le statut actuel sur un matériel ou un assemblage.

[escartefigue]

Bonjour Bluebeery

Votre modèle est riche, il y a beaucoup d'entités-types et associations.
Avant d'établir un modèle exhaustif, il est préférable de se concentrer sur le coeur de métier, la partie stratégique.
Rédigez les règles de gestion relatives à cette partie et communiquez la sous-partie du MCD correspondante.
Une fois ce sous-ensemble stabilisé, on pourra s'intéresser à un autre, puis on assemblera les morceaux

[fsmrel]

Bonjour,


BlueBeery, vous avez proposé un MCD, bel effort.

Une question : qu’est censé représenter le losange sur lequel sont greffées les entités-types SOCIETE, CLIENT, FOURNISSEUR, CONSTRUCTEUR ? Une spécialisation de SOCIETE ?

On s’interroge sur le sens à donner aux ronds sur lesquels sont branchées des pattes porteuses de cardinalités 1,1 (par exemple le rond connectant SUIVI_MAT et SUIVI_GARNANTIE).

Quelle signification donner à ce que vous nommez « points d’extension » dans les associations ?

Je n'arrive pas à intégrer la table "DETAIL_STATUT" qui viens détailler le statut actuel sur un matériel ou un assemblage.

Au stade MCD, DETAIL_STATUT n’est pas une table mais une entité-type (alias classe d’entités). Quelle règle de gestion gouverne l’hypothétique association entre MATERIEL et DETAIL_STATUT ?

[BlueBeery]

Bonjour,
J'ai suivi ces 2 tutoriels :

ainsi que quelque autre ressource en ligne.

Une question : qu’est censé représenter le losange sur lequel sont greffées les entités-types SOCIETE, CLIENT, FOURNISSEUR, CONSTRUCTEUR ? Une spécialisation de SOCIETE ?

Le losange représente une relation d'héritage (je vais changer le symbole car en effet ce n'est pas le bon).

On s’interroge sur le sens à donner aux ronds sur lesquels sont branchées des pattes porteuses de cardinalités 1,1 (par exemple le rond connectant SUIVI_MAT et SUIVI_GARNANTIE).

Ce sont des CIF.

Quelle signification donner à ce que vous nommez « points d’extension » dans les associations ?

Aucune signification, je ne peux juste pas supprimer ce champ ...

Au stade MCD, DETAIL_STATUT n’est pas une table mais une entité-type (alias classe d’entités). Quelle règle de gestion gouverne l’hypothétique association entre MATERIEL et DETAIL_STATUT ?

Le but de DETAIL_STATUT pour les utilisateurs finaux est de pouvoir détailler via une description le statut d'un matériel ou d'un assemblage => ex : MATERIEL = PC portable, STATUT = En panne, DETAIL_STATUT = Ecran fissuré et port usb c non fonctionnel.

[fsmrel]

Bonjour,

Le but de DETAIL_STATUT pour les utilisateurs finaux est de pouvoir détailler via une description le statut d'un matériel ou d'un assemblage => ex : MATERIEL = PC portable, STATUT = En panne, DETAIL_STATUT = Ecran fissuré et port usb c non fonctionnel.

Il va falloir préciser les règles de gestion. Commençons doucement...

1 - Un statut a-t-il au moins un détail ?

2- Considérez-vous DETAIL_STATUT comme entité-type autonome (ou faible par rapport à STATUT) ? Cette question n’est pas a priori fondamentale, mais on verra par la suite. Sémantiquement parlant au moins, un détail n'est jamais que la propriété d'un statut.

3 - Je suppose qu’un détail concerne aussi bien un matériel qu’un assemblage, mais il est possible que tel détail soit pertinent pour un matériel mais pas pour un assemblage ou soit pertinent pour un assemblage mais pas pour un matériel. Votre position ?

A suivre.

[BlueBeery]

J'ai décomposé le tout en 4 sous partie.

- Une partie Bâtiment :

RG_BAT_001 : Une société possède de 1 à n bâtiment / Un bâtiment peut appartenir de 1 à n société.


RG_BAT_002 : Un site possède de 0 à n contrainte_site /Une contrainte_site est présente de 0 à n site.
RG_BAT_003 : Un site possède de 1 à n type_site /Un type_site est présent de 0 à n site.
RG_MAT_004 : Une société possède de 0 à n site / un site appartient de 1 à n société.

RG_BAT_005 : Un bâtiment appartient de 0 à 1 site / Un site contient de 1 à n bâtiment.
RG_BAT_006 : Un bâtiment possède de 0 à n contrainte_bâtiment /Une contrainte_bâtiment est présente de 0 à n bâtiment.
RG_BAT_007 : Un bâtiment possède de 0 à n étage /Un étage est présent dans 1 bâtiment.

RG_BAT_008 : Un étage possède de 0 à n piéce /Une pièce est présent dans 1 étage.

RG_BAT_009 : Une pièce possède de 0 à n contrainte_pièce / Une contrainte_pièce est présente de 0 à n pièce.
RG_BAT_010 : Une pièce possède de 1 à n type_pièce /Un type_piéce est présent de 0 à n pièce.
RG_BAT_011 : Une pièce possède de 0 à n matériel /Un matériel est présent de 0 à 1 pièce.
RG_BAT_012 : Une pièce possède de 0 à n assemblage /Un assemblage est présent dans 1 pièce.



- Une partie Matériel :

Un matériel correspond à une entité commandé chez le fournisseur (un ordinateur, un portable, projecteur, etc ....), on peut choisir ou non de détailler un composant sous forme de matériel.
Un assemblage regroupe un ensemble de matériaux et peut se référer à lui même, exemple = un assemblage "poste de travail" fait parti de l'assemblage "Serveur".

RG_MAT_001 : Un matériel possède de 1 à n marque / Une marque possède de 0 à n matériel.
RG_MAT_002 : Un matériel possède de 0 à n documentation / Une documentation réfère de 0 à n matériel.
RG_MAT_003 : Un matériel possède de 0 à n composant (pas besoin de détailler les composants d'une bouilloire par exemple) / un composant appartient de 1 à n matériel ( on peut retrouver la même carte graphique dans plusieurs PC).
RG_MAT_004 : Un matériel est 1 type_matériel / un type_matériel englobe de 0 à n matériel.
RG_MAT_005 : Un matériel a 1 statut / Un statut engolbe de 0 à n matériel. RG_MAT_015 : De même pour assemblage. Ces associations ont pour attributs le détail du statut.
RG_MAT_006 : Un matériel appartient de 0 à 1 assemblage / Un assemblage comporte de 2 à n matériel.
RG_MAT_007 : Un matériel est dans 1 état / Un état englobe de 0 à n matériel.
RG_MAT_008 : Un matériel a de 0 à n utilisateur / un utilisateur utilise de 0 à n matériel. RG_MAT_016 : De même pour assemblage.
RG_MAT_009 : Un matériel a de 1 à n technicien / un technicien à de 1 à n matériel. RG_MAT_017 : De même pour assemblage.
RG_MAT_010 : Un matériel appartient à 1 parc / un parc possède de 1 à n matériel.

RG_MAT_011 : un composant est ou n'est pas 1 matériel / un matériel est ou n'est pas un composant.

RG_MAT_012 : Un assemblage appartient à 1 parc/ un parc possède de 0 à n assemblage.
RG_MAT_013 : Un assemblage contient de 0 à n assemblage / un assemblage appartient de 0 à 1 assemblage.
RG_MAT_014 : Un assemblage possède de 1 à n type_assemblage / Un type_assemblage englobe de 0 à n assemblage.

L'ensemble des "SUIVI_xxx" et OPERATION sont des CIF de matériel.


Je pense à peut être ajouter un type de matériel et assemblage privée/publique.





Je détaillerais plus tard les 2 parties suivante :

- Une partie socété :



- Une partie Gestion :



éditer suite au recommandation de fsrmel

[fsmrel]

Bel effort, je clique sur le pouce vert. D’accord pour l’urbanisation de votre MCD en domaines distincts (Bâtiments, Matériels, etc.)

Je regarde le domaine Matériels puisqu’on a commencé avec lui (l’histoire des détails des statuts).

Vous avez rédigé les règles de gestion fondamentales, excellente initiative. Je vous suggère de les numéroter (par exemple sous la forme RG_MAT_001, etc. pour les matériels), afin de pouvoir plus facilement y faire référence en cas de besoin.

Cas des abréviations : merci de préciser ce dont il s’agit ("CG", "CI" ça n’est pas très causant…)

Bon je vais regarder tout ça.

N.B. La couleur rouge sombre empêche de voir le nom des entités-types…

[escartefigue]

Bonjour,

Merci d'avoir accédé à ma requête en découpant le modèle en blocs fonctionnels, c'est bien plus facile à lire.

Que signifie la mention "points d'extension" répétée dans les différentes associations ?

Pour la partie bâtiment

Comme le bâtiment peut avoir zéro à plusieurs étages, certains bâtiments n'ont aucun étage et donc aucune pièce, est-ce normal ?
L'étage est une entité-type faible du bâtiment et la pièce est une entité-type faible de l'étage, vous pouvez donc utiliser l'identification relative :
BA_BATIMENT 1,n --- BA_ET --- 1,1(R) ET_ETAGE 1,n --- ET_PC --- 1,1(R) PC_PIECE


Pour la partie matériel
MATERIEL et SUIVI_MAT sont en relation 1,1 de part et d'autre, vous pouvez les fusionner.
Idem concernant SUIVI_GARANTIE et SUIVI_FINANCE

La cardinalité maxi n de MATERIEL vers MARQUE est surprenante : un même matériel peut avoir plusieurs marques ?

ETAT_MATERIEL, s'il n'est connu qu'au travers d'un code (1 pour neuf à 6 pour cassé) ne nécessite pas une entité-type, vous pouvez rapatrier cet attribut dans l'entité-type matériel et, au niveau SQL, créer une contrainte check vérifiant la plage de valeurs. Si par contre vous associez ce code à un libellé ou d'autres attributs, pourquoi pas.

Même remarque concernant STATUT

Que signifient les attributs nommés liste_xxx (ex : liste_type_mat), un attribut ne doit jamais contenir une liste de valeurs

COMPOSANT, s'il s'agit d'établir une nomenclature composant/composé des MATERIELs, alors la modélisation doit être une association réflexive sur MATERIEL.

[BlueBeery]

Que signifie la mention "points d'extension" répétée dans les différentes associations ?

Comme dit précademment je ne peut enlever ce texte sur mon logiciel (ne pas y faire attention donc).

Pour la partie bâtiment

Comme le bâtiment peut avoir zéro à plusieurs étages, certains bâtiments n'ont aucun étage et donc aucune pièce, est-ce normal ?

Oui, on peut très bien imaginer qu'une société soit juste domicilié à une adresse sans pour autant y avoir des bureaux, ou encore que l'on veuille juste enregistrer l'adresse d'une société potentiellement cliente dans le futur. Je me demande donc si une table adresse ne serait pas pertinente ?...

L'étage est une entité-type faible du bâtiment et la pièce est une entité-type faible de l'étage, vous pouvez donc utiliser l'identification relative :
BA_BATIMENT 1,n --- BA_ET --- 1,1(R) ET_ETAGE 1,n --- ET_PC --- 1,1(R) PC_PIECE

En effet, c'est ajouté !

La cardinalité maxi n de MATERIEL vers MARQUE est surprenante : un même matériel peut avoir plusieurs marques ?

Oui, il arrive qu'un produit soit issu du travail de plusieurs marques.

ETAT_MATERIEL, s'il n'est connu qu'au travers d'un code (1 pour neuf à 6 pour cassé) ne nécessite pas une entité-type, vous pouvez rapatrier cet attribut dans l'entité-type matériel et, au niveau SQL, créer une contrainte check vérifiant la plage de valeurs. Si par contre vous associez ce code à un libellé ou d'autres attributs, pourquoi pas.

Même remarque concernant STATUT

Que signifient les attributs nommés liste_xxx (ex : liste_type_mat), un attribut ne doit jamais contenir une liste de valeurs

Faut il évité d'avoir des tables ne contenant q'un id et un attribut constitué d'une liste de valeur récurrente dans une autre table ? il me semblait avoir vu dans la documentation MERISE que par normalisation, si une valeur revenait de manière récurrente dans une table, la création d'une nouvelle table était conseillée ... j'aurais bien besoin d'explication sur ce point !

COMPOSANT, s'il s'agit d'établir une nomenclature composant/composé des MATERIELs, alors la modélisation doit être une association réflexive sur MATERIEL.

L'idée derrière la table COMPOSANT est de pouvoir lister les composants de MATERIEL si nécessaire / pertinent, et de pouvoir les décrire comme des MATERIELS si nécessaire / pertinent. Si "j'intègre" la table composant en une association réflexive sur MATERIEL, alors je vais devoir déclarer chaque composant comme un nouveau MATERIEL, même si ce composant existe déjà dans ma base de données. Exemple : j'ai une dizaine de PC dans ma table MATERIEL, chaque PC possède un processeur identique proc1 que je trouve pertinent de lister dans la table COMPOSANT (une seule ligne dans cette table donc), cependant pour un de ses PC, j'ai besoin de détailler proc1 comme un MATERIEL pour x raison. Dans le cas d'une association réflexive sur MATERIEL, j'ai du mal à visualiser la chose

Pour la partie matériel
MATERIEL et SUIVI_MAT sont en relation 1,1 de part et d'autre, vous pouvez les fusionner.
Idem concernant SUIVI_GARANTIE et SUIVI_FINANCE

Surtout si je fusionne ces tables ensemble

[escartefigue]

Comme dit précademment je ne peut enlever ce texte sur mon logiciel (ne pas y faire attention donc).

Désolé je n'avais pas vu l'explication plus haut. OK c'est noté

Faut il évité d'avoir des tables ne contenant q'un id et un attribut constitué d'une liste de valeur récurrente dans une autre table ? il me semblait avoir vu dans la documentation MERISE que par normalisation, si une valeur revenait de manière récurrente dans une table, la création d'une nouvelle table était conseillée ... j'aurais bien besoin d'explication sur ce point !

Ca dépend
Si la typologie est utilisée plusieurs fois, il est préférable de modéliser un type d'entité qui deviendra une table. C'est le cas par exemple des codes pays qui peuvent être en lien avec les clients (pays de domiciliation fiscale par exemple), les adresses (pays de l'adresse), les produits (pays de fabrication) ou d'autres types d'entité.
Si la typologie est associée à d'autres attributs : libellé long, libellé court, date de début de validité, date de fin de validité... il est également nécessaire de créer un type d'entité.
Si la typologie ne sert qu'une seule fois et qu'on a seulement une liste de valeurs permises, alors un type d'entité n'apporte rien.

L'idée derrière la table COMPOSANT est de pouvoir lister les composants de MATERIEL si nécessaire / pertinent, et de pouvoir les décrire comme des MATERIELS si nécessaire / pertinent. Si "j'intègre" la table composant en une association réflexive sur MATERIEL, alors je vais devoir déclarer chaque composant comme un nouveau MATERIEL, même si ce composant existe déjà dans ma base de données. Exemple : j'ai une dizaine de PC dans ma table MATERIEL, chaque PC possède un processeur identique proc1 que je trouve pertinent de lister dans la table COMPOSANT (une seule ligne dans cette table donc), cependant pour un de ses PC, j'ai besoin de détailler proc1 comme un MATERIEL pour x raison. Dans le cas d'une association réflexive sur MATERIEL, j'ai du mal à visualiser la chose

Si les attributs d'un matériel et d'un composant sont proches, on peut n'avoir qu'une seule entité-type.
On peut ensuite utiliser la spécialisation pour ajouter les attributs spécifiques à certains sous-types.
Dans l'association, on trouvera un attribut quantité mentionnant combien de fois le composant est utilisé dans le composé.

Voici un exemple de MCD :
Pièce jointe 600585

Et le script DDL correspondant (ici décliné pour SQL server) :

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
CREATE TABLE MA_materiel(
   MA_ident INT IDENTITY,
   MA_reference CHAR(8) NOT NULL,
   MA_description VARCHAR(50) NOT NULL,
   PRIMARY KEY(MA_ident),
   UNIQUE(MA_reference)
);
 
CREATE TABLE BO_boitier(
   MA_ident INT,
   PRIMARY KEY(MA_ident),
   FOREIGN KEY(MA_ident) REFERENCES MA_materiel(MA_ident)
);
 
CREATE TABLE CA_carte(
   MA_ident INT,
   CA_RAM SMALLINT NOT NULL,
   PRIMARY KEY(MA_ident),
   FOREIGN KEY(MA_ident) REFERENCES MA_materiel(MA_ident)
);
 
CREATE TABLE AL_alim(
   MA_ident INT,
   AL_puissance DECIMAL(5,2) NOT NULL,
   AL_tension_entree DECIMAL(5,2) NOT NULL,
   AL_tension_sortie DECIMAL(5,2) NOT NULL,
   PRIMARY KEY(MA_ident),
   FOREIGN KEY(MA_ident) REFERENCES MA_materiel(MA_ident)
);
 
CREATE TABLE EQ_equiper(
   MA_ident_composé INT,
   MA_ident_composant INT,
   EQ_quantite SMALLINT NOT NULL,
   PRIMARY KEY(MA_ident_composé, MA_ident_composant),
   FOREIGN KEY(MA_ident_composé) REFERENCES MA_materiel(MA_ident),
   FOREIGN KEY(MA_ident_composant) REFERENCES MA_materiel(MA_ident)
);

Bien évidemment, chaque composant ne sera enregistré qu'une seule fois, c'est l'attribut quantité de l'association qui permet de savoir combien de fois on associe tel composant à tel autre (autre composant qui peut lui même être un composant d'un autre...)