Использование идентификаторов из нескольких таблиц в одном столбце

Один из моих коллег создал схему, подобную следующей. Это упрощенная схема, включающая только части, необходимые для решения этого вопроса.

Системные правила следующие:

1. Департаменты могут иметь от 0 до многих отделов.
2. Подразделение должно принадлежать только одному отделу.
3. ] Статья может быть назначена либо отделу, либо отделу этого отдела.

Схема такова:

Department
---------- 
DepartmentID (PK) int NOT NULL
DepartmentName varchar(50) NOT NULL

Division
--------
DivisionID (PK) int NOT NULL
DepartmentID (FK) int NOT NULL
DivisonName varchar(50) NOT NULL

Article
-------
ArticleID (PK) int NOT NULL
UniqueID int NOT NULL
ArticleName varchar(50) NOT NULL

Он определил схему, используя воображаемое правило (из-за отсутствия лучшего термина), что все идентификаторы отдела будут от 1 до 100, а все идентификаторы DivisionID будут от 101 до 200. Он заявляет, что при запросе таблицы Article вы узнаете, из таблицы Department или из таблицы Division, в зависимости от того, в какой диапазон он попадает.

Я считаю, что это плохой дизайн, и предлагал следующую альтернативную схему:

Department
----------
DepartmentID (PK) int NOT NULL
ParentDepartmentID (FK) int NULL /* Self-referencing foreign key.  Divisions have parent departments. */
DepartmentName varchar(50) NOT NULL

Article
-------
ArticleID (PK) int NOT NULL
DepartmentID (FK) int NOT NULL
ArticleName varchar(50) NOT NULL

Я считаю, что это правильно нормализованная схема, которая должным образом обеспечивает отношения и целостность данных, соблюдая при этом бизнес-правила, изложенные выше.

Мой конкретный вопрос таков:

Я знаю, что в одном столбце значений из двух доменов - это плохой дизайн, и я могу аргументировать преимущества внешнего ключа в таблице Article. Однако может ли кто-нибудь предоставить ссылку на конкретную статью / статью о дизайне базы данных, которую я могу использовать для подтверждения своей позиции. Если я могу указать на что-то конкретное, это будет намного проще.