Есть сущность ЮридическоеЛицо, имеющая такие свойства как НазваниеКомпании, ЮрАдрес, ИНН и тд. А также есть БанковскиеАттрибуты, которые относяться к банку, в котором открыт счет юрлица. Аттрибуты состоят из таких свойств как корреспондентский и расчетный номера счетов, название банка, его адрес и БИК. Нужно-ли их выделять в отдельную таблицу ? С одной стороны, БИК банка явно не относиться к аттрибутам юрлица, с другой стороны, особой пользы от выделения тоже не видно ...

Если можно, то еще один вопрос - а стоит-ли выделять в отдельную таблицу например паспорт у Клиента ? Ведь не бывает 2 человек с одинаковым номером паспорта, т.е. он гаранированно уникален. Вроде нет смысла выделять, но все-таки он ведь тоже отдельная сущность ...

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

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

Сергей Васкецов
Это неверно.

где вы хотите заносить его еще раз ?

Сергей Васкецов
Перенесли винт на другой комп, например. Или заменили на новый.

так и поменяли данные прямо в таблице Компьютер.

egorych
люди, бывает, меняют паспорта

данные о паспорте тоже можно поменять прямо в таблице Клиент.

egorych
а у меня в компе 2 винта, а в сервере - 7

это меняет постановку исходной задачи :)

Так все-таки, в чем собственно выгода выноса ? Только в том, что в каждой таблице будет только одна сущность ? Из каких правил нормализации это следует ?

MasterZiv
Паспортов у человека может быть много (несмотря на все старания милиции).
...
Если ты обработаешь у себя в системе верно ситуацию, когда,
например, человек получил деньги под отчет по одному паспорту,
сдал их, потом получил по другому и сдал,
и тебе надо напечатать два этих авансовых отчета одновременно
(и правильно), то тогда действительно все в порядке.
Ты можешь менять прямо в таблице. И не делать доп. таблицу
для паспортов.

ситуацию, когда есть несколько паспортов или винчестеров мы не обсуждаем - там все ясно, интересует именно если сущность одна. Например строго один паспорт или винчестер.
Если хотите другой пример - характеристики двигателя автомобиля. Уж он-то в машине точно один Уносим характеристики двигателя в отдельную таблицу, или оставляем в таблице Автомобиль ?

MasterZiv
Любая нормализация строится на понятии "функциональная зависимость".
Функциональная зависимость определяется предметной областью и постановкой
задачи. Для одной задачи МОЖНО характеристики двигателя приписать автомобилю.
Для ДРУГОЙ - нельзя.

а можно привести пример, когда это можно, а когда нет ? А то что-то непонятно, то говорят, что согласно правилам нормализации нужно выносить в отдельную таблицу, то говорят что можно оставлять :)

474
Хм. Сегодня Иванова получила аванс по паспорту, о чем сделана запись в журнал выдачи авансов.
Завтра Иванова вышла замуж, взяла фамилию Петрова.
Через неделю получила новый паспорт, в БД поменяли ей карточку, а затем снова взяла аванс, о чем снова сделана запись в журнале.

Еще через неделю бухгалтер распечатала журнал авансов, и о ужас - в реестре две записи о выдаче аванса Петровой, а согласно информации из кадров, по штату в копании на дату первой записи никакой Петровой не было!

Паспорт у нее был и есть один. А отчет неверный. Кому отрывать голову?

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

474
Вы в жизни себе представляете хоть один бумажный отчет в котором вместо ФИО - табельные номера?
Что произойдет скорее - руководитель подпишет такой отчет, или выгонит программиста, который его написал?

вы сами-то вообще поняли, что написали ? Какое отношение отчеты имеют к способу организации данных ? Еще раз - обычно сотрудники компаний получают уникальные номера, или например в медицинских клиниках каждый больной имеет свой номер (часто называемый номером карточки). Именно этот номер уникально идентифицирует человека. И аванс будет соответственно выдан работнику с табельным № 2365, а не Петровой, которая потом стала Ивановой и получила новый паспорт. А вы как я понял, вместо этого предлагаете хранить все паспорта, который были у человека
А какие данные включать в конкретный отчет имеет мало отношения к обсуждению.

MasterZiv
Пример первый, пусть это будет БД оператора телефонной связи.

это да, хороший пример. Из него следует, что если никто не работает с некоторой сущностью отдельно, то ее можно оставлять в таблице с сущностью-владельцем, а если работает - то выносится в отдельное место ?
Про пример с тем-же паспортом - если я нигде не работаю с ним отдельно, и он везде "прицеплен" к клиенту - то можно оставить в таблице с клиентами, если-же хочу например вести историю изменений паспортов, или например сам по-себе паспорт важная сущность (например для паспортного стола, где они отвечают за прием заявлений на него и их выдачу) - то уношу в другую таблицу ?

