Доброго времени суток, читатели, зрители моего канала programmer's notes. Не забывайте подписываться и писать свои комментарии к моим статьям и видео.
Данный текст является приложением к видео
Элементы проектирования реляционных баз данных
Проектирование баз данных предполагает неформальное понимание предметной области применительно к тем задачам, которые вы собираетесь решать, используя спроектированную базу данных. Можно обозначить следующую последовательность элементов анализа предметной области, приводящую в конечном итоге к правильной реляционной базе данных:
- Анализируя предметную область, выделяем сущности, необходимые нам для построения обозначенной в постановке задачи системы.
- Анализируем полученные сущности на предмет получения атрибутов этих сущностей.
- Анализ атрибутов сущностей. В результате такого анализа часть атрибутов распадаются на несколько других атрибутов. Другие же атрибуты сами превращаются в сущности.
- Определение связей между сущностями.
Для нас сегодня важен третий пункт. Чем мы и займёмся.
На рисунке 1 показана схема простой таблицы, являющейся описанием простой сущности Работник. Что нас может здесь заинтересовать? Атрибут fio (фамилия, имя, отчество) состоит из трёх частей. Т.е. атрибут является составным. Если для нашей задачи необходимо выделять отдельные компоненты, то это может вызвать определённую сложность, например, в силу того, как мы записали fio. Если мы встречаем атрибут, который состоит из нескольких компонентов, то это называют нарушением первой нормальной формы. Вообще требование первой нормальной формы предполагает, что атрибут должен простым, неделимым.
В нашем случае мы должны исходить из таблицы, представленной на рисунке 2. Мы, т.о. выполнили требования первой нормальной формы.
Следует сделать два важных замечания:
- Мы понимаем, что количество компонентов атрибута fio ограничено числом три. Т.е. мы заранее знаем сколько столбцов нам необходимо.
- Мы исходили из того, что нам понадобятся компоненты fio по отдельности. Если же нам не нужны отдельные компоненты, то и смысла деления атрибута нет. Т.е. нарушение первой нормальной формы вытекает из постановки задачи.
В представленном выше примере мы вышли из положения разделив атрибут на три части.
Рассмотрим таблицу на рисунке 3. В ней содержится информация о людях и телефонах, которые на них зарегистрированы. Нас интересует атрибут Телефоны. Т.е. в одном атрибуте перечислены телефоны некого абонента. Например так (рисунок 4)
Т.е. в строке стоит список телефонов. Разделителем может быть любой знак. В нашем случае это запятая. Если нам важны отдельные номера телефонов, а не всё перечисление, то налицо нарушение требования первой нормальной формы. Но в отличие от предыдущего примера мы заранее не знаем сколько элементов в нашем списке. Данная коллизия разрешается созданием еще одной таблицы (см. рисунок 5).
Т.е. если при нарушении первой нормальной формы не определена верхняя граница количества компонентов атрибута, то этот атрибут становится сущностью. Как видим очень простое правило. В конструкции, представленной на рисунке 5 количество номеров телефонов у отдельного абонента может быть любым.
Замечание
Превращая атрибут в сущность, мы открываем для себя возможность добавлять атрибуты уже для новой сущности. Например, для телефонов, возможно, будет необходима дата регистрации и какие то ещё характеристики.
Обратимся к ещё одной ситуации, которая может привести к тому, что атрибут может стать сущностью. Хотя это и скрытая отсылка к первой нормальной форме, но проявляется это несколько иначе. Речь идёт о том, значение атрибута может меняться во времени. Очень часто на этот аспект не обращают внимание. Обратимся снова к рисунку 2. Обратим внимание на то, что фамилия человека может меняться в течении жизни. Иногда это происходит несколько раз в течение жизни. Если вы будете просто перезаписывать значение фамилии, то теряется история этих изменений. Но это может отрицательно повлиять на ценность базы данных. Справки за прошлые годы могут оказаться недействительными, не правильно отражающими действительность на период, на который даётся справка. Если атрибут меняется с течением времени и нам нужна история его изменений, то атрибут должен стать сущностью (таблицей). См. рисунок 6.
Ну, пока всё!
Пишите свои предложения и замечания и занимайтесь программированием, а также проектированием баз данных, хотя бы для поддержания уровня интеллекта.
