Основные требования при проектировании БД Проектирование базы данных

Основные требования при проектировании БД Проектирование базы данных процесс разработки структуры (схемы) базы данных (БД) в соответствии с требованиями пользователей Общие требования к БД в процессе проектирования 1. Удовлетворение информационных потребностей различных категорий пользователей за ограниченный промежуток времени, в определенном месте и в определенном виде. 2. Обеспечение достоверности данных в базе, исключение дублирования информации. 3. Обеспечение надежности функционирования системы баз данных, а также восстановление данных за приемлемое время в случае ее отказа. 4. Установка защиты базы данных от несанкционированного доступа. 5. Возможность проведения гибкой и нетрудоемкой модификации при изменении требований предметной области, программных и технических средств. 1

Жизненный цикл системы баз данных Фаза анализа и проектирования 1. Формулирование и анализ требований 2. Концептуальное проектирование 3. Проектирование реализации 4. Физическое проектирование Фаза реализации и функционирования базы данных 1. Реализация базы данных 2. Анализ функционирования и поддержка 3. Модификация 2

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

Этап 1. Формулирование и анализ требований Общие требования при проектировании базы данных: • многократное использование данных; • простота, легкость использования; • гибкость при модификации структуры; • обработка незапланированных запросов; • простота корректировки данных; • небольшие затраты на эксплуатацию; • минимальная избыточность; • производительность; • секретность; • достоверность; • защита от искажений и сбоев; • физическая и логическая независимость; • требуемая скорость доступа и поиска; • стандартизация данных; • наличие словаря базы; • контроль за целостностью данных в базе; • восстановление и реорганизация данных в базе. 4

Этап 1. Формулирование и анализ требований Методы выполнения: • изучение существующих форм документов, отчетов, файлов, баз данных, программного обеспечения; • интервьюирование персонала различных уровней, специалистов организации. Содержание исходной информации: • имя и описание объекта данных; • элементы данных; • продолжительность хранения и условия перевода в архив. 5

Пример содержания исходной информации 6

Пример функционального моделирования (SADT-модель, начальный уровень модели) 7

Пример функционального моделирования (SADT-модели, первый уровень декомпозиции модели) 8

1. 5. Обеспечение свойств базы данных в процессе проектирования Фундаментальные свойства базы данных 1) целостность, согласованность, восстанавливаемость; 2) безопасность; 3) эффективность, рост, размер, эксплуатационные ограничения. 9

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

Фундаментальные свойства базы данных Безопасность Защита данных от преднамеренного или непреднамеренного доступа, модификации или разрушения. Эффективность Степень соизмерения результатов функционирования базы данных с затратами на обеспечение целостности базы данных. Показатель – скорость обработки единицы информации 11

ПРИМЕР 1 12

Пример: Система обеспечения продажи товаров (требования) Номер заказа (1234, 5678, 9112, …. ) Наименование товара (AMD Athlon 64 X 2 6000+ BOX < Socket. AM 2 >, DDRII 2048 Mb (pc 2 -5300) 667 MHz ECC Fully Buffered Qimonda, D-Link DWA-140 Беспроводной адаптер USB, 802, 11 n, … ) Цена товара в заказе (…) Количество товара в заказе (…) Единицы измерения товара в заказе (шт. , м, …) Наименование типа товара (процессоры, модули памяти, сетевое оборудование, … 13

Пример содержания исходной информации 14

Пример: Фрагмент системы обеспечения продажи товаров (исходный вариант) Объект ЗАКАЗЫ 15

Первая нормальная форма (1 НФ) Определение Отношение находится в 1 НФ (First Normal Form, 1 NF) тогда и только тогда, когда на пересечении каждого столбца и каждой строки находятся только элементарные значения атрибутов. Другими словами, в отношении не должно быть ячейки, в которой находится несколько значений. В терминах теории баз данных каждое значение в столбце таблицы является элементарным (атомарным), т. е. состоящим из одного экземпляра. Пример Фрагмент организации данных, удовлетворяющий условиям 1 НФ 16

Аномалии первой нормальной формы Аномалия включения Пока не будет заказа на товар информация о товаре будет отсутствовать в базе данных (наименование товара, код типа товара, наименование типа товара); Аномалия обновления При изменении наименования товара необходим полный просмотр отношения с целью найти все заказы, чтобы изменение наименования товара было отражено во всех заказах. Аномалия удаления Если какой-либо товар удалить из базы данных (снят с продажи), то при этом будет потеряна не только информация о тех заказах, в которых присутствовал этот товар, но и товаре в целом (код товара, его наименование и тип) Аномалия дублирования Некоторые значения атрибутов приходится многократно повторять (наименование товара и наименование типа товара). 17

Вторая нормальная форма (2 НФ) Определение Отношение находится во 2 НФ (Second Normal Form, 2 NF) тогда и только тогда, когда оно находится в первой нормальной форме и не содержит неполных функциональных зависимостей непервичных атрибутов от атрибутов первичного ключа. Другими словами, дополнительное ограничение состоит в том, что все неключевые атрибуты целиком зависят от всего ключа, а не от отдельной его части (т. е. отсутствует частичная зависимость). Пример Фрагмент организации данных, удовлетворяющий условиям 2 НФ 18

Третья нормальная форма (3 НФ) Определение Отношение находится в 3 НФ (3 НФ, Third Normal Form, 3 NF) тогда и только тогда, когда оно находится во второй нормальной форме и не содержит транзитивных зависимостей. Другими словами, дополнительное ограничение заключается в том, что все неключевые атрибуты должны быть взаимно функционально независимы, т. е. ни одно из неключевых полей таблицы не должно зависеть функционально от любого другого неключевого поля. Пример Фрагмент организации данных, удовлетворяющий условиям 3 НФ 19

ПРИМЕР 1 Cкладской учет 20

1 НФ

Проблемы нормализации • Разобрав вышеприведенный пример мы получили нормализованный складской учет. Но у нормализации есть и свои недостатки: 1. Прежде всего, это большее количество сущностей БД. Чем это может грозить?

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

Проблемы нормализации • 2. Еще одним недостатком, можно определить трудности построения запросов к таким БД, так как необходимо связывать несколько таблиц. А границы понимания не безграничны особенно у человека! Стоит ли идти по пути нормализации или свалить все в одну максимум две таблицы, что за частую все и делают, зато не нужно долго думать. На практике обычно используют 2 НФ - это не так сложно, хотя чаще всего присутствует избыточность

Главной задачей администратора БД, является достичь наибольшего уровня нормализации БД при наименьшем количестве объектов в ней