Abstração de referências hierárquicas com modelo estrito

Aqui está uma solução possível. Navegar na estrutura de cima para baixo pode ser um pouco grosseiro, mas talvez os objetos do lado do aplicativo possam lidar com isso.

Eu acho que você pode construir isso usando 2 tabelas dbo.Devicee arquivos dbo.Combiner. Cada tabela tem uma coluna que faz referência a quem é seu objeto pai, independentemente de ser um deviceou um combiner. Podemos então usar alguns tipos diferentes constraintse alguns triggerspara garantir que os dados sigam o caminho que você deseja usar.

Estruturas de tabela (agora seus objetos provavelmente têm mais pontos de dados do que apenas a,namemas por uma questão de simplicidade, vou acompanhar apenas aname)

dbo.Device

CREATE TABLE dbo.Device
(
    ID INT IDENTITY(1,1) NOT NULL,
    Name VarChar(100) NOT NULL,
    ParentDeviceID INT NULL,
    ParentCombinerID INT NULL,
    CONSTRAINT [PK_Device] PRIMARY KEY CLUSTERED 
    (
        [ID] ASC
    )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, FILLFACTOR = 90) ON [PRIMARY]
) ON [PRIMARY]

CREATE UNIQUE NONCLUSTERED INDEX IX_UniqueParentDeviceIDDevice 
ON dbo.Device(ParentDeviceID)  
WHERE ParentDeviceID IS NOT NULL

ALTER TABLE [dbo].[Device]  WITH CHECK ADD  CONSTRAINT [FK_Device_Device] FOREIGN KEY([ParentDeviceID])
REFERENCES [dbo].[Device] ([ID])
GO

ALTER TABLE [dbo].[Device]  WITH CHECK ADD  CONSTRAINT [FK_Combiner_Device] FOREIGN KEY([ParentCombinerID])
REFERENCES [dbo].[Combiner] ([ID])
GO

ALTER TABLE [dbo].[Device]
ADD CONSTRAINT CHK_Device CHECK (ParentDeviceID IS NULL OR ParentCombinerID IS NULL)
GO

dbo.Combiner

CREATE TABLE dbo.Combiner
(
    ID INT IDENTITY(1,1) NOT NULL,
    Name VarChar(100) NOT NULL,
    ParentDeviceID INT NULL,
    ParentCombinerID INT NULL,
    CONSTRAINT [PK_Combiner] PRIMARY KEY CLUSTERED 
    (
        [ID] ASC
    )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, FILLFACTOR = 90) ON [PRIMARY]
) ON [PRIMARY]

CREATE UNIQUE NONCLUSTERED INDEX IX_UniqueParentDeviceIDCombiner
ON dbo.Combiner(ParentDeviceID)  
WHERE ParentDeviceID IS NOT NULL

ALTER TABLE [dbo].[Combiner]  WITH CHECK ADD  CONSTRAINT [FK_Combiner_Device] FOREIGN KEY([ParentDeviceID])
REFERENCES [dbo].[Device] ([ID])
GO

ALTER TABLE [dbo].[Combiner]  WITH CHECK ADD  CONSTRAINT [FK_Combiner_Combiner] FOREIGN KEY([ParentCombinerID])
REFERENCES [dbo].[Combiner] ([ID])
GO

ALTER TABLE [dbo].[Combiner]
ADD CONSTRAINT CHK_Combiner CHECK (ParentDeviceID IS NULL OR ParentCombinerID IS NULL)
GO

Cada tabela contém quem é seu objeto pai via ParentDeviceIDou ParentCombinerID. O Unique Filtered Indexon ParentDeviceIDajuda a garantir que um dado Devicepossa ser apenas o pai de um objeto (A Unique Constraintpararia várias linhas com um NULLvalor). Não é garantido, então é por isso que vamos usar alguns gatilhos no futuro. Os dois CHECK Constraints ajudam a garantir que qualquer objeto possa ter apenas 1 objeto pai em vez de ter a Devicee Combinercomo pai. Os Foreign Keys garantem que os valores armazenados em ParentDeviceIDe ParentCombinerIDsejam valores válidos para essas duas tabelas.

Triggers

Podemos inserir um Triggerem cada table. Estes Triggers precisam garantir:

