Foreign Key avec "filtre données"

Un problème d'architecture de données sans solution ... actuellement.
Deux tables qui devraient être en relation parent-child mais avec filtre sur les données parent.
Ci-dessous un exemple fabriqué de toute pièce, l'expression du besoin, les solutions envisagées et les problèmes rencontrés.

Je trouve que le cas est intéressant - même si mon besoin est bien réel, tout autant que mon embaras.
Si quelqu'un possède une solution ou pense à une voie à explorer ...

ENVIRONNEMENT :
Oracle 10g - dispose d'un user avec privilege sysdba

STRUCTURES :
1) table TBL_PAYS de structure
( ide_pays number(9) not null
, libelle_pays varchar2(50) not null
, code_continent char(2) not null
)
avec constraints
+ primary key sur ide_pays
+ check sur code_continent in ('EU','AM','AF','AS','OC')
2) table TBL_VILLE_EU de structure
( ide_ville_eu number(9)
, name_ville_eu varchar2(50)
, ide_pays number(9)
)
avec constraint
+ primary key sur ide_ville_eu

BESOIN :
Gérer l'intégrité référentielle pour permettre l'insertion dans TBL_VILLE_EU des lignes relatives aux pays du continent Europe (code_continent = 'EU').

Techniquement, si les données TBL_PAYS sont
ide_pays libelle_pays code_continent
1 FRANCE EU
2 CHINE AS
Alors
insert into TBL_VILLE_EU values (1,'PARIS',1)
> 1 row inserted
insert into TBL_VILLE_EU values (2,'PEKIN',2)
> error ref integrity

SOLUTIONS POSSIBLES :
1) +a Création d'une table TBL_PAYS_EU de structure similaire à TBL_PAYS
+b Transfert des données depuis TBL_PAYS vers TBL_PAYS_EU avec un filtre sur code_continent
+c Ajout d'une constraint foreign key qui référencie la table TBL_PAYS_EU
==> inconvénients :
+ données dupliquées
+ refresh obligatoire des données TBL_PAYS_EU (le trigger peut faciliter les choses)
+ espace disque
2) +a Filtre des données TBL_PAYS à l'aide d'une view
Create or replace view VIE_PAYS_EU ( ide_pays_eu )
as select ide_pays from TBL_PAYS where code_continent = 'EU'
+b Ajout d'une constraint foreign key qui référencie la view VIE_PAYS_EU
==> problèmes :
+ la création de la foreing key génere une erreur parce que la colonne de la view n'est pas indexée
+ l'ajout d'une constraint primary key sur ide_pays_eu (DISABLE NOVALIDATE) ne change rien (la constraint est pourtant visible dans ALL_CON_COLUMNS).
3) MV (Materialized View) : solution non testée, utilisation non désiré.