Сергей Васкецов
Там же, в ту же таблицу.

в смысле ? У каждого человека паспорт уникален, как вы его еще раз внесете ?

Сергей Васкецов
Угу, дважды сделали работу (в старом компе и в новом), вместо переноса именно девайса.

точно, об этом я не подумал.

Сергей Васкецов
Можно, но не всегда. Для паспортов есть срок действия. Кроме того, паспорт - просто некоторый тип удостоверения личности, местами весьма специфический, но тем не менее УЛ. Надо исходить из таблицы с удостоверениями личности физика, а не лепить просто паспорт. Существует не так много действий, для которых требуется именно паспорт, а не свидетельство о рождении, или загранпаспорт, или права, или студенческий билет, или военный билет. Все они могут использоваться как удостоверения личности. Поэтому надо изначально исходить из правильной постановки, потому что "паспорт в таблице Клиент" - это исключительно дальнейшее развитие ошибки, что паспорт - единственное УЛ и не меняется.

вроде как это зависит от специфики бизнеса. Например вряд-ли вам в банке откроют счет по водительским правам, а по военному билету вы совершенно точно вы пересечете границу. Соответственно зачем там предусматривать различные варианты удостоверений ?
Имхо, как раз не так уж много ситуаций, когда годяться разные варианты УЛ.

Сергей Васкецов
Атрибуты должны быть у той сущности, чьими атрибутами они являются. Если это не так, должны быть крайне существенные основания, я даже не готов с ходу придумать их сейчас для Вас.

кстати возник интересный вопрос по этому поводу. В том-же паспорте имеется поле КемВыдан, представляющее отделение милиции и его КодПодразделения. Что-то я не думаю, что вы будете выносить подразделение милиции и кодом в отдельное место :) Или будете ? Ведь отдельная сущность получается :)

474
Я понял, а вот вы, похоже нет.

Если вы не храните изменяемые атрибуты отдельно, то вам рано или поздно придется столкнуться с ситуацией, когда атрибут объекта (сотрудника, к примеру) поменяется, а поскольку он у вас хранится один только раз и история не ведется (негде ее вести, раз нет отдельной таблицы), то всюду в вашей системе у вас будет новое значение вместо старого. Была Иванова, стала Петрова. И при необходимости вывести срез данных на какую-то дату вы столкнетесь с искажением данных. Теперь понятно вам понятно как ответить на ваш же вопрос "Какое отношение отчеты имеют к способу организации данных"? Если непонятно, то я отвечу - отчеты строятся на основе данных. Если данных нет или они искажены - правильный отчет вы не получите.

Об идентификации объектов речь внутри системы я вообще не вел, не приписывайте мне собственных домыслов. То что внутри системы используются ключи сущностей, и для системы Иванова это, к примеру, id100 - понятно даже школьникам. Просто сегодня для пользователя системы id100 это Иванова, а через месяц id100 - это Петрова. В вашей реализации (все хранить в одной сущности и изменять ее атрибуты напрямую) в системе и следа о том, что id100 когда-то была Ивановой не останется.

о майн гот.

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

Ответьте мне пожалуйста на следующий вопрос: при вашем способе реализации человек идентифицируется ФИО + паспорт. Судя по вашим словам "Еще через неделю бухгалтер распечатала журнал авансов, и о ужас - в реестре две записи о выдаче аванса Петровой, а согласно информации из кадров, по штату в копании на дату первой записи никакой Петровой не было! Паспорт у нее был и есть один. А отчет неверный. Кому отрывать голову?" у вас в системе будет следующая ситуация - две записи о выдачи аванса, одна из них про Петрову, другая про Иванову с другим паспортом. Таким образом один и тот-же человек (хотя по отчету кажется, что они разные) получил аванс дважды, что предположим, запрещено правилами компании. Кому теперь будем отрывать голову ?


Сергей Васкецов
Как раз с точностью до наоборот.

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

Сергей Васкецов
Если отделения милиции как таковые мне интересны, например, я их контролирую и надзираю за ними, то безусловно "да". Если же ничего кроме реквизитов УЛ мне не надо, то достаточно просто текстового поля, где будет писаться наименование органа, выдавшего УЛ, в точном соответствии с тем, как оно написано в самом УЛ на момент его выдачи.

это похоже на вышеприведенный пример MasterZiv'а про телефоны - если телефон это просто аттрибут, с которым отдельно не работаем, то оставляем в таблице с владельцем, если нет - то выносим. Отсюда вытекает такой момент, что (по аналогии с КемВыдан и его кодом подразделения) если я с паспортом нигде отдельно не работаю, то можно оставлять в таблице владельца ? Если так, то все встает на свои места.

