Цитата:
Изначально опубликовано Nik
Подскажите Grizzli, как эту проблему можно решить "через изменение потребностей пользователя"?
В данном конкретном случае, думаю, никак
В том же сообщении чуть ниже я сказал, что если:
1) объем результирующего множества невелик (не поставит систему "колом" во время выполнения запроса)
2) данный запрос выполняется не часто (не приведет к существенному снижению общей производительности системы)
3) требования к выходной информации изменить нельзя,
то "я бы пристрелил программера, который ради этого стал городить огород, а тем паче менять структуру БД"
Данная задача, как мне кажется, из этой категории
Но поверьте мне, бОльшей частью "требования пользователя" определяются не действительнымит потребностями, а привычками работы либо с предшествующей системой, либо вручную. В то время как аналитики даже не пытаются выяснить истинные причины таких требований.
Цитата:
Изначально опубликовано Nik
2. Подход к нормализации Персонала и Зарплаты у меня вызывает удивление. С какой целью разработчики ушли от третьей нормальной формы. Буквально везде в полях хранятся вычисляемые значения. Для быстродействия?
Нормализация не догма, а руководство к действию
Иногда существует конфлик между соблюдением требований нормализации и требованиями, предъявляемыми к системе. А любая ИС создается не для того, чтобы демонстрировать свое соответствие математичекис теориям, а для решения конкретных задач. Крис Дейт в своем классическом труде "Руководство по реляционной СУБД DB2" на эту тему сказал: "Принципы нормализации рекомендуют руководствоваться критерием "один факт в одном месте"; но иногда есть существенные причины для того, чтобы иметь два факта в одном месте или один факт в двух местах". Использование принципов нормализации в РСУБД в некоторой степени было призвано оптимизировать операции по модификации (создание, обновление, удаление) за счет сокращения избыточности данных. Но иногда избыточность бывает полезна с точки зрения оптимизации операций по выборке.
Все относительно...
Кроме того, даже атомарность атрибута, о которой говорил Lazy_Tiger, вещь тоже достаточно относительная и определяется выполняемыми над ним операциями.
Вот с одним из таких проявлений относительности атомарности атрибута Вы и столкнулись (иногда дату нужно рассматривать как набор из трех атрибутов, но чаще удобнее как единое целое). И, на мой взгляд, никакого противоречия с требованиями 1nf здесь нет.