Добрый день,

Есть таблица [Люди].
Столбцы - [ID], [Имя], [Пол], [Размер груди].
Размер груди релевантен только для строк, у которых [Пол] == Ж. Если [Пол] == М, то [Размер груди] == NULL.

Правильно ли я понимаю, то эта таблица не удовлетворяет 3NF? Т.к. тут нарушено "все неключевые атрибуты взаимно независимы" (зависимы [Размер груди] зависит от [Пол]).
Нужно эту таблицу разбить на две - убрать столбец [Размер груди] из таблицы [Люди], сделать отдельную табличку [Дамы], в которой будет [ID], [Размер груди].

Спасибо.

vadiminfo,

спасибо за ответ.
А с точки зрения 3 нормальной формы, таблица ([Id], [Имя], [Пол], [Размер груди]) удовлетворяет 3 НФ?

Ennor Tiegaelstannull45Если [Пол] == М, то [Размер груди] == NULL. А по-моему, это утверждение расходится с объективной реальностью.

[Размер груди] выбран в примере, как признак не релевантный для мужчин.
Смысл в том, что в таблице есть столбцы (в моем примере это [Размер груди]), которые релевантны только для части строк .

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

vadiminfo Хотя Пол вообще типа выводимое, т.е. оно как бы известно и так без ввода в БД. Т.е. вообще на выкидывание могло прендовать.
Нет, обязательно есть признак м или ж, а заносить [Размер груди] для женщин не обязательно. Но просто для части женщин он будет неизвестен, а для мужчин он просто не релевантен, т.к. с точки зрения бизнес логики нам не важно какая грудь у мужчин, им например надо свой столбец с понятно какой характеристикой). Который опять таки будет не релевантен для женщин.

vadiminfo
Однако, правда в том, что есть NULL. В этом случае говорить об ФЗ с участием NULL, возможно, не совсем корректно.
Не могу понять почему говорить о функциональной зависимости не совсем корректно?

guest_20040621> эта таблица не удовлетворяет 3NF?

Сложно предположить, чему она вообще удовлетворяет. Начнем с того, что размер груди - такой, как вы его понимаете - шкала для нижнего белья.

Ну почему только для нижнего. Для маек тоже может быть важно. И потом может это не магазин, а каталог девушек легкого поведения.

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

Я теперь рад переформулировать свой вопрос - что вообще не так с моей таблицей, в которой у меня есть столбцы, которые имеют смысл только для части строк. Она не удовлетворяет требованиям нормальных форм или может все с ней впорядке?
Я просто сделал так как сделал, а объяснить почему не могу. И стыдно, что не могу.

Спасибо за обсуждение!

Я кажется навел порядок в голове.
Оказывается в англоязычной литературе эта проблема называется Table-per-Hierarchy versus Table-per-Type Inheritance.
То есть одна таблица на иерархию, либо по таблице на каждый тип.
Как написал vadiminfo, по сути то, что я описывал на уровне таблиц, в коде выглядело бы как наследование классов.
На уровне базы это можно реализовывать и как TPT, так и TPH из соображений производительности. В частности для моей области - MS SQL Server + Entity Framework рекомендуется TPH :
http://www.asp.net/mvc/tutorials/getting-started-with-ef-using-mvc/implementing-inheritance-with-the-entity-framework-in-an-asp-net-mvc-application TPH inheritance patterns generally deliver better performance in the Entity Framework than TPT inheritance patterns, because TPT patterns can result in complex join queries.

В тоже время есть возможность следовать и подходу TPT. Более того, вот тут человек аргументирует по поводу недостатков TPH:
http://weblogs.asp.net/manavi/archive/2010/12/24/inheritance-mapping-strategies-with-entity-framework-code-first-ctp5-part-1-table-per-hierarchy-tph.aspx TPH Violates the Third Normal Form

Another important issue is normalization. We’ve created functional dependencies between nonkey columns, violating the third normal form. Basically, the value of Discriminator column determines the corresponding values of the columns that belong to the subclasses (e.g. BankName) but Discriminator is not part of the primary key for the table. As always, denormalization for performance can be misleading, because it sacrifices long-term stability, maintainability, and the integrity of data for immediate gains that may be also achieved by proper optimization of the SQL execution plans (in other words, ask your DBA).
В частности он утверждает, что такая таблица TPH будет нарушать третью нормальную форму.
Применительно к моему примеру дискриминатором выступает этот самой столбец [Пол]. Этот столбец определяет какие колонки принадлежат к каким подклассам. При этом этот дискриминатор не является частью первичного ключа. Это и нарушает условие третьей нормальной формы "ни один неключевой атрибут R не находится в транзитивной функциональной зависимости от потенциального ключа R" http://ru.wikipedia.org/wiki/%D0%A2%D1%80%D0%B5%D1%82%D1%8C%D1%8F_%D0%BD%D0%BE%D1%80%D0%BC%D0%B0%D0%BB%D1%8C%D0%BD%D0%B0%D1%8F_%D1%84%D0%BE%D1%80%D0%BC%D0%B0] http://ru.wikipedia.org/wiki/Третья_нормальная_форма
Таким образом я сейчас считаю, что все же третьей нормальной форме моя таблица не удовлетворяет. Хотя я решил ее оставить как есть, оправдывая себя тем, что для Entity Framework это рекомендуется.