2 Urri
Так у Вас 4 отношения?
Среди которых R1(Д,О,П) и R2(О,П)?
Если так, то R1(Д,О,П) не удовлетворяет НФБК => схема не удовлетворяет НФБК.
(Есть конечно и третья схема из одного отношения R1(Д,О,П) - она и не в НФБК и нельзя навязать зависимость П->О, и очевидны аномалии ввода и удаления. Но одно отношение.)
У Вас же 4. Чем больше отншений при прочих равных условиях, тем очевидно менее оптимальна схема. А она равна по условиям схеме из двух отношений R1(Д,О,П) и R2(О,П). Не в НФБК и можно реализовать ограничение целостности S1 (просто объявить уникальной пару {Д,О}). В R2 ключем объявить П. В принципе все фукциональные зависимости навязаны с точки зрения теории. Для того, чтобы все-таки обеспечить ограничения целостности и не допустить в R1 ввода подразделений, которых нет в R2 или не приписать чужих подразделенй отделению в R3 можно объявить сверх того суперключ в R2 - пару {О,П} ограничение ссылочной целостности с внешним ключем {О,П} в R1. Но это детали - просто этой пары достаточно, чтобы получить то же, что Вы получили с 4 отношениями.

Главное с точки зрения темы, что нормализация выше 3 формы (НФБК) имеет проблемы с ограничениями целостности. Т.е. чтобы показать, что этот пример не говорит об этом, надо чтобы схема была и в НФБК, и обеспечивались все ограничения целостности из примера, включая S1, но только они (например, никаких Д->П не должно быть).

Поскольку R1(Д,О,П) нарушает НФБК, то его быть не должно. А если его нет, то нельзя навязать ДО -> П с помощью декларативных ограничений целостности.



На практике и с триггерными схема R1(Д,О,П), R2(О,П) может оказаться предпочтительней. Так как О в R1 - просто в этом случае вычислимое поле, а пользователь вводит тока Д и П. Потому что скорей всего в схеме R1(Д,П), R2(О,П) - триггер обеспечивающий S1 может иметь сложности в зависимости от СУБД. Например в Оракле - с мутейтинг тэйбл придется столкнуться. Да и просматривать он должен гораздо больше, чем триггер первой схемы. Но так или иначе сложнее прояснять моменты с целостностью данных

А было утверждение

SanyL
2)Проще прояснить моменты с целостностью данных


До 3НФ включительно - это скорей всего так, а вот с НФБК - это, наверное, не так.

Кроме того, нормализация и по 3НФ (и вообще) может приводить к появлению отношений, которые не соответсвуют сущностям ПО. Т.е. может приводить к неадекватному представлению сущностей реального мира. Плюс дополнительные соединения.

С другой стороны преимущества нормализации очевидны - устранение избыточности и аномалий ввода и удаления.

Думаю, нормализация с возможной последующей денормализацией лучше в общем случае, чем проектирование вообще без этапа, на котором проводится нормализация в ходе поиска оптимальной схемы. Денормализация может понадобиться потом с целью оптимизации всей системы в целом с учетом особенностей выбранной СУБД.

Однако, считается, что опытный пректировщик может спроектировать и без нормализации. В любом случае вопрос проектирования БД - вопрос искусства проектировщика в сложных случаях, поскольку теория не дает критериев оптимальной схемы на все случаи.

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

Однако, я наблюдал БД, где явные нарушения 3НФ приводили не только большой избыточности, но и усложняли написание запросов, да и к противоречиям в данных - т.е там и ограничения целостности трудновато было обеспечить, да и не утруждали себя их обеспечением разработчики.

softwarer
Я бы сказал чуть иначе - без явно выделенного этапа нормализации. Поскольку эта работа идет в фоне, в подкорке.

Я имел в виду более радикальное: опытный проектировщик не знает ничего про нормальные формы, функциональные зависмости (ну может слышал сами термины). Нутром типа чувствует избыток или аномалии - чисто эвристический подход. Мне, кажется, что автор темы именно про это спрашивал.


Что касается явного выделения этапа нормализации (иногда этот этап называют этапом логического проектирования БД), то его, наверное, не присутствует в большинстве случаев. Возможно, в планах вообще есть этап проектирование БД, в который каждый уже включает что сочтет нужным.