1. No insert/ updatede um dbo.Deviceregistro em que um valor armazenado ParentDeviceIDainda não está emdbo.Combiner.ParentDeviceID
2. No Insert/ Updatede um dbo.Combinerregistro em que um valor armazenado ParentDeviceIDainda não está emdbo.Device.ParentDeviceID

-- On the Insert/Update of a dbo.Combiner record a value stored on ParentDeviceID is not already on dbo.Device.ParentDeviceID
CREATE TRIGGER dbo.CombinerCheck ON dbo.Combiner
AFTER INSERT, UPDATE
AS
BEGIN
    IF EXISTS
    (
        SELECT *
        FROM INSERTED I
            INNER JOIN Device D
                ON I.ParentDeviceID = D.ParentDeviceID
    )
    BEGIN
        RAISERROR ('This Combiner cannot be added since it''s parent Device is already a parent to a different Device.', 16, 1);
        ROLLBACK TRANSACTION; --stops the Insert/Update
        RETURN 
    END
END

--On the insert/update of a dbo.Device record a value stored on ParentDeviceID is not already on dbo.Combiner.ParentDeviceID
CREATE TRIGGER dbo.DeviceCheck ON dbo.Device
AFTER INSERT, UPDATE
AS
BEGIN
    IF EXISTS
    (
        SELECT *
        FROM INSERTED I
            INNER JOIN Combiner C
                ON I.ParentDeviceID = C.ParentDeviceID
    )
    BEGIN
        RAISERROR ('This Device cannot be added since it''s parent Device is already a parent to a Combiner.', 16, 1);
        ROLLBACK TRANSACTION; --stops the Insert/Update
        RETURN
    END
END

Como alternativa, esta pergunta do StackOverflow aparentemente dá o mesmo efeito ou similar com um Unique Indexem um View. Se você quiser evitar Triggersdo que isso pode ser uma solução para você. https://stackoverflow.com/questions/16314372/ms-sql-server-cross-table-constraint . Eu não estou familiarizado com essa abordagem, mas talvez seja uma solução melhor para você.

Exemplos

A implementação do 1º Exemplo fornecido (apenas 3 dispositivos em uma cadeia) seria algo assim. Apenas 3 registros em dbo.Device:

+----+------+----------------+------------------+
| ID | Name | ParentDeviceID | ParentCombinerID |
+----+------+----------------+------------------+
|  1 | D1   | NULL           | NULL             |
|  2 | D2   | 1              | NULL             |
|  3 | D3   | 2              | NULL             |
+----+------+----------------+------------------+

A implementação do 2º Exemplo fornecido (1 Device --> 1 Combiner --> 3 Devices) seria algo assim. 4 registros em dbo.Devicee 1 registro em dbo.Combiner.

Device
+----+------+----------------+------------------+
| ID | Name | ParentDeviceID | ParentCombinerID |
+----+------+----------------+------------------+
|  1 | D1   | NULL           | NULL             |
|  2 | D2   | NULL           | 1                |
|  3 | D3   | NULL           | 1                |
|  4 | D4   | NULL           | 1                |
+----+------+----------------+------------------+

Combiner
+----+------+----------------+------------------+
| ID | Name | ParentDeviceID | ParentCombinerID |
+----+------+----------------+------------------+
|  1 | C1   |              1 | NULL             |
+----+------+----------------+------------------+

Mais um exemplo um pouco mais complicado para exibir todas as opções de relacionamento:

dbo.Device
+----+------+----------------+------------------+
| ID | Name | ParentDeviceID | ParentCombinerID |
+----+------+----------------+------------------+
|  1 | D1   | NULL           | NULL             |
|  2 | D2   | 1              | NULL             |
|  3 | D3   | NULL           | 1                |
|  4 | D4   | NULL           | 1                |
|  5 | D5   | NULL           | 1                |
|  6 | D6   | NULL           | 2                |
|  7 | D7   | NULL           | 2                |
|  8 | D8   | NULL           | 2                |
+----+------+----------------+------------------+

dbo.Combiner
+----+------+----------------+------------------+
| ID | Name | ParentDeviceID | ParentCombinerID |
+----+------+----------------+------------------+
|  1 | C1   | 2              | NULL             |
|  2 | C2   | NULL           | 1                |
+----+------+----------------+------------------+

Espero que isso forneça tudo o que você precisa do lado do banco de dados. Novamente, acho que isso será complicado no lado do aplicativo, navegando pelas estruturas da tabela. Mas o banco de dados deve manter os relacionamentos do jeito que você deseja.