Bonjour,  
 
je suis en train de me pencher sur la mise en place d'une base de données sur access pour ma boîte, mais je n'arrive pas à concrétiser le MCD.  
 
Il s'agit de raccordement en fibre optique d'abonnés. Je part d'une entité "Boîte de Raccordement" (qui peut regrouper 10 abonnés) pour arriver sur une entité "Noeud de Raccordement" (qui regroupe 300 abonnés).  
Le problème est que un NRO peut être soit actif, auquel cas on se branche directement d'un port de switch sur un bandeau de fibre (4 attributs: N° actif, N° port, N° tiroir FO, N° fibre).  
Soit il est passif et dépend d'un NRO actif. Voir le schéma ci-dessous.  
 
CAS ACTIF  
-NRO N°1 ------------------> Boite Racco N°1  
Actif A //////////////////////////la fibre du tiroir est raccordée à la boite deracco  
Port 10  
Tiroir 3  
Fibre 12 ( on relie l'actif au tiroir)  
 
CAS PASSIF  
- NRO N°1 ------------------------>NRO N°2------------------> Boite Racco N°2  
Actif A /////////////////////////////////Tiroir 1  
Port 11 ////////////////////////////////Fibre 1 (transport aval)  
Tiroir 2 /////////////////////////////////Tiroir 2  
Fibre 2 ////////////////////////////////Fibre 1 (vers boite racco)  
(on relie l'actif au tiroir pour  
le transport en amont)  
 
 
Comment relier les entités boite racco et NRO?  
Merci de me donner vos idées car je sèche...  

Là comme ça, je m'inspirerais de ce que le soft GLPI a fait avec la notion de connexion directe ou via réseau :
- une table pour les liaisons directes NRO actif-boîte racco,  
- une table pour les liaisons NRO passif-NRO actif.
 
Une autre solution possible est de faire 2 entités NRO, une pour les actifs et l'autre pour les passifs, les passifs ayant en clé étrangère un ID de NRO actif.

Je n'ai pas compris ta première solution, qu'est-ce que le soft GLPI et les connexion directes et via réseau?
 
J'ai étudié la deuxième solution, elle me paraît très cohérente et résoudrerais ma problématique. Mais dans ce cas, ma table boite de racco se retrouve avec 2 clés étrangères: N°NROActif et N°NROPassif.  
Dans le cas d'un raccordement actif, une clé étrangère doit être nulle (N°NROPassif): est-ce gérable dans une base de données? si oui est-ce souhaitable?

oui, une clé étrangère peut être nulle dans le cas de relations 0-1.
 
Par contre, si j'ai bien compris, à un NRO est associé 1 ou plusieurs boîtiers de raccordement. J'avais compris l'inverse tout à l'heure
 
Perso, je pense que ma première solution est préférable. Google pour savoir ce qu'est le soft GLPI -> gestion de parc informatique.
Donc, à une machine, on peut connecter en direct des périphs (écran, clavier...) et en "indirect", via des connexions réseaux, d'autres "choses" : imprimantes réseau, montages NFS, déport KVM... C'est pour ça que je trouvait que cette modélisation collait à ton pb. Et GLPI résout ce pb avec 2 tables de connexions (i.e. de liaisons) : une pour les liaisons directes (dans ton cas, boîtier racco lié à NRO actif) et l'autre pour les indirectes (NRO passif à NRO actif). Du reste, cette 2ième table devrait être plus complexe que la première (la première aurait 3 champs, clé primaire, clé étrangère boîtier, clé étrangère NRO actif), celle-ci devant avoir les 2x4 attributs que tu as mentionnés pour gérer les notions de liaisons tiroir-fibre-port...

En fait cette deuxième solution me paraît compliquée. Car je me rend compte qu'il faut inclure en aval de la table NRO des tables Tiroirs et Actif. Puis de tiroir, une table fibre et de Actif, une table Port. De manière à retrouver à partir d'un port ou d'une fibre tout le process.
Si je fait ça, la table liaison indirecte aurait deux liaisons vers la même table NRO, ce qui est incompatible avec le modèle.
A ce stade autant me rabattre sur la première solution où je sépare les NRO actifs et les NRO Passifs.
Ce raisonnement est-il cohérent? Quels est le désavantage cette seconde solution?

 
Si t'as déjà commencé à coder avant d'avoir validé ton MCD, c'est une grave erreur et c'est trop tard pour poser ta question
 
Et je pense que t'as pas compris ma solution.
Table liaisons directes NRO-boîtier de racco : (ID, ID NRO, ID boîtier)   ID étant la clé primaire.
 
Table des liaisons indirectes NRO passifs-actifs :  
ID,  
ID NRO passif,  
NROpassifActifX,  
NROpassifPortX,  
NROpassifTiroirX,  
NROpassifFibreX
ID NRO actif,
NROactifTiroirX,
NROactifFibreX,
...
 
 
Autre solution à base d'une seule table :
ID,     (clé primaire)
ID lienIN    (clé NRO actif ou passif)
ID lienOUT   (clé NRO actif ou boîtier racco)
Nom branchementIN    (ex : actif A, port 11...)
Nom branchementOUT  (ex : tiroir 1, fibre 1...)
Type branchement   (NRO passif-NRO actif ou NRO actif-boîtier racco)
 
Le champ "Type" te permet de savoir le type de branchement que c'est et de faire les bonnes jointures sur les tables par la suite. En plus, c'est une solution générique et évolutive car tu pourrais gérer avec ça d'autres types de branchements

j'ai bien compris la solution. pour la solution à une seule table: comment un ID peut-il être relié à une entité OU à une autre?  
EX: ID lienOUT= liée à NRO actif OU à boîtier racco
un boitier est différent d'un NRO, donc se sont forcément des tables séparées...?
Ce qui me gêne pour la première solution, c'est que les attributs ne sont pas uniques. EX: NROActifTiroirX, un NRO possède plusieurs tiroirs.
(j'ai appris avec des modèles de ventes style une entité client n'a qu'un seul nom, qu'un seul numéro de tel...)
Ou mon raisonnement est-il faux?

Comme tu ne donnes pas la modélisation complète de ce qu'est un NRO, un boîtier de racco et les relations entre eux, je ne peux pas te donner la bonne implémentation.
 
Pour le coup des ID de NRO ou de boîtier, ne perd pas de vue que les champs "ID" (clés primaires ou étrangères donc) ne sont que des nombres, des entiers (dans la plupart des cas). Leur interprétation ne dépend donc que de toi et de ce que tu auras défini.

     
 
La première relation se fait entre l'ID 10, un NRO passif et l'ID 15, un NRO actif. La 2ième relation se fait entre le NRO actif 15 et le boîtier de racco 7. La 3ième relation se fait aussi entre un NRO actif 5 (qui n'est pas lié à un NRO passif) et un autre boitier de racco 2. La dernière relation se fait entre un NRO passif 9 et un NRO actif 2. Ce dernier, dans l'ex, n'est pas encore relié à un boîtier de racco. Suivant le champ "type lien" (en général, on prend le type "enum" et non "varchar" pour ce type de champ), la jointure (ie l'interprétation) qu'on fera avec les tables ne sera pas la même