24. Проверка логической модели с помощью правил нормализации и в отношении транзакций пользователей.

Логическая структура реляционной БД – это адекватное отображение модели. Проектирование схемы БД должно решать задачи минимизации дублирования данных и упрощения процедур их обработки и обновления. При неправильно спроектированной схеме БД могут возникнуть аномалии модификации данных. Проверка модели с помощью концепций нормализации – целью применения этой процедуры является получение гарантий того, что каждое из отношений, полученных на основе концептуальной модели, находится, по крайней мере, в третьей нормальной форме. Обязательным является выполнение требований до 3-ей НФ. В отдельных случаях необходимо приводить к НФ БК, поэтому следующий этап состоит из действий:

- из отношений удаляются повторяющиеся группы атрибутов;

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

- устраняется транзитивная зависимость от первичных ключей;

- все детерминальные отношения были потенциальными ключами.

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

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

Последний шаг логического проектирования БД является определение требований поддержки целостности данных. Ограничение целостности представляет собой набор правил, которые позволяют предотвратить ввод в БД противоречивых данных. Различают 5 типов целостности данных: 1.Обязательные данные; 2.Ограничение для доменов атрибутов; 3.Целостность сущностей; 4.Ссылочная целостность; 5.Требования данного пользователя. На этапе обязательных данных, необходимо отметить данные, которые являются справочными и без наличия этих данных невозможна дальнейшая работа. Обязательные данные задаются в процессе документирования каждой сущности и заносятся в словарь данных. В ограничении для доменов атрибутов указывается область определения атрибутов, если такая необходима. Целостность сущностей. Значение первичного ключа не должно иметь NULL-значения. Ссылочная целостность. Для каждого внешнего ключа должно быть соответствующее значение первичного ключа.

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

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

1. Перенос глобальной логической модели в среду СУБД

1.1 проектирование таблиц БД в среде СУБД;

1.2 реализация бизнес правил предприятия в среде СУБД;

2. Проектирование физического представления БД в среде СУБД

2.1 анализ транзакций;

2.2 выбор файловой структуры;

2.3 определение вторичных индексов;

2.4 анализ необходимости ведения контроля избыточности функций;

3. Определения требований к дисковой памяти защиты БД

3.1 разработка пользовательских представлений;

3.2 определение прав доступа к функциям;

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

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

1. Поддерживает ли система определение первичных, вторичных, альтернативных ключей; 2. Допускает ли СУБД определение обязательных данных; 3. Поддерживается ли определение доменов; 4. Допускаются ли определения бизнес-правил предприятия; 5. Способ определения таблиц БД.

Эффективное хранение данных.

Имеется ряд показателей, которые позволяют определить оценку достигнутой эффективности:

1. Пропускная способность транзакции. Этот показатель позволяет определить какое количество транзакций может быть отработано за данный промежуток времени; 2. Время ответа. Характеризует временной промежуток, необходимый для выполнения одной транзакции; 3. Дисковая память. Характеризует объем дискового пространства для размещения БД. Чтобы достичь требований эффективности физического проектирования БД, разработчик должен решить, как взаимодействует между собой и основными компонентами оборудования и каким образом это будет влиять на общую производительность системы: ОП, процессор, диск в/в, сеть. Необходимо иметь максимальные сведения о запросах и транзакциях, которые будут выполняться для этой БД. Рекомендуется выбирать основные группы.