4.2.4 Получение схемы базы данных из модели «сущность-связь».

В первую очередь, прежде, чем получать схему базы данных, мы должны определить, для какой именно СУБД мы будем это делать. Выбор СУБД – отдельный и достаточно сложный вопрос. Коротко можно отметить, что необходимо учитывать и возможности СУБД в части хранения данных и обеспечения быстрого доступа к ним, причем не на момент создания БД, а на перспективу, чтобы не пришлось в ближайшем будущем переносить данные в другую БД (что может оказаться труднее, чем создать первоначальную). Кроме того, нужно учитывать и степень поддержки языка запросов, и наличие драйверов для доступа к данным из разрабатываемого приложения и другие подобные вопросы. Наконец, экономический аспект, то есть, стоимость лицензий на СУБД, также имеет большое значение. Но пока оставим эту тему в стороне.

После того, как СУБД выбрана, мы должны определить типы атрибутов, или уточнить их, учитывая тот набор типов полей, который доступен в выбранной СУБД. Конечно, большая часть типов совпадает в разных СУБД, но все же этому вопросу надо уделить пристальное внимание. Правильный выбор типов обеспечивает надежное хранение данных и их эффективную обработку.

Если мы подходили к построению модели предметной области внимательно и вдумчиво, то схема базы данных, которая строится по этой модели, будет как минимум в третьей нормальной форме. Связи «один к одному» и «один ко многим» реализуются в виде внешних ключей. Преобразовываться специально должны связи «многие ко многим», если онb еще остались, и обобщенные и производные сущности.

О связях «многие ко многим» мы уже сказали достаточно, рассмотрим вопрос преобразования обобщенных сущностей. Варианты преобразования достаточно хорошо видны из диаграммы – мы можем поместить все сущности в одну таблицу, создав поля для всех атрибутов, можем создать таблицу для каждой сущности (в том числе, и для «базовой»), либо использовать какой-то промежуточный вариант.

В первом случае мы несем затраты на выделение места для неиспользуемых полей – в каждой записи поля, которые не относятся к данному экземпляру сущности, будут оставаться пустыми. Зато так достигается максимально быстрое извлечение записей, ведь они все в одной таблице.

В случае, когда для каждой сущности есть отдельная таблица, мы не расходуем зря место, но при необходимости получить даже информацию об отдельной сущности у нас возникает необходимость соединять две таблицы – а это достаточно затратная операция с точки зрения времени выполнения. В некоторых случаях базу данных даже проектируют так, чтобы полностью избежать необходимости соединять таблицы, пусть даже и ценой дублирования данных.

Однозначной рекомендации дать невозможно. В каждом случае нужно смотреть и на количество производных сущностей, и на количество их экземпляров, и на то, какими атрибутами и в каком количестве они обладают. И, конечно, на то, как часто будут нужны те или иные значения атрибутов, какие именно операцию будут выполняться с этими данными.

Наконец, нужно сказать несколько слов о проблеме выбора первичных ключей. Как мы знаем из определения первичного ключа, это атрибут или набор атрибутов, значения которого позволяют однозначно идентифицировать запись. Таким образом, первичный ключ должен быть уникальным. Но помимо уникальности можно выделить еще и требования к постоянству его значения и к его размеру. Эти требования вытекают из того, что в реляционных БД для связей между таблицами используются поля внешних ключей. То есть, первичный ключ из главной таблицы может многократно встречаться в подчиненных таблицах. И здесь вопрос размера ключа может оказаться довольно существенным. Одно дело, если мы уменьшили ключ, скажем, на 10 байт – о такой экономии говорить смешно. И другое дело, если он связывает запись в главной таблице с десятками тысяч записей в подчиненной – тут уже речь идет о мегабайтах. Конечно, при современных ценах на накопители, экономия даже и десятков мегабайт на дисках – это не слишком выгодное дело. Но надо помнить, что операции выполняются в оперативной памяти. И чем короче ключ, тем меньше он будет занимать места в памяти, и тем быстрее будут выполняться операции сравнения значений ключей. Неизменность значений ключа также вытекает из наличия связей: одно дело изменить значение первичного ключа в одной записи, и совсем другое – изменить значение внешнего ключа в десятках тысяч (а то и миллионах) связанных записей. Конечно, это можно выполнить, но регулярно это делать не стоит.

Те атрибуты, которыми сущности обладают в реальности (так называемые естественные ключи) довольно редко обладают уникальностью, неизменностью во времени, да еще и малым размером. Поэтому, довольно часто используют так называемые искусственные ключи – то есть, добавляют в таблицу поле, значение которого никак не связано со значениями атрибутов и служит только для идентификации записи. Часто это просто порядковый номер записи, и большинство СУБД имеет встроенную возможность автоматического присвоения номеров записям.

При использовании таких искусственных ключей мы достигаем всех трех целей – ключ небольшого размера (восьмибайтного целого хватит практически для всех разумных случаев), он уникален, и со временем не меняется (так как причин для этого нет). Минус всего один – из естественного ключа мы в некоторых случаях может извлечь полезную информацию, даже не открывая саму запись, искусственный ключ никакой информации о записи не содержит. В качестве компромисса можно использовать какую-то собственную систему кодирования, в которой по коду можно что-то сказать о записи, которой он присвоен, но это удается не всегда.

Какие именно ключи использовать – зависит от выбранной предметной области, СУБД и предпочтений проектировщика. Единого мнения на этот счет нет, существуют и высказываются разные точки зрения.