Формально дата По лишняя, кроме того случая, когда период действия данных завершается окончательно. На практике интервал [С, По] позволяет упростить выборки нужных строк из таблиц, например писать sysdate between С and ПО, вместо конструкций с подзапросами min/max.
Кроме того индекстирование по ключу (ID, С, ПО), позволяет находить ROWID нужной строки только путём сканирования индекса по диапазону не обращаясь к сегменту таблицы. В результате существенно сокращается количество логических чтений и увеличивается производительность запросов.

Делить отношение на таблицы по принципу изменяемые/неизменяемые атрибуты, тем более выделять отдельные колонки нет смысла. На соединениях в запросах потеряешь больше, а определить какой атрибут изменился очень просто сравнив поля в соседних записях.

Самая главная проблема это ввод первичных данных.
Практика показывает, что возьня с датами, а тем более с интервалами сильно усложняет работу оператора и логику приложения (нужно отслеживать пересечения интервалов, правильно делать блокировки, исправление ошибок становится нетривиальной задачей и т.д.). Решением может быть создание Front-end подсистемы для заведения первичных данных, в виде максимально приближенном к формату источника. Затем после заведения и проверки данных нужно отразить их в исторические записи, пригодные для удобного использования во многих подсистемах. Кроме того нужно предусмотреть операцию исправления первичных данных, если в них обнаружились ошибки, и повторного применения в историческую подсистему.
Часто новая версия документа отличается от предыдущей только датой вступления в силу и изменениями нескольких строк или полей. В этом случае полезно иметь функцию создания новой версии документа по образцу существующей версии. В связи с этим возникает интересная задача трассировки версий, например для поиска и исправления растиражированных ошибок (вспомним Copy/Paste ).