meerdere relaties voor 1 primaire sleutel

[dbAnnelies]

Goeie dag,

Ik heb 3 tabellen:

tblGateway
GatewayID (PK)
...

tblEndpoint
EndpointID (PK)
GatewayID
...

tblSensor
SensorID (PK)
GatewayID
EndpointID
...

Meerdere endpoints spreken met 1 gateway, dus dit is een simpele 1 op meer relatie. meerdere senoren spreken met 1 endpoint, dus ook een 1 op meer relatie.
Maar er kunnen ook meerdere sensoren rechtstreeks communiceren met 1 Gateway. Dus plaats ik daar ook een 1 op meer relatie.

Toch krijg ik hier problemen mee. Ik moet kiezen tussen Enpoint of Sensor als ik een subgegevensblad wil aanmaken. ook het toevoegen van een nieuw record in mijn tblSensor krijg ik een foutmelding en kan ik niet verder omdat er een relatie gedefinieerd is tussen Gateway en Endpoint.

Hoe los ik dit op?

Bijkomende vraag: er kunnen maximaal 4 sensoren op 1 gateway of endpoint komen. kan je het maximale aantal van records definieren?

Alvast bedankt!

Annelies

 

[OctaFish]

Hoi Annelies,

Ik snap je redenatie niet helemaal, al was het maar omdat ik zelf meestal andersom denk:

Meerdere endpoints spreken met 1 gateway, dus dit is een simpele 1 op meer relatie. meerdere senoren spreken met 1 endpoint, dus ook een 1 op meer relatie.

Lees ik als:
1 Gateway spreekt met meerdere endpoints, 1 endpoint spreekt met meerdere senoren. En dat leidt dan tot:

tblGateway
GatewayID (PK)
...

tblEndpoint
EndpointID (PK)
GatewayID (FK)
...

tblSensor
SensorID (PK)
EndpointID (FK)
...

Je legt dus een lijn van
tblGateway --> tblEndpoint --> tblSensor. Allemaal één-op-veel relaties dus. Het kan ook zijn dat je eigenlijk een veel-op-veel relatie hebt tussen tblSensor en tblGateway. In taal: veel gateways spreken met veel sensoren. In dat geval kun je geen directe relatie leggen tussen tblGateway en tblSensor maar heb je een tussentabel nodig. In jouw geval: tblEndpoint. En dan zien de relaties er zo uit:

tblGateway
GatewayID (PK)
...

tblSensor
SensorID (PK)
EndpointID
...

tblEndpoint
EndpointID (PK)
GatewayID (FK)
SensorID (FK)
...

Omdat ik niet weet wat je precies opslaat in die tabellen, kan ik niet beoordelen welke variant je nodig hebt. Maar in die richting zou ik het zoeken!

 

[dbAnnelies]

In bijlage zie je wat ik precies bedoel. Een sensor kan dus aan 1 endpoint hangen, maar kan ook aan een gateway hangen. het is dus niet dat een sensor aan meerdere gateways kan hangen.

Misschien heb ik je hier mee iets meer duidelijkheid mee kunnen geven...

Annelies

 

[OctaFish]

't Is nog niet helemaal precies wat je bedoelt denk ik want ik mis de één-op-veel aanduidingen. In je plaatje zie ik allemaal unieke sensorennummers. Houdt dat in dat één sensor maar aan één apparaat kan hangen? Lijkt mij logisch trouwens, maar dat moeten we nog wel even vastleggen .
Kan één Gateway meerdere sensoren hebben? Zoiets schreef je in je eerste bericht. In dat geval zou je een aparte koppeltabel kunnen maken voor die records.
Zelf zou ik het denk ik zo oplossen: als een Gateway een koppeling moet hebben met Sensoren, én/of een Endpoint, dan zou ik één tabel gebruiken voor koppeling van Sensor met apparaat. Dat apparaat kan dan een GW of een EP zijn. In beginsel heb je die tabel dus al. Daarbij hoef je namelijk alleen maar een EP record aan te maken voor de Gateway. Je krijgt dan dus eigenlijk een EP record voor de Gateway dat niet nodig is want de Gateway hééft eigenlijk geen Endpoint nodig. Maar dat record heb je dus nodig om te koppelen met de sensor.
Dus: het maakt in beginsel niet uit of een GW géén endpoint heeft of niet: elke GW krijgt minimaal één record in de tabel tblEndPoint. En op basis van dat record maak je dan de koppeling met Sensor. Dat wordt dan dus een nieuwe tabel waarin je EndPoints koppelt met Sensoren. Iets als:

tblGateway
GatewayID (PK)
...

EndpointID (PK)
SensorID (PK)
...

tblEndpoint
EndpointID (PK)
GatewayID (FK)
...

tblEndpoint_Sensor
Endpoint_SensorID (PK)
EndpointID (FK)
SensorID (FK)
...

 

[dbAnnelies]

Ik heb gisteren er mijn hoofd over gebroken, maar begrijp je redenering niet goed...

1 sensor kan inderdaad maar gegevens doorsturen naar ofwel een 1 gateway ofwel een 1 endpoint.

1 gateway kan rechtstreeks gegevens ontvangen van max. 4 sensoren.

1 gateway kan rechtstreeks gegevens ontvangen van meerdere endpoints die op hun beurt rechtstreeks gegevens ontvangen van max. 4 sensoren.

Volgens jouw redenering verzamel je dus de gegevens van de endpointID en SensorID in 1 tabel, maar je doet niets met die tabel... of heb ik het verkeerd?

Annelies

 

[OctaFish]

Ik zou dus één tabel gebruiken voor de sensor links. Ongeacht of die link met een Endpoint of met een Gateway is. In het geval dat je de sensor aansluit op een Gateway, zou ik tóch voor die gateway één Endpointrecord aanmaken. Elke gateway heeft dus tenminste één Endpointrecord. Op die manier heb je een consistente koppeling tussen de verschillende sensoren en waar ze aan hangen.

 

[dbAnnelies]

dan heb je in principe die tussentabel niet nodig. de sensor spreekt met de endpoint (1 op meer) ongeacht als dat een fysieke endpoint is of een virtuele endpoint waar de sensoren rechtstreeks met de gateway verbonden zijn. en de endpoints sperken met de gateway (1 op meer).

 

[OctaFish]

Spraakverwarring, denk ik: in mijn ogen is tblEndpoint de tussentabel .

 

[dbAnnelies]

K, dank je wel.

Ik sluit de toppic af.