Источники данных для концептуального проектирования

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

Основные источники:

- сведения, полученные от экспертов;

- документальные источники.

Работа с экспертами.

Необходимо собеседование с многочисленными экспертами, т.к. ни один человек не может оценить потребности всей организации в данных.

Необходимо уметь задавать экспертам нужные вопросы, ответы на которые помогут, например, отличить сущности и атрибуты.

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

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

Работа с документальными источниками.

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

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

Построение концептуальной схемы

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

Предлагается использовать набор условных обозначений, который отличается от символов, используемых в CASE – средствах и стандарте IDEF1X (рисунок 3.1).

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

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

Рисунок 3.1 – Условные обозначения

Рисунок 3.2 – Пример концептуальной схемы данных

Проектирование базы данных на логическом уровне

Исходные данные для проектирования

Концептуальная модель – СУБД – независимая модель данных.

Требования к эксплуатационным характеристикам.

Количественные оценки объема данных и частоты решения задач.

Требования к программному обеспечению.

Характеристики СУБД.

Имеющиеся вычислительные ресурсы.

Результаты проектирования

Логическая модель – СУБД – ориентированная схема.

Подсхемы БД – представления разных групп пользователей.

Требования для физического проектирования.

Руководство по проектированию программ.

Руководство для группы сопровождения базы данных.

Требования к эксплуатационным характеристикам

Целостность – свойство базы данных, при котором данные удовлетворяют некоторым ограничениям и сохраняют это качество при любых изменениях (замене, добавлении или удалении).

Например: ограничение в виде диапазона, списка допустимых значений или соответствия некоторому бизнес – правилу.

Требование целостности:

- ограничение;

-правила применения ограничений;

- правила обработки данных при нарушении ограничения целостности;

- эффективность применения ограничений.

Согласованность – свойство базы данных выдавать одинаковые ответы на одновременные запросы разных пользователей.

Например: блокировка доступа к данным на время, когда в них вносятся изменения.

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

Требования согласованности:

- алгоритмы корректировок;

- время на одну модификацию;

- время между двумя модификациями.

Восстанавливаемость – возможность восстановления целостности БД после любого сбоя.

Требование восстанавливаемости – время на восстановление.

Требования целостности, согласованности и восстанавливаемости – самые "жесткие" ограничения при проектировании БД на логическом уровне.

Безопасность – защита данных от преднамеренного или непреднамеренного доступа, модификации или разрушения.

Требования безопасности:

- уровни блокирования данных;

- допустимые накладные расходы.

Эффективность – используемые вычислительные ресурсы и время отклика.

Варианты требований эффективности:

- min времени;

- min внешней памяти;

- min времени при min памяти.

3.4 Особенности учета требований при проектировании БД

В общем случае проектирование БД может рассматриваться как решение оптимизационной задачи:

- ограничения задаются требованиями целостности, согласованности, восстанавливаемости и безопасности;

- целевая функция – требование эффективности.

На практике математические методы для решения данной задачи не применяются. Обычно используют следующие правила:

- чем выше избыточность данных в базе, тем меньше время поиска, выше стоимость корректировки и больше требуемый объем внешней памяти;

- поддержание целостности и согласованности увеличивает время отклика;

- чем сложнее и быстрее восстанавливается база данных, тем выше накладные расходы и т.д.