Лекция № 2. Общий обзор процедуры проектирования БД
Интенсивность волны I пропорциональна квадрату звукового давления Р2.
Где А – амплитуда колебаний, которую можно заменить амплитудным значением звукового давления (Ро).
Суммарная интенсивность ЗВ в диффузном ЗП в любой точке равна нулю.
Основной параметр ЗП – объемная плотность энергии w, которая определяется как:
, Дж/м3
Интенсивность волны можно определить как:
Как и любой программный продукт, база данных обладает собственным жизненным циклом, который включает в себя следующие основные этапы:
- планирование разработки БД;
- определение требований к системе;
- сбор и анализ требований пользователей;
- проектирование БД:
Ø концептуальное;
Ø логическое;
Ø физическое;
- разработка приложений:
Ø проектирование транзакций (последовательность операций над БД, выполняемых с целью доступа или изменения содержимого БД);
Ø проектирование пользовательского интерфейса;
- реализация;
- загрузка данных;
- тестирование;
- эксплуатация и сопровождение:
Ø анализ функционирования и поддержка исходного варианта БД;
Ø адаптация, модернизация и поддержка переработанных вариантов.
Этапы проектирования базы данных
Основными целями проектирования БД являются:
- представление данных и связей между ними;
- создание модели данных, способной поддерживать выполнение любых требуемых транзакций обработки данных;
- разработка предварительного варианта проекта, структура которого позволяет удовлетворить требования, предъявляемые к производительности системы.
Концептуальное (инфологическое) проектирование базы данных – это процесс создания модели информации, не зависящей от любых физических аспектов ее представления.
Модель данных – интегрированный набор понятий для описания данных, связей между ними и ограничений, накладываемых на данные в некоторой организации. Отображает представление реального мира.
Первая фаза процесса проектирования начинается с анализа предметной области и выявления требований к ней отдельных пользователей (сотрудников организации, для которых создается база данных). Проектирование обычно поручается одному человеку или группе лиц – администратору данных (АД).
Объединяя частные представления о содержимом базы данных, полученные в результате опроса пользователей, и свои представления о данных, которые могут потребоваться в будущих приложениях, АД сначала создает обобщенное неформальное описание создаваемой базы данных. Это описание выполняется с использованием языка речи, математических формул, таблиц, графиков и других средств, понятных всем людям, работающих над проектированием базы данных.
Концептуальное проектирование абсолютно не зависит от типа выбранной СУБД, используемых языков программирования, типа выбранной вычислительной платформы, а также от любых других особенностей физической реализации.
В построении общей концептуальной модели данных выделяют ряд этапов:
- формулирование объектов, описывающих локальную предметную область проектируемой БД;
- описание атрибутов каждого объекта;
- выделение ключевых атрибутов (полей);
- спецификация связей между объектами, удаление избыточных связей.
При разработке концептуальная модель данных постоянно подвергается тестированию и проверке на соответствие требованиям пользователей.
Согласованная с пользователями модель данных используется разработчиками в качестве технического задания на разработку системы.
Созданная концептуальная модель данных предприятия является источником информации для фазы логического проектирования.
Конкретный вид и содержание концептуальной модели базы данных определяется выбранным для этого формальным аппаратом. Обычно используются графические нотации, подобные ER-диаграммам (entity-relationship model, ERM) – модель сущность-связь.
Чаще всего концептуальная модель базы данных включает в себя:
- описание информационных объектов, или понятий предметной области и связей между ними;
- описание ограничений целостности, т.е. требований к допустимым значениям данных и к связям между ними.
Логическое (даталогическое)проектирование базы данных – создание схемы базы данных на основе конкретной модели данных, например, реляционной модели данных.
Для реляционной модели данных даталогическая модель – набор схем отношений, обычно с указанием первичных ключей, а также «связей» между отношениями, представляющих собой внешние ключи. На этапе логического проектирования не учитывается физический тип целевой СУБД и другие физические аспекты реализации.
На второй фазе проектирования концептуальная модель данных уточняется и преобразуется в логическую модель данных. Учитываются особенности выбранной модели организации данных в СУБД (иерархическая, сетевая, реляционная или объектно-ориентированная модель).
В процессе разработки логическая модель данных постоянно тестируется и проверяется на соответствие требованиям пользователей. Для проверки корректности логической модели данных используется метод нормализации. Нормализация гарантирует, что выведенные из существующей модели данных отношения не будут обладать избыточностью данных, способной вызвать аномалии обновления после их физической реализации. Также логическая модель должна обеспечивать поддержку всех необходимых пользователям транзакций.
Построенная логическая модель данных является источником информации для этапа физического проектирования.
Физическое проектирование базы данных – создание схемы базы данных для конкретной СУБД. Это процесс реализации БД на запоминающих устройствах с указанием структур хранения и методов доступа, используемых для организации эффективной обработки данных.
Проектировщик принимает решение о способах реализации разрабатываемой БД. Приступая к физическому проектированию, прежде всего необходимо выбрать конкретную СУБД.
Между логическим и физическим проектированиями существует постоянная обратная связь, т.к. решения, принимаемые на этапе физического проектирования с целью повышения производительности системы, способны повлиять на структуру логической модели данных.
Целью этого этапа является описание способа физической реализации логического проекта БД. Для реляционной модели данных под этим подразумевается следующее:
- создание набора реляционных таблиц и ограничений для них на основе информации, представленной в логической модели данных;
- определение конкретных структур хранения данных и методов доступа к ним, обеспечивающих оптимальную производительность системы с базой данных;
- разработка средств защиты создаваемой системы.