Комментарии 27
А чтобы пройти собеседование с меньшим позором — еще и добавить про отношения один-ко-многим, многие-ко-многим, один-к-одному, тогда статья станет почти эталонной :)
А потом расскажем, зачем БД индексы, расскажем про SQL, оговоримся про noSQL и перестанем укладываться в два часа :)
Был в жизни случай, когда надо было заочникам материал всего семестра упихать в голову за три часа. Вы справились лучше :)
Но я бы ещё после каждого разобранного понятия написал, как оно называется в больших и скучных учебниках — чтобы прокинуть мостик к этим учебникам, чтобы говорить с людьми, которые по ним учились, на одном языке, чтобы слова типа «третья нормальная форма» не ставили в тупик на собеседовании.
Ну, не совсем. В реальной жизни бывают такие таблицы, в которых дублирование это нормально. Просто потому, что когда вы разрабатываете что-то в рамках СУБД, то таблицы — это единственная структура данных, которая у вас есть, и поэтому скажем логи (аудит) — это тоже таблица, но без уникального ключа. Немного странно и не по книжкам, но бывает.
А еще оно служит целям резервирования и позволяет заметить несоответствия в веденных данных. Потому что если полностью удалить дублирование, то стоит в 'Персона' заменить (или изначально ввести неправильно) 'Том Хэнкс' на 'Иван Иванович' — и бедный Том Хэнкс больше никогда никому не докажет, что он вообще когда-то существовал.
Если крутить дальше, то выходим на новую табличку, назовем ее Место-в-сеансе (ИД, МестоИД, СеансИД, Цена), тут уже можно навести лад и с ценой — от фильма и типа места.
Реляционное решение есть, но с добавлением избыточности и использованием новых ключей (добавленные элементы выделены синим цветом).
Вы прям великолепно расписали. Обязательно буду кидаться ей в студентов.
Нужно было сделать БД по продаже билетов, а пришлось строить ещё БД фильмов, БД людей.
И это ещё не глубоко копнули. :-)
Тоже преподаю, но школьникам. БД упоминаем «для знакомства». А с вашим материалом теперь можно и задачки на размышление дать.
Статья — хороший пример большого недостатка РМД — многовариантность построения структур БД, что превращает эту задачу в вид искусства.
Не могу согласиться. Это не входит в рамки статьи, но если описать информационные сущности, их ключи и связи, структуру бд можно строить автоматически, потому что вариативности не остаётся. Разработать инфомодель, то есть описать предметную область — вот это ближе к искусству. Но к бд это отношения не имеет.
Пожалуйста, продолжайте этот цикл. Про триггеры там и все такое очень хочется услышать в вашем изложении.
Спасибо за статью! Я как раз пишу приложение для миникинотетра)
Как научиться проектировать реляционные базы данных за полчаса