Создание диаграмм

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

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

Если моделируется существующий бизнес-процесс, используйте бумажные документы и формуляры для определения атрибутов каждого объекта. Например, картотеку компании, торгующей автомобилями, наверняка можно взять за основу при выборе способа описания автомобилей. Поля учетной карточки трансформируются в столбцы таблицы базы данных.

Не все из нас художники, поэтому для составления диаграмм лучше пользоваться специализированными приложениями. Наиболее популярны пакет Visio компании Microsoft (www.microsoft.com/office/visio)и его открыто распространяемый эквивалент Dia (www.lysator.liu.se/~alla/dia). В последнем применяется библиотека GTK, поэтому существуют его версии для Windows.

Пакеты Visio и Dia предназначены для создания диаграмм общего назначения. Программа ArgoUML (http: argouml.tigris.org) строит диаграммы UML. Она написана на Java, поэтому может применяться в любой операционной системе, где есть виртуальная машина Java.

Пакет ERWin компании Computer Associates (www.ca.com) позволяет моделировать базы данн1х. Он может подключаться к СУБД и строить диаграммы существующих баз данных, а также создавать базы данных на основании диаграмм. Аналогичные функции выполняетпакет DeZign компании Datanamic (www.datanamic.com). К сожалению, оба они доступны только в Windows.

Реализация модели

Когда проект базы данных завершен, переходят к ее реализации. В соответствии с диаграммами создаются инструкции CREATE TABLE. Будьте готовы вернуться к этапу проектирования для внесения очередных модификаций: переход на язык SQL часто открывает различные упущения.

В спецификации проекта были описаны столбцы каждой таблицы. Для них необходимо подобрать типы данных, поддерживаемые в SQL. Дополнительно можно создать индексы, хотя зачастую схема их использования настолько сложна, что придется прибегнуть к инструкции EXPLAIN (описана в главе 13, Инструкции SQL ).

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

Реализация модели 93

сопровождающему базу данных, понять ее структуру. Синтаксис комментариев описан в начале главы 13, Инструкции SQL .

Можно также пользоваться опцией COMMENT инструкции CREATE TABLE. Такие комментарии хранятся вместе с таблицей. Для их просмотра необходимо ввести инструкцию SHOW TABLE STATUS.

При переходе от этапа проектирования к этапу реализации необходимо придерживаться пяти ключевых принципов:

первичные ключи следует помечать спецификатором NOT NULL;

пользуйтесь флагом AUTOINCREMENT для автоматического создания идентификаторов;

внешние ключи должны сстлаться на первичные ключи;

отношения многие ко многим должны устанавливаться через промежуточную таблицу;

таблицы, между которыми существуют отношения один к одному , лучше объединять.

Как правило, всякая таблица должна иметь первичный ключ. Вспомните из главы 5, Реляционная модель , что столбцы первичных ключей необходимо объявлять со спецификатором NOT NULL. В большинстве таблиц первичный ключ представляет собой отдельный столбец целочисленных значений, так как зачастую трудно сказать заранее, будут ли значения других полей уникальными. Например, всем клиентам можно присвоить целочисленные идентификаторы, что позволит различать тезок, но самим клиентам эти идентификаторы не нужны, они могут даже не догадываться об их существовании. В MySQL такие абстрактные первичные ключи реализуются в виде столбцов-счетчиков.

Внешние ключи участвуют в отношениях один ко многим . Таблица, с которой существует множественная связь, будет содержать внешний ключ, указывающий на первичный ключ противоположной таблицы. MySQL не проверяет правильность значений внешних ключей, т.е. предложения FOREIGN KEY инструкции CREATE TABLE являются необязательными. Но есть ряд причин, по которым их все же стоит указывать. Во-первых, это послужит целям документации. Во-вторых, это позволит некоторым приложениям читать схему базы данных и строить на ее основы диаграммы. Наконец, впоследствии может понадобиться передать схему в другую СУБД, где внешние ключи играют более важную роль.

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

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

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

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

Выбор правильных типов столбцов - это творческий процесс, частично связанный с анализом исходных требований. Если необходимо заботиться об экономии дискового пространства, следует выбирать минимально возможные типы, охватывающие заданный диапазон значений. Например, если известно, что в таблице будет примерно 500 строк, то трехзначного первичного ключа окажется достаточно. Спецификация INT (3) является некорректной, поскольку для типа INT MySQLвсегда использует 32-разрядное целое число. Тип TINYINT занимает один байт, что недостаточно. В рассматриваемом случае подойдет тип SMALLINT, т.е. спецификация типа должна выглядеть так: UNSIGNED SMALLINT (3).

Значения в столбцах-счетчиках должны быть беззнаковыми, потому что отрицательные целые числа будут трактоваться как большие положительные числа. Следовательно, вставка в столбец отрицательного числа приведет к тому, что следующее число окажется очень большим. Таким образом, спецификация типа поля-счетчика всегда должна включать ключевое слово UNSIGNED.

Столбцы, хранящие короткие значения одинаковой длины, например коды деталей, должны иметь тип CHAR. Правда, если в таблице есть поля переменной длины, значения CHAR могут автоматически приводиться к типу VARCHAR. Строковые поля длиной более 255 символов должны иметь тип BLOB или TEXT.

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

Индексы можно создавать не только для первичных и внешних ключей, но и для обычных столбцов. Индексы ускоряют поиск записей в запросах с объединением, группировкой или упорядочением записей. Наличие индекса позволяет сразу же перейти к нужной записи, а не сканировать всю таблицу по одной записи за раз. Однако трудно предугадать заранее, какие запросы будут выполняться тем или иным приложением. Поэтому может понадобиться проанализировать запросы с помощью инструкции EXPLAIN. Этот процесс рассматривается в главе 26, Оптимизация .

Тестирование

Тестирование бывает двух видов: на предмет поиска недочетов и на предмет проверки полноты реализации. Недочеты являются следствием человеческих ошибок. Полной считается система, удовлетворяющая всем исходным требованиям.

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