В этом техническом описании мы расскажем, что такое моделированием данных, почему оно имеет такое значение, и какие концепции и методы лежат в основе моделирования данных.
ВАЖНОСТЬ МОДЕЛИРОВАНИЯ ДАННЫХ
Почему так важно иметь эффективные модели данных? Во-первых, эффективная модель данных способна обеспечить более высокую производительность, особенно для систем оперативной обработки транзакций (online transactional systems, OLTP). Во-вторых, эффективная модель данных гарантирует создание хорошо документированной, масштабируемой базы данных. Если пренебречь разработкой эффективной модели данных, то вам придется помучиться, когда дело дойдет до добавления в модель новых данных; в конце концов, пострадает ваша физическая база данных.
ПРОИЗВОДИТЕЛЬНОСТЬ
Эффективное моделирование данных обеспечивает высокую производительность работы РСУБД, Во-первых, выполнение стандартных правил моделирования данных поможет вам устранить алогичности данных, например, их дублирование, что в конечном итоге поможет избежать необходимости встраивания в приложение дополнительной логики для обработки этих алогичностей. Кроме того, при хранении данных в структурированном формате ядро запросов может найти и извлечь данные быстрее, чем в том случае, если они хранятся в плоском файле или являются плохо структурированными. Это обусловливает более высокую производительность вашего приложения и/или отчетов.
ДОСТУПНОСТЬ ДАННЫХ
Эффективная модель данных делает данные, хранящиеся в вашей базе данных, более понятными. Если ваши сущности и таблицы хорошо определены и правильно классифицируют данные, с которыми вам приходится работать, то анализ этих данных посредством отчетов или через хранилище данных будет существенно более простым и эффективным. Если вы не можете найти данные, то вы не сможете их использовать. Одним из главных преимуществ надежной, хорошо продуманной модели данных реализуется в процессе разработки физической базы данных. Это особенно заметно в масштабных проектах, над которыми может одновременно работать несколько разработчиков: комплексные модели данных позволят каждому из разработчиков работать над своей секцией базы данных, не теряя из виду всей базы данных в целом. Это поможет предотвратить дублирование заданий, обеспечит дополнительную гибкость в назначении разработчиков и более быструю и сплоченную работу в фазе разработки, по крайней мере, в отношении базы данных.
СОЗДАНИЕ МОДЕЛИ ДАННЫХ
Чтобы на деле приступить к созданию моделей данных, вам необходимо иметь представление о сущностях, атрибутах и отношениях. Эти понятия являются кирпичиками, из которых строятся модели данных. Мы подробно рассмотрим каждую из структур и расскажем о том, как использовать их для построения логической модели.
СУЩНОСТИ
Сущности - это главные объекты, которые используются в модели данных. Сущность - это представление, или результат классификации, отдельного типа данных. Клиенты, заказы, продажи, изделия - все это примеры сущностей. Логически каждая сущность представляет собой набор экземпляров определенного типа данных. Экземпляр - это одно вхождение упомянутого фрагмента данных. Чтобы лучше разобраться в этих понятиях, вспомните отношение строк к таблицам в физической базе данных: строки относятся к таблицам так же, как экземпляры к сущностям.
Обратите внимание на то, что, хотя между таблицами/строками и сущностями/экземплярами есть определенное сходство, не поддавайтесь искушению всегда воспринимать сущности как таблицы. Не забывайте, что сущность - это логическое представление некоторого типа данных, а таблица - это физическая структура хранения для данных. Наконец, одна сущность может быть физически реализована как одна или более таблиц, и, наоборот, одна физическая таблица может включать несколько сущностей (хотя и чрезвычайно редко).
Анализируя требования к модели данных и пытаясь определить, какие фрагменты информации необходимо отнести к сущностям, ищите ключевые слова, например, заказчик, производитель, изделие и т. п. Обычно это имена существительные, которые упоминаются в интервью с пользователями, и заметки, сделанные в ходе наблюдений. Не забывайте о простом практическом правиле: существительные означают сущности. Если вы видите, что какой-либо тип данных описывается как элемент или объект, то этот тип данных обычно и будет искомой сущностью.
АТРИБУТЫ
Атрибут - это дескриптор конкретного экземпляра в сущности. Сущность обычно имеет несколько атрибутов. Предположим, например, что мы создали сущность с именем ОшейникДляСобак, представляющую ошейники для собак, которые продает магазин товаров для животных. Каждый ошейник имеет набор физических атрибутов (признаков): цвет, длина, ширина и т. п. Эти атрибуты будут атрибутами и для данной сущности: Цвет, Длина, Ширина, Торговая Марка и т. д. В процессе конструирования модели данных для каждой сущности будет определен набор атрибутов, описывающих данные, которые хранит эта сущность.
С атрибутами связана весьма специфическая проблема, которую необходимо решить - какой именно сущности "принадлежит" данный атрибут. Эту ошибку совершают, в основном, при проектировании приложения (и его модели данных/базы данных) на основе физического процесса (который в настоящее время не связан ни с каким приложением). В классическом примере с розничной торговлей информация о клиенте (номер телефона и адрес) часто хранится вместе с каждой записью, которую делает клиент. При создании модели данных нетрудно ошибочно преобразовать ее в физическую документацию (например, в виде таблицы) непосредственно в сущностях. В примере с заказами сущность Заказы может иметь присоединенные атрибуты клиента. С логической точки зрения это неправильно. Заказ - это логический фрагмент данных, или объект, а клиент - логический объект. Атрибуты Номер Телефона и Адрес должны ассоциироваться с клиентом, а не с заказом.