В этом техническом описании мы расскажем, что такое моделированием данных, почему оно имеет такое значение, и какие концепции и методы лежат в основе моделирования данных.
ОТНОШЕНИЕ
В основе реляционных баз данных лежит концепция о том, что данные в базе данных ссылаются на другие порции данных в той же базе данных, или связаны с ними. Работа с базой данных, в которой не определены отношения, напоминает ситуацию, в которой все квитанции, платежные чеки и финансовые отчеты сваливаются на хранение в одну большую корзину. Если вы не знаете, как эти порции документов относятся друг к другу, то как вы сможете управлять своими финансами или платить налоги? Если в вашей модели данных не определены отношения, то ситуация ничуть не лучше: различные сущности и их атрибуты должны быть связаны с другими сущностями и атрибутами, и нам придется документировать все эти отношения. В модели данных существует три основных типа логических отношений: один к одному, один ко многим и многие ко многим.
Каждый тип отношений описывает особый способ связи двух порций данных.
Отношение "один к одному"
Отношение "один к одному", наверное, проще всего для понимания, но, к сожалению, не слишком часто используется. Отношение " один к одному" означает, что для каждого экземпляра родительской сущности существует один и только один, не больше и не меньше, экземпляр в дочерней сущности. Эту ситуацию можно сравнить с игрой в мяч: в каждый момент только один игрок может бросить мяч, и только один игрок реально может его поймать.
Отношение "один ко многим"
Этот тип отношения - самый распространенный тип отношений и именно с ним знакомы большинство людей. В отношении " один ко многим" один экземпляр в родительской сущности относится ко многим экземплярам в дочерней сущности. На практике этот тип отношения можно назвать отношением "один к одному или более", поскольку обычно в дочерней сущности есть хотя бы один значимый экземпляр, но их может быть больше. В семантическом отношении это более важно при моделировании физической базы данных, поскольку в функциональном определении необходимо точно указать, сколько записей имеется в родительской сущности (таблице) и сколько в дочерней. Простейший пример отношения "один ко многим" - это модель заказа и информации по заказу. Для каждого экземпляра заказа в сущности Заказы может быть несколько позиций, каждая из которых является экземпляром в дочерней сущности Информация по Заказу.
Отношение "многие ко многим"
Из трех основных типов отношений отношение "многие ко многим" является самым трудным для понимания и обычно самым трудным для моделирования. Отношение "многие ко многим" имеет место, если один (или более) экземпляров в родительской сущности может быть связан с одним (или более) экземплярами в дочерней сущности, и наоборот. Представьте себе, например, модель данных для запасных частей к автомобилям, в частности, сидений для автомобилей класса "седан". В седане используется два типа сидений: сиденье ковшового типа для водителя и пассажира спереди и многоместное неразделенное сиденье для пассажиров в задней части автомобиля. Поэтому в модели данных, по-моему, должна быть сущность Модели для седана, а сущность Сиденья для сидений. Сначала это выглядит как отношение "один ко многим" от сущности Модели к сущности Сиденья. Однако многие производители автомобилей используют одни и те же сиденья в различных моделях. Поэтому речь идет об отношении между несколькими экземплярами сущности Модели и несколькими экземплярами сущности Сиденья. Принципиально, это и есть отношение "многие ко многим". Здесь мы снова имеем дело с логической версией этого отношения, которое физически реализуется в базе данных как отношение "многие ко многим", требует использования третьего объекта (таблицы) для физического применения правил, которым подчиняется отношение.
По этой причине для того, чтобы во всех аспектах описать существование отношения и поддержать разработку физической базы данных, возможно, хорошей идеей будет моделирование отношения с помощью третьей сущности.
ДОМЕНЫ
В ходе разработки модели данных и определения атрибутов для каждой сущности почти всегда находятся атрибуты, которые существуют в нескольких сущностях, поскольку являются довольно общими типами данных. Например, можно хранить в базе данных адреса клиентов, поставщиков и сотрудников. Каждый из этих объектов представляет собой явную и отдельную сущность, и для каждого из них необходимо хранить адрес. Чтобы обеспечить непротиворечивость, можно создать домены атрибутов, которые будут одинаковыми во всех сущностях. Домен - это определение атрибута, которое содержится в логической модели, но не привязано непосредственно к какой-либо данной сущности. Если вы создали домен, то можете добавить этот домен к соответствующим сущностям, после чего данный домен отображается в данных сущностях как атрибут. Однако такой атрибут нельзя изменять в данной сущности до тех пор, пока он не будет выделен из домена. Это позволяет гарантировать целостность данных во всех сущностях, имеющих одни и те же атрибуты. Итак, мы можем создать домен "адрес", определяющий тип данных и длину поля для записи адреса. Это немного упростит код приложения, так как всегда известно, как именно вводить информацию об адресе, независимо от сущности.
НОРМАЛИЗАЦИЯ
Нормализация - это процесс группирования данных логическим образом, позволяющее избежать дублирования и усложненности данных. Существует много уровней (или форм) нормализации, каждый следующий уровень является более строгим, чем предыдущий; мы рассмотрим все формы, чтобы вам было легче разобраться, в какие моменты в процесс вмешиваются ограничения реального мира. Первые правила нормализации были разработаны Е. Ф. Коддом (E. F. Codd), сотрудником исследовательского сектора IBM. Правила применяются как последовательный ряд форм модели данных, причем каждая следующая форма является более строгой, чем предыдущая. Сначала было разработано всего три формы; однако в ходе дальнейших исследований были обнаружены некоторые потенциальные проблемы с обновлением данных, поэтому были добавлены еще две формы, позволяющие избежать этих проблем. Общее название форм - нормальные формы; их названия соответствуют их положению в последовательности за небольшим исключением, о котором речь пойдет далее.
ПЕРВАЯ НОРМАЛЬНАЯ ФОРМА (1НФ) Чтобы модель данных соответствовала 1 нормальной форме, все сущности в модели должны иметь первичные ключи. Первичный ключ сущности представляет собой атрибут или набор атрибутов, определяющих уникальный экземпляр в этой сущности. Очевидно, что первичный ключ никогда не может иметь значение null, поскольку это атрибут, определяющий все экземпляры. Кроме того, никакие два экземпляра не могут иметь одинаковые значения в качестве своих первичных ключей. 1 нормальная форма также требует, чтобы в модели не было повторяющихся групп. Повторяющаяся группа - это группа, в которой любой атрибут имеет несколько значений, связанных с одним значением в другом атрибуте того же экземпляра. Если, например, у нас есть сущность Исполнители, в которой хранится информация о записывающих альбомы исполнителях, вероятно, у нас есть и названия записанных ими альбомов. Если какой-либо исполнитель записал более одного альбома, то мы могли бы создать атрибут НазваниеАльбома, в котором хранились бы названия альбомов для каждого исполнителя. Однако на самом деле у вас есть несколько значений одного атрибута (НазваниеАльбома), которые связаны с одним значением (ИмяИсполнителя) для одного экземпляра. Чтобы исправить ситуацию, вам придется выделить альбомы в отдельную сущность и создать отношение между этими двумя сущностями.
ВТОРАЯ НОРМАЛЬНАЯ ФОРМА (2НФ)
Вторая нормальная форма требует, чтобы все неключевые атрибуты зависели только от всего первичного ключа в целом. Очевидно, что для сущностей, первичный ключ которых состоит из одного атрибута, это не является проблемой. Однако если ваша сущность имеет составной первичный ключ (то есть, первичный ключ состоит более чем из одного атрибута), то вторая нормальная форма требует, чтобы все другие атрибуты в сущности были связаны со всеми атрибутами в первичном ключе. Если имеется атрибут, который связан только с одной частью первичного ключа, то, возможно, этот атрибут является частью другой сущности, с отношением, направленным к данной сущности через внешний ключ. Внешний ключ - это атрибут, который не является ключевым атрибутом в дочерней сущности и определенно соответствует атрибуту первичного ключа в родительской сущности.
Хорошим примером является сущность, в которой хранится информация об изделиях.
Например, у нас есть сущность Изделие, первичным ключом которой является ИдентификаторИзделия (числовой идентификатор изделия), НазваниеИзделия и ИдентификаторСклада (позволяющий идентифицировать место хранения изделия). Остальные атрибуты в данной сущности - это АдресСклада, ОписаниеИзделия, НазваниеПоставщика и ИдентификаторПоставщика. Очевидно, что атрибут АдресСклада не связан непосредственно с именем изделия, потому что склад имеет адрес независимо от того, какие изделия в нем хранятся. Поэтому вполне вероятно, что нужно создать сущность Склад, а сущность Изделия будет иметь отношение к этой сущности, определяющей место хранения каждого изделия.
Читать часть 4