Определение первичных и вторичных ключей

Этапы и шаги проектирования и создания баз данных

Принципы и этапы проектирования и создания баз данных

Основные принципы проектирования баз данных.

1. Удовлетворение информационных потребностей различных поль­зо­вателей за приемлемое время и в удобной форме.

2. Гибкая и нетрудоемкая модификация при изменении предметной области, прог­рамм и технических средств.

3. Достоверность данных, исключение дублирования.

4. Защита от несанкционированного доступа.

5. Восстановление данных и надежность функционирования.

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

1.1. Определение типов сущностей. Выявление основных типов сущностей в представлениях пользователя и их документирование.

1.2. Определение типов связей. Определение типов связей между сущ­ностями; документирование и составление ER‑диаграмм.

1.3. Определение атрибутов и их связей. Связывание атрибутов с сущностями; выявление простых, составных, множественных, производ­ных атрибутов и их документирование.

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

1.6. Определение суперклассов и подклассов для типов сущностей.

1.7. Создание ER‑диаграмм для отдельных пользователей.

1.8. Согласование локальных концептуальных моделей с пользова­те­лями. При отрицательных результатах согласования нужно вернуться назад на соответствующий шаг для перепроектирования.

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

2.1. Выбор целевой СУБД. Формулирование требований и огра­ни­че­ний к CУБД. Изучение и сравнительный анализ СУБД. Оценка кандидатов и выбор СУБД.

2.2. Преобразование локальной концептуальной модели в логичес­кую. Удаление из концептуальной модели связей типа М:М, сложных, ре­кур­сивных и избыточных связей, множественных атрибутов, связей с атри­бу­тами. Перепроверка связей типа 1:1.

2.3. Определение набора отношений. Определение и документи­ро­ва­ние набора от­ноше­ний (таблиц) и связей между ними, первичных, вто­рич­ных и внешних клю­чей; форматы представления данных (столбцов) в от­ношениях.

2.4. Нормализация отношений. Проверка и, при необходимости, про­­ведение процедуры нормализации отношений, по крайней мере, в нормальную форму Бойса‑Кодда (НФБК) (п. 1.5.2).

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

2.6. Создание ER‑диаграмм для отдельных пользователей.

2.7. Определение требований поддержания целостности данных. Определение ограничений, налагаемых на отдельные элементы (поля, стро­ки, таблицы, ключи, индексы, связи), правила обновления данных, биз­нес‑пра­вила, триггеры. Документирование всех ограничений.

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

3. Создание глобальной логической (канонической) модели дан­ных. Объединение локаль­ных логических моделей в единую глобальную логическую модель всей предметной области приложения.

3.1. Объединение локальных логических моделей данных в глобаль­ную логическую модель. Анализ имен и связей сущностей, первичных клю­чей. Последовательное объединение сущностей и связей из отдельных локальных моделей. Устранение дублирования простых и транзитивных свя­зей между сущностями. Выявление про­пущенных сущностей и связей. Проверка корректности внешних ключей, ограничений целостности. Унификация имен и форматов пред­став­ления данных, связей и других элементов модели. Выполнение чертежа (ER‑диаграммы) гло­баль­ной логической модели и ее документирование.

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

3.3. Проверка возможностей модификации модели в будущем. Оценка приспособленности модели к возможным изменениям в будущем.

3.4. Создание ER‑диаграммы глобальной логической модели.

3.5. Согласование глобальной логической модели с пользователя­ми. Проверка соответствия модели предметной области приложения.

4. Создание глобальной логической мо­дели в среде целевой СУБД.

4.1. Создание таблиц. Создание таблиц, индексов, связей, огра­ни­че­ний, схем (ди­аг­рамм), правил, триггеров и других элементов базы данных.

4.2. Реализация бизнес‑правил. Правила защиты, контроля, обнов­ле­ния и обработки данных.

5. Проектирование физического представления данных. Опре­де­ле­ние способов хранения таблиц, строк индексов и других элементов базы данных на магнитных дисках.

5.1. Анализ транзакций. Определение характеристик транзакций (час­тота выполнения, время доступа к данным и др.).

5.2. Настройка фи­зической среды. Распределение файлов по раз­лич­ным дисководам и таблиц по файлам. Определение пер­вич­ных и макси­маль­но возможных размеров файлов и их приращений. Фор­ми­ро­ва­ние фак­то­ров заполнения страниц данных и индексов. Опре­де­ле­ние клас­тер­ных индексов.

5.3. Определение дополнительных индексов. Введение таких индек­сов может увеличить производительность системы.

5.4. Анализ введения избыточности данных. Анализ возможности хранения производных данных, дублирования и объединения таблиц на предмет повышения производительности системы.

Дата добавления: 2014-12-10