Как стать автором
Обновить

Комментарии 23

Мне кажется, или это статья о том, что преподается на 1 курсе любого вуза, есть в 1 главе любой книги по бд и тонне статей даже для самых маленьких?

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

Азбуку здесь тоже не найдешь.
А может стоило бы
Действительно. Ведь куча статей вида «я распаковываю новую %железконейм%» или ставшее мемом «как я ремонтирую балкон» куда больше относятся к IT-тематике Хабра.
Прекрасная статья, лишние усложнения для понимания — я считаю понты. Еще раз. я считаю. Человек сразу обозначил для кого статья, и может я тупой, но именно это я и искал. Спасибо автору!
Foreign key (вторичный ключ) — really?

Тут бы хоть про нормальные формы написать, чтобы помяснее было, но нет...

Планирую написать отдельную статью по ним. Мне кажется, что впихнуть их сюда это будет лишним, потому что статья именно про связи.

Спасибо за работу, возможно, кому-то пост поможет.

Написанный мною код должен работать и на других СУБД, поскольку запросы являются универсальными и не используют специфических конструкций языка T-SQL.

На самом деле это не так — как минимум nvarchar и identity будут не во всех СУБД.
Выбран очень странный стиль написания имён объектов — где-то используется схема, где-то не используется. ИМХО, в «справочном» посте стиль должен быть унифицирован.
Плюс, вы много где объявляете поле как nvarchar, а вставляете туда varchar — не надо так):
create table dbo.Person
(...
	FirstName nvarchar(64) not null,
	LastName nvarchar(64) not null,
...)

insert into dbo.Person(PersonId, FirstName, LastName, PersonAge) values (5, 'John', 'Doe', 25)


Ещё хотелось бы добавить, что у явно объявленных связей есть определённые сайд-эффекты, о которых тоже хотелось бы получить информацию в таком «справочном» посте. Связи требуют определённой стратегии индексирования, которая зависит от предполагаемого использования данных.
Просто, в качестве примера, рассмотрим вот эту таблицу:
create table dbo.Phone
(
	PhoneId int identity primary key,
	PersonId int foreign key references Person(PersonId),
	PhoneNumber varchar(64) not null
)

При удалении записи из таблицы Person будет происходить полное сканирование таблицы Phone — а это прямой путь к избыточным блокировкам и/или дедлокам.
Большое спасибо за критику!

На самом деле это не так — как минимум nvarchar и identity будут не во всех СУБД.

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

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

Исправил — обращаюсь ко всем объектам через схему.

Плюс, вы много где объявляете поле как nvarchar, а вставляете туда varchar — не надо так)

Тоже исправил.

Ещё хотелось бы добавить, что у явно объявленных связей есть определённые сайд-эффекты, о которых тоже хотелось бы получить информацию в таком «справочном» посте. Связи требуют определённой стратегии индексирования, которая зависит от предполагаемого использования данных.

В ближайшее время немного подробнее опишу foreign key.

“Invalide” — не очень хорошее название для таблицы. Лучше “disability” или “employee_disability”. Звучит несколько более этично.

Согласен.
Спасибо, внес правки в статью.
там не только «звучит», там коннотация достаточно негативная.
Это для славян легко написать invalid\invalide для людей (или как в одной истории про дизайнера — он сокращал button до butt, и в проекте у него были цвета с размерами, так что даже дошло до black_big_butt), но для англоязычных это слова и у них есть свой смысл.
Интересно, что бы сказали, если бы в коде на 1С (кстати, а где еще в продакшене пишут по русски?) встретили «ВЫБЕРИТЕ ИМЯ ИЗ НЕВЕРНЫХ ГДЕ ВОЗРАСТ > 30» и т.д. (или если про дизайнера — увидев переменную «большая_черная_жопа» %) )?

PS: это я пытаюсь усилить вашу позицию, что оно не просто «звучит неэтично», на него все хорошо-англоговорящие сразу делают внутренний «эээээ, вы точно это имели в виду?» (так же как и хорошо-русскоговорящие на фразу иностранца «этот чурка»).
Заявка на создание своего введения в реляционные БД для новичков имеет право на жизнь. Как говорится пока кому-нибудь не объяснишь, сам не поймешь. Написано конечно топорно, но не у каждого найдется сил и на это. Дальше только полировать.
Связи один-к-одному не такие уж и редкие. На больших объемах данных возникает необходимость в вертикальном секционировании для ускорения работы запросов.
Если некий объект имеет множество атрибутов, часть из которых используется очень часто, а часть очень редко, целесообразно хранить их отдельно друг от друга, чтобы уменьшить расходы на чтение диска.
«вторичный ключ» перекликается с «альтернативный ключ» — по этому это название плохо применимо для «foreign key» = «внешний ключ».
Связи один-к-одному не такие уж и редкие. На больших объемах данных возникает необходимость в вертикальном секционировании для ускорения работы запросов.
Если некий объект имеет множество атрибутов, часть из которых используется очень часто, а часть очень редко, целесообразно хранить их отдельно друг от друга, чтобы уменьшить расходы на чтение диска.

Довольно-таки логично, спасибо за дополнение!

«вторичный ключ» перекликается с «альтернативный ключ» — по этому это название плохо применимо для «foreign key» = «внешний ключ».

Благодарю, заменил на «внешний ключ».

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

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

Довольно интересный подход!
Чем-то напоминает способ запоминания, когда изученный материал рассказываешь так, чтобы понял 8-летний ребенок.

На самом деле можно изучить что-то на следующих уровнях:
1) чтобы понять, но не смочь сделать
2) чтобы понять и сделать (обычно здесь останавливаются, т к дальше нет необходимости в работе)
3) чтобы обучить и передать знания и хорошо сделать
4) чтобы быстро и легко обучить и также передать знания, а также быстро и долговечно сделать

В статье не хватает акцента с необязательной и обязательной связью.
Всего в жизни 7 формальных правил, а именно:
1) один к одному с обязательной связью (у каждого гражданина РФ есть паспорт гражданина РФ и он только один)
2) один к одному с необязательной связью (у каждого человека может быть заграничный паспорт и если да, то только один)
3) один ко многим с обязательной связью (у каждого гражданина есть несколько документов, подтверждающих его личность)
4) один ко многим с необязательной связью (у каждого человека могут быть дети)
5) многие к одному с обязательной связью (у детей есть биологический отец/мать)
6) многие к одному с необязательной связью (у детей может быть отец/мать и если да, то только один/одна или сирота)
7) многие ко многим (женщины и мужчины-могут быть любовницами и любовниками причем не только относительно одного человека, а могут и не быть)
Причем отношения могут меняться-смотря как формализовать и для чего.
В этом весь фокус.
Т е можно взять детей и родитель (мама/папа)-если рассматривать без учета сирот, то связь будет обязательна, а если с сиротами-то не обязательна (многие к одному)
А вот если перевернуть: родитель (мама/папа) и дети, то необязательна-если допустить, что детей может не быть и обязательна, если дети точно есть (хотя бы один) (один ко многим).
Если же допустить в предыдущих вариантах, что ребенок может быть только один, то отношение станет 1:1 (с обязательной или необязательной связью соответственно).
А если рассмотреть вообще попечителей и детей, то получаем отношение многие ко многим.
Т е в принципе все 7 формальных правил действуют по отношении между одними и теми же сущностями. Важно формализовать ту, которая нужна для реализации (для достижения конкретной цели в предметной области).
И т д и т п

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