2 Cat2
В моей фразе под "опытный проектировщик" имелось в виду некоторые "опытные проектировщики", но не обязательно все. Т.е. нельзя сказать, что опытный проектировщик, не знающий нормальных форм всегда спроектирует хуже, чем тот который знает. Причем это не мое мнение, а я где-то вычитал.

Этапа нормализации у опытного проектировщика нет.

Я пытался сказать, что такого этапа, скорей всего, нет у многих: и опытных, и, что хуже, у не опытных проектировщиков. Однако, он рекомендуется в толстых книгах.
И в общем случае он может быть и у опытного проектировщика. Наверное, во многих случаях сами функциональные зависимости довольно простые, и потому можно обойтись без явного выделения этого этапа.
Но, например, если было где-то явно написано, что схема нормализована по 3НФ, например, а потом денормализована так-то и так-то, то врядли в этом был вред для другого проектировщика, который бы сопровождал БД в будующем.

2 Semaphore
Как же выходит за пределы ФЗ? Пожалуста все то же формально: есть две ФЗ вытекающие из ПО: П->О и ДО->П. Они порождают остальные с помощью аксим вывода Амстронга. Все остальное в моем примере просто интерпритация этих формальностей для наглядности. Потому что моей целью было ответить на вопроос и тем кто не изучал теорию рел БД про нормальные формы и огр целостности.

Что касается "только один", то это входит в определение ФЗ. Это и есть обеспечение однозначного определения атрибута в моем примере: пара ДО однозначно благодаря этому опрделяет П. Или Вы думаете нет?

PS
Хочу обратить Ваше внимание на то что книга Э. Озкарахан "Машины баз данных", М.Мир, 1989 (а она сейчас передо мной) не претендует на изложение теории рел баз данных - у нее другая цель: машины БД. От этого определения которые там есть недостаточно формально строги, и допучскают видимо Вам истолковать их как-то по своему. Я, однако, ввел "количественную характеристику" именно ради однозначного определения атрибута. Так чтобы у меня была именно функцианальная зависмость, т.е. чтобы, выражаясь Вашим языком, попасть в пределы ФЗ.

ModelR
На самом деле, когда говорят ( используя ER методологию) "O становится частью первичного ключа П " , то это означает, что ФЗ П->О упраздняется.
Здесь конечно следовало бы оговорить где П сущность, а где атрибут типа :
П(П#, O#) , O(O#).

Не ER - метологию, а теорию рел БД. И не первичного ключа а просто ключа О станивтся частью. И потому становится первичным атрибутом. Это имеет значение: отношение находится в 3НФ, но не НФБК. Там для обозначение отношений (а не сущностей и даже не типов сущностей - это из модели сущность-связь, а мы в реляционной) использовались R1 и R2.
Обозначения для РМД - ясные.


ModelR
После упразднения ФЗ задачка естественно вырождается, остается только
Д->ПО на что видимо Urri и намекал.

К срожалению, ФЗ не склонны к упраздению. Склонны к пораждению новых. Задачка вроде не вырождалась ни естественно, ни противоестественно.

Я не уверен Вы про ту задачку говорите: есть три атрибута Д, О, П
Есть две ФЗ: ДО->П и П->О.

Построить схему в НФБК, чтобы она полностью характеризовала эти ФЗ, т.е. их можно было навязать с поммощью объявления ключей (не важно первичных альтернативных).

Я утверждаю, что этого нельзя сделать. Потому что если есть в схеме отношение R(Д,О,П) - то схема не в НФБК, а если этого отношения нет, то нельзя навязать ДО->П, (не навязывая ФЗ, которых нет типа Д->П).

Вы утверждаете обратное? Приведите схему.

Вывод: нормализация выше 3НФ имеет проблемы с ограничениями целостности.

ModelR
Ну, единственно просил бы пояснить термин "первичный атрибут".

В ряде источников первичным называют атрибут, который входит хоть в один ключ.

ModelR
Ни с этим утверждением, ни с Дейтом (см.седьмое издание, стр.447: " попытка достижения двух целей , а именно - декомпозиции исходной переменной-отношения на переменные-отношения, находящиеся в НФБК, и декомпозиции исходной переменной-отношения на независимые переменные-отношения, в некоторых случаях может привести к конфликтной ситуации" ) никто спорить и не собирался.


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