Пора поговорить подробнее о проектировании базы данных. Проектирование осуществляется в три этапа:

  1. Концептуальное проектирование;
  2. Логическое проектирование;
  3. Физическое проектирование.

2.1. Концептуальное проектирование

Задача концептуального проектирования – создание концептуальной модели данных исходя из представлений пользователей о предметной области. Для ее достижения выполняется ряд последовательных процедур. Пример сущностной (концептуальной) схемы:

1. Определение сущностей и их документирование.

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

2. Определение связей между сущностями и их документирование.

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

3. Создание ER-модели предметной области.

Для представления сущностей и связей между ними используются ER-диаграммы (Entity–relationship). На основе создаются единый образ нашей моделируемой предметной области.

4. Определение атрибутов и их документирование.

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

  • имя атрибута и описание;
  • тип и размерность значений;
  • значение, принимаемое для атрибута по умолчанию (если такое имеется);
  • может ли атрибут иметь NULL-значения;
  • является ли атрибут расчетным, и если это так, то как вычисляются его значения;
  • является ли атрибут составным, и если это так, то из каких простых атрибутов он состоит. Например, атрибут "Ф.И.О. клиента" может состоять из простых атрибутов "Фамилия", "Имя", "Отчество", а может быть простым, содержащим единые значения, как-то "Иванов Иван Иванович". Если пользователь не нуждается в доступе к отдельным элементам "Ф.И.О.", то атрибут представляется как простой;
Java-университет

5. Определение значений атрибутов и их документирование.

Каждому атрибуты мы должны описать набор допустимых значений и имя для него. Например, роль пользователя может иметь только “Администратор” , “Преподаватель”, “Студент” и эти значения так же заносятся в словарь.

6. Определение первичных ключей для сущностей и их документирование.

Здесь мы должны определить что мы будем помечать как первичный ключ, одно значение, несколько значений и как они будут связаны. Эти данные так же заносятся в словарь.

7. Обсуждение концептуальной модели данных с конечными пользователями.

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

2.2 Логическое проектирование

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

Пример логической схемы БД.

1. Выбор модели данных.

Выбирается реляционная/нереляционная модель данных в связи с наглядностью табличного представления данных и удобства работы с ними.

2. Определение набора таблиц исходя из ER-модели и их документирование.

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

3. Нормализация таблиц.

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

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

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

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

5. Определение требований поддержки целостности данных и их документирование.

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

  • обязательные данные. Есть ли атрибуты, которые не могут иметь NULL-значений;
  • ограничения для значений атрибутов. Допустимые значения для атрибутов;
  • целостность сущностей. Она достигается, если первичный ключ сущности не содержит NULL-значений;
  • ссылочная целостность. Она понимается так, что значение внешнего ключа должно обязательно присутствовать в первичном ключе одной из строк таблицы для родительской сущности;
  • ограничения, накладываемые бизнес-правилами. Каждая из ролей может выполнять определенный список операции и мы можем это разграничивать.

Все эти сведения переносятся в словарь.

6. Создание окончательного варианта логической модели данных и обсуждение его с пользователями.

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

2.3. Физическое проектирование

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

1. Проектирование таблиц базы данных средствами выбранной СУБД.

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

2. Реализация бизнес-правил в среде выбранной СУБД.

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

Все решения, связанные с бизнес-логикой описываются в сопроводительной документации.

3. Проектирование физической организации базы данных.

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

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

Все это так же документируется.

4. Разработка стратегии защиты базы данных.

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

5. Организация мониторинга функционирования базы данных и ее настройка.

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

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