Integridade Referencial - Chave Estrangeira Indireta em "Profundidade"

Eu pessoalmente não gosto da ideia de empurrar o valor Job.ID em todas as outras tabelas filhas

Por que não? A solução óbvia é tornar JobID a principal coluna de índice PK/clustered em todas as tabelas filhas. E garante um ótimo desempenho para acessar todas essas tabelas por JobID.

Geralmente sempre que você tem um "relacionamento de identificação" também conhecido como "tabela filho" também conhecido como "entidade fraca", a tabela filho deve usar uma chave primária composta cujas colunas principais também são a chave estrangeira para a tabela pai. Algo assim:

create table Parent
(
  ParentId int not null identity,
  constraint pk_Parent
    primary key(ParentId)
)

create table Child
(
  ParentId int not null, 
  ChildId int not null identity, 
  constraint pk_Child 
    primary key (ParentId,ChildId),
  constraint fk_Child_Parent
    foreign key (ParentId) references Parent(ParentId)
    on delete cascade
)
create table GrandChild
(
  ParentId int not null references Parent, 
  ChildId int not null, 
  GrandChildId int not null identity,
  constraint pk_GrandChild 
    primary key (ParentId,ChildId,GrandChildId),
  constraint fk_GrandChild_Child
    foreign key (ParentId) references Parent(ParentId)
    on delete cascade
)

Um exemplo de como a integridade dos dados pode ser mantida usando o FKs. Modifiquei um pouco o modelo para permitir que um executável faça parte de mais de um trabalho. A suposição é que, quando um executável é executado, ele é executado para todos os clientes associados a esse executável. Seu ERD não mostra restrições, portanto, há algumas suposições envolvidas.

-- Customer CUS exists.
--
customer {CUS}
      PK {CUS}

-- Executable EXE exists.
--
executable {EXE}
        PK {EXE}

-- Executable EXE runs task for customer {CST}.
--
customer_exe {EXE, CST}
          PK {EXE, CST}

FK1 {EXE} REFERENCES executable {EXE}
FK2 {CUS} REFERENCES customer   {CUS}

-- Job JOB exists.
--
job {JOB}
 PK {JOB}

-- Step number STP# of job JOB
-- runs executable EXE.
--
job_step {JOB, STP#, EXE}
      PK {JOB, STP#}
      SK {JOB, STP#, EXE}

FK1 {JOB} REFERENCES job {JOB}
FK2 {EXE} REFERENCES executable {EXE}

Uma suposição é que as tarefas gravam em log_tabelas, portanto, espera-se alguma redundância: como EXEem log_job; ainda FKsevitar anomalias.

-- Executable EXE ran as step number STP#
-- of job JOB on DTE (date-time).
--
log_job {DTE_J, JOB, STP#, EXE}
     PK {DTE_J, JOB, STP#}
     SK {DTE_J, JOB, STP#, EXE}

      FK {JOB, STP#, EXE} REFERENCES
job_step {JOB, STP#, EXE}

-- Executable EXE ran for customer CUS,
-- with success result RES, on DTE_C (date-time),
-- as step number STP# of job JOB, which ran on DTE_J.
--
log_cus {DTE_J, JOB, STP#, CUS, EXE, DTE_C, RES}
     PK {DTE_J, JOB, STP#, CUS}

    FK1 {DTE_J, JOB, STP#, EXE} REFERENCES
log_job {DTE_J, JOB, STP#, EXE}

         FK2 {EXE, CST} REFERENCES
customer_exe {EXE, CST}

Observação:

All attributes (columns) NOT NULL

PK = Primary Key
AK = Alternate Key   (Unique)
SK = Proper Superkey (Unique)
FK = Foreign Key