Comments 12
Любая БД является моделью некоего процесса, отображением значений и зависимостей характеристик этого процесса. Зависимости в значения данных, о которых вы ведёте речь, являются следствиями зависимостей внутри процесса, который моделируется. В связи с чем стремление "забыть" об исходнике и придумывать эти зависимости только на основе данных модели - по меньшей мере странно и не очень разумно. Хотя бы потому, что объём данных почти наверняка не покрывает область допустимых значений параметров. Собственно изъяны ака аномалии и есть следствие этой неполноты.
И поневоле возникает вопрос - а нафига оно вообще такое надо? К сожалению, именно на этот вопрос ответа в статье я не вижу.
Собственно изъяны ака аномалии и есть следствие этой неполноты.
Я бы сказал, что аномалии это следствие плохой декомпозиции, когда в одной таблице смешивают факты разного порядка. Статья как я понял пытается дать теоретический базис для джунов, им полезно знать что зависимость не просто "так бизнес сказал", а строгое математическое отношение, которое можно вертеть аксиомами Армстронга.
Другой вопрос, что без привязки к реальному проектированию это превращается в абстракцию ради абстракции..
Автору невдомек (или делает вид) что такое нормализация базы данных, например, до 3-ей формы. Иначе сформулированных вопросов для рассмотренного примера просто не было бы.
Пример с оценками немного оторван от суровой реальности: в жизни зависимость Студент -> Оценка может сломаться не только потому, что Иван получил четверку, а потому что Иван пересдал, и теперь у нас историчность данных. И функциональная зависимость превращается в темпоральную, где (Студент, Предмет, Дата) -> Оценка
Статика в БД - редкий зверь
А зачем все это
Хороший вопрос.
И не говорите. Жаль, что ответа я так и не увидел (плохо смотрел?).
Мне когда-то объяснили очень просто. Любой факт должен быть отражён в идеальной базе (не подверженной техническим ограничениям и не требующей кеширования) ровно один раз. Иначе возможен конфликт: в одном случае факт изложен так, а в другом — иначе, и вы не будете знать, чему верить, не вводя правил приоритетов, что для идеальной базы нежелательно. Поэтому проектируем базу так, чтобы исключить конфликты (нормализуем), для чего выделяем преподов с их кафедрами в справочник.
А тут — функциональные зависимости, конгресс, немцы… Функциональные зависимости — это всё то, что настолько очевидно при проектировании с нормализацией, что мы опускаем в рассуждениях, но для чего кому-то обязательно надо придумать закорючки формальной записи, или тут есть какое-то двойное дно, которое я упускаю? Заранее спасибо.
Спасибо за комментарий!
Любой факт должен быть отражён в идеальной базе (не подверженной техническим ограничениям и не требующей кеширования) ровно один раз. Иначе возможен конфликт
Согласен. Как раз об этом в подробностях будет рассказано в статье про нормализацию и нормальные формы.
Данная же статья статья рассматривает теоретическую сторону ФЗ, для дальнейшего использования теории на практике в нормализации БД.
Функции - частный случай отображений, которые бывают сюръективными, инъективными, биективными. Эти свойства переносятся и на функции, о чем автор даже не упоминает. Подход в целом очень ограничивает рассмотрение функций в БД.
Вот в таком виде ФЗ наконец начинают укладываться в голове
Самое интересное начинается, когда Сазонов переходит на кафедру физики, а Никитенко по совместительству замещает ушедшую в декрет преподавательницу математики.
Разбираемся в функциональных зависимостях БД