那么，下一个问题是：如果外键列不能为空，会怎么样呢？
SQL> desc child;
Name   Type          Nullable Default Comments
------ ------------- -------- ------- --------
C_ID   NUMBER(3)
V_ID   NUMBER(3)     Y
C_NAME VARCHAR2(100) Y
SQL> alter table child modify v_id not null;
Table altered
SQL> desc child;
Name   Type          Nullable Default Comments
------ ------------- -------- ------- --------
C_ID   NUMBER(3)
V_ID   NUMBER(3)
C_NAME VARCHAR2(100) Y
SQL> delete prim where v_id=2;
delete prim where v_id=2
ORA-01407: 无法更新 ("A"."CHILD"."V_ID")为 NULL
　　更改失败~
　　五、传说中的on update cascade
　　On update cascade被称为“级联更新”，是关系数据库理论中存在的一种外键操作类型。这种类型指的是：当主表的记录被修改（主键值修改），对应子表的外键列值连带的进行修改。
　　SQL> alter table child add constraint FK_CHILD_PRIM foreign key(v_id) references prim(v_id) on update cascade;
　　alter table child add constraint FK_CHILD_PRIM foreign key(v_id) references prim(v_id) on update cascade
　　ORA-00905: 缺失关键字
　　目前的Oracle版本中，似乎还不支持on update cascade功能。Oracle在官方服务中对这个问题的阐述是：在实际系统开发环境中，直接修改主键的情况是比较少的。所以，也许在将来的版本中，这个特性会进行支持。
　　六、结论
　　Oracle外键是我们日常比较常见的约束类型。在很多专家和业界人员的讨论中，我们经常听到“使用外键还是系统编码”的争论。支持外键策略的一般都是数据库专家和“大撒把”的设计师，借助数据库天然的特性，可以高效实现功能。支持系统编码的人员大都是“对象派”等新派人员，相信可以借助系统前端解决所有问题。
　　笔者对外键的观点是“适度外键，双重验证”。外键要设计在紧密的引用关系中，对验证动作，前端和数据库端都要进行操作。外键虽然可以保证后安全渠道，但是不能将正确易于接受的信息反馈到前端。前端开发虽然比较直观，但是的确消耗精力。所以，把握适度是重要的出发点。