Сергей Васкецов
Например, считаете ли Вы, что после смены наименования региона (область -> край) у всех, кому в этом регионе выдавали паспорта, в паспортах резко сменился орган, который выдавал этот документ?

Не знаю, вряд-ли, ведь у меня в паспорте например местом рождения числится Свердловск, хотя это теперь Екатеринбург.
Кстати, а вот вы будете разбивать поле Прописка на составляющие ? Имхо та-же история - хотим работать с ее составляющими - выносим, не хотим - вписываем в одно текстовое поле ...

Сергей Васкецов
Архитектор любой системы должен предполагать, что будет с системой, если чуть-чуть колыхнуть предпосылки, на которых система построена. Ваша система не обладает достаточной гибкостью. К чему это приведет - пока сказать сложно, может быть потеряете клиента, если он будет настаивать на оформлении не по паспорту, может быть потребуется внести изменения и переписать функциональность и всякие отчеты. Я же предпочитаю сделать сразу правильно , чтобы потом не было мучительно больно.

вы-же сами написали "Если же ничего кроме реквизитов УЛ мне не надо, то достаточно просто текстового поля, где будет писаться наименование органа, выдавшего УЛ, в точном соответствии с тем, как оно написано в самом УЛ" . Почему-же если мне нужны только аттрибуты паспорта, то вписывать его в таблицу владельца неправильно ?
На самом деле хочу сказать, что вы с MasterZiv'ом меня безусловно убедили в необходимости выноса сущностей, спасибо вам, просто есть пара моментов, которые не дают спокойно спать. Если отделение милиции мне как таковое не нужно и его можно оставлять в таблице с паспортом, то почему если не нужен паспорт как таковой, то его нельзя оставить в таблице с владельцем ? Так, на всякий случай ? Только из-за пресловутой гибкости системы ?

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

а вот давайте теперь колыхнем вашу систему - скажем заказчик теперь хочет знать, сколько у него иногородних клиентов (не такое-уж невероятное изменение в требованиях), а прописка у вас, по вашим словам, текстовое поле. Что вы будете делать ? Система-то негибкая получилась. По такой логике получается нужно вообще все сущности разделять. Даже пример MasterZiv'а про телефоны перестает работать - вдруг там клиент захочет теперь знать, из каких городов чаще выигрывают - придеться телефон таки бить на составляющие номера и уносить в другое место. Да и отделение милиции с кодом подразделения из паспорта можно вынести - тоже на всякий случай, ради гибкости.

474
Я про это и писал. Рад, что стало понятно.

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

474
Запись о получении аванса в системе - это отражение факта в реальном мире. Если одному и тому-же человеку выдали аванс дважды, что запрещено правилами - отрывать голову надо тому, кто выдал. Почему ему - потому что правила пишутся для людей, а не для компьютеров.

Внутри системы эти два человека - это один объект, но в срезах на конкретную дату у него могут быть разные значения атрибутов. Если в требованиях на систему было прописано соответвие правилам (то есть ограничение на выдачу аванса дважды), но реализовано не было - тогда дополнительно оторвать голову и программисту.

тогда спрошу по-другому: хорошо, в системе это один человек, реализовано правило о невыдаче аванса дважды - все замечательно.
По вашим словам "Вы в жизни себе представляете хоть один бумажный отчет в котором вместо ФИО - табельные номера?" в бумажных документах и на экране компьютера вашей системы человек идентифицируется ФИО + паспорт (внутри системы может быть также или введен суррогатный ключ). Кроме того, ФИО и паспорт показываються в соответствии с историей - если в апреле Иванова была Петровой, то на экране за апрель светиться именно Петрова. (кстати вы откуда вообще взяли такую дурацкую постановку задачи ? Никого не интересует, какое ФИО у нее было в апреле, если это не отделение милиции. И табельные номера с номерами клиентов к клиниках введены вовсе не для того, чтобы реализовывать такие требования - просто встречаются абсолютные тезки, и в отчетах для различения их пришлось-бы вбивать номера паспортов).
Все верно, я ничего вам не приписал ?
Так вот, бухгалтер хочет выдать аванс Ивановой (паспорт 45 3456), но система говорит, что этот человек уже получал аванс в этом месяце. Бухгалтер запрашивает отчет об авансах за этот месяц и конечно никакой Ивановой (паспорт 45 3456) там не находит, ибо она там еще была Петровой (паспорт 66 7890). Что теперь должна делать бухгалтер и кому будем отрывать голову ?