Информационные системы

Информационные системы

Электронный учебник

Лекция № 3: «Что такое проектирование базы данных»

     

Примеры функциональных требований: выдача отчетов по продажам по регионам; выдача отчетов по продажам по кварталам; автоматический расчет скидок на товары при увеличении объема закупаемой партии и т.п.

Примеры ограничений: максимальное время, отпущенное на проект; количество денежных средств, которое можно на него потратить. Следует также учитывать технологические средства, доступные при реализации проекта, например требование реализации базы данных в архитектуре "файл-сервер".

В эксплуатации база данных и ее окружение должны удовлетворять набору требований по ряду укрупненных (интегрированных) параметров, таких как:

· функциональность и адаптируемость;

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

· пропускная способность;

· время реакции;

· безопасность.

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

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

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

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

Введем определение проектирования баз данных.

Определение 1. Проектирование базы данных - это поиск способов удовлетворения функциональных требований средствами имеющейся компьютерной технологии с учетом заданных ограничений.

Как правило, ИТ-проекты по созданию базы данных включают в себя следующие этапы: определение стратегии построения системы, анализ требований к базе данных, проектирование базы данных, реализация базы, тестирование и внедрение базы данных. Этап проектирования базы данных считается одним из самых сложных "размытых" этапов создания базы данных, который не имеет явно выраженного начала и окончания. По сравнению с анализом требований к базе данных или разработкой приложений, проектирование базы данных, по мнению многих ведущих специалистов, является плохо структурированной задачей. Если все этапы создания базы данных перекрываются друг с другом в своей последовательности, то этап проектирования перекрывается со всеми остальными этапами. Проектирование начинается с момента принятия стратегических решений и продолжается на этапах реализации и тестирования.

Процесс проектирования базы данных охватывает несколько основных сфер.

· Проектирование объектов базы данных (таблицы, представления, индексы, триггеры, хранимые процедуры, функции, пакеты) для представления данных предметной области в базе данных.

· Проектирование интерфейса взаимодействия с базой данных (формы, отчеты и т.д.), т.е. проектирование приложений, которые будут сопровождать данные в базе данных и реализовывать вопросно-ответные отношения на этих данных.

· Проектирование баз данных под конкретную вычислительную среду или информационную технологию (архитектура "клиент-сервер", параллельные архитектуры, распределенная вычислительная среда).

· Проектирование баз данных под назначение системы (интеллектуальный анализ данных, OLAP, OLTP и т.д.).

Отметим, что приложения работы с базой данных проектируются одновременно с физической схемой базы данных, а не отдельно! Зачастую вычислительная среда задается в качестве входных условий проектирования, но иногда проектирование следует проводить с учетом возможного перехода в будущем на другую аппаратную платформу или технологию.

Внимание! Базы данных всегда проектируются под конкретное назначение системы.

Техника проектирования баз данных может измениться в целом и в деталях в зависимости от назначения системы. Например, следует различать проектирование систем складирования данных и проектирование так называемых OLTP-систем, ориентируемых на оперативную обработку транзакций. В данном учебном курсе рассматривается проектирование баз данных в основном для OLTP-систем. Именно на таких системах исторически сложилась техника проектирования баз данных.

Известно, что база данных:

· имеет свою внутреннюю архитектуру;

· имеет свое собственное лингвистическое содержание;

· действует в рамках некоторой внешней среды;

· имеет свои средства взаимодействия с внешней средой;

· функционирует на конкретной программно-аппаратной платформе;

· поддерживается в рамках определенных организационно-технологических мероприятий.

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

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

  Типовая бизнес-модель процесса проектирования базы данных

Процесс проектирования базы данных может быть представлен в виде модели бизнес-процессов. Обычно проектировщики не создают бизнес-модель процесса проектирования базы данных. А напрасно! Бизнес-модель процесса проектирования позволяет:

· отобразить субъективное мнение проектировщика баз данных на процесс проектирования конкретной базы данных;

· учесть особенности ИТ-проекта, в рамках которого проектируется база данных;

· достаточно быстро составить план проектирования конкретной базы данных;

· просчитать длительность проектных работ (создать временную модель проектирования).

Рассмотрим типовую бизнес-модель процесса проектирования базы данных. На рис. 3.1 приведена контекстная диаграмма процесса проектирования базы данных.

 


Рис. 3.1.  Контекстная диаграмма процесса проектирования базы данных

 

Как видно из рисунка, на вход процесса проектирования базы данных подаются:

· информационная модель предметной области базы данных: диаграммы "сущность-связь" (ER-диаграммы);

· функциональная модель предметной области базы данных: бизнес-модель процессов, диаграммы потока данных (DF-диаграммы), диаграммы состояний, - диаграммы жизненных циклов сущностей, спецификации на системы (требования), бизнес-правила;

· общесистемные требования и ограничения;

· задачи обратного влияния.

Могут быть представлены и другие документы.

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

На выходе процесса проектирования базы данных формируются следующие результаты:

· физическая модель базы данных, которая может быть преобразована в скрипт для создания базы данных;

· физическая база данных;

· спецификация модулей приложений базы данных;

· план тестирования базы данных.

По требованию может быть разработана и другая документация.

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

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


Рис. 3.2.  Диаграмма декомпозиция процесса проектирования базы данных: первый уровень

 

Такими задачами (этапами) являются:

· сбор и анализ входных данных;

· создание логической модели базы данных;

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

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

· создание серверного кода;

· проектирование модулей приложений базы данных;

· контроль качества проектирования базы данных;

· задачи обратного влияния.

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

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

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

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

Создание серверного кода - это этап, на котором на основании функциональной модели предметной области базы данных создается серверный код базы данных в виде триггеров, хранимых процедур и пакетов. Эти модули создаются проектировщиком базы данных и выполняются сервером.

Проектирование модулей приложений - это этап, на котором создаются спецификации модулей приложений, разрабатываются стратегии тестирования базы данных и приложений, создается план тестирования приложений базы данных и готовятся тестовые данные.

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

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

Как правило, последние четыре из сформулированных нами задач решаются в соответствии с правилами и стандартами, принятыми в конкретной организации.

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

 Бизнес-модель процесса проектирования базы данных: сбор и анализ входных данных.

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

 
Рис. 3.3.  Диаграмма декомпозициии процесса проектирования базы данных: второй уровень.

Сбор и анализ входных данных

Такими задачами являются:

· сбор документации с результатами анализа предметной области базы данных в виде диаграмм, спецификаций и требований;

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

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

· подготовка плана проектирования базы данных.

В ходе контроля качества основными моментами деятельности являются контроль ER-диаграмм и контроль диаграмм функциональной модели предметной области. На основании ER-диаграмм создается логическая модель реляционной базы данных; на основании диаграмм функциональной модели разрабатывается серверный код и проектируются модули приложений базы данных.

Систематизация требований заказчика к базе данных проводится с целью их адекватного распределения по этапам проектирования базы данных. Важным результатом систематизации является вывод о достаточности требований и реализуемости базы данных. Заказчик должен точно знать, что он получит и чего не получит в результате создания базы данных! Особенно важно указать, чего он не получит. Анализ требований на реализуемость базы данных в рамках конкретного ИТ-проекта служит основой для принятия решения менеджером проекта о возможности реализации проекта в целом.

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

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

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

 

Бизнес-модель процесса проектирования реляционной базы данных: создание логической модели базы данных

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

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

·              нормализация сущностей предметной области:

o             получить список атрибутов сущности;

o             определить функциональные зависимости (ФЗ) в сущности;

o             определить детерминанты сущности;

o             определить возможные ключи отношения, в частности, рассмотрев уникальный идентификатор сущности.

o             выполнить нормализацию сущности (преобразовать сущность в отношение);

o             для полученного отношения назначить первичные ключи;

o             сформировать список кандидатов на внешние ключи, если необходимо;

o             сформировать бизнес-правила поддержки целостности сущности, если необходимо;

·              нормализация отношений логической модели базы данных:

·              определить степень связи сущностей;

·              определить класс принадлежности сущности к связи;

o             нормализовать отношение (разрешить связи);

o             назначить первичные ключи связывающих отношений, исходя из уникального идентификатора связи и процедуры миграции ключей при нормализации;

o             определить атрибуты связывающих отношений, если необходимо;

o             сформировать бизнес-правила поддержки целостности связей;

·              проверка правильности логической модели реляционной базы данных:

o             проверка отношений на соответствие нормальной форме Бойса-Кодда;

o             проверка отношений на свойства соединения без потерь и сохранения функциональных зависимостей;

o             предотвращение потери данных путем миграции первичных ключей отношения и назначения внешних ключей;

o             проверка на отсутствие незамкнутых связей;

o             проверка на отсутствие одиночных отношений;

·              формулировка части исходных данных для решения задачи управления ссылочной целостностью;

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

·              принятие решения о реализуемости построенной логической модели реляционной базы данных;

·              принятие решения о разработке физической модели реляционной базы данных.

Результатом проектирования логической модели базы данных является нормализованная схема отношений базы данных. Отметим, что в ходе выполнения этапа создания логической модели базы данных могут быть созданы новые объекты базы данных, не предусмотренные в информационной модели предметной области, например связывающая сущность при нормализации отношения со степенью связи "многие-ко-многим". Иногда на этом этапе принимается решение о выборочной денормализации отношений.

Бизнес-модель этапа проектирования - создание физической модели реляционной базы данных

В данном разделе рассмотрим организационную сторону решения профессиональной задачи проектировщика баз данных - задачу создания физической модели реляционной базы данных. Основная цель решения этой задачи: преобразовать логическую модель реляционной базы данных в последовательность команд SQL для создания объектов реляционной базы данных. Таким образом, проектировщик базы данных отображает отношения логической модели реляционной базы данных (сущности предметной области, представленные в нормализованной форме на ER-диаграммах) в таблицы и индексы реляционной базы данных.

Эта задача включает выполнение ряда обязательных последовательных процедур.

·        Создание базовых таблиц. Они представляют основные блоки хранения данных и выводятся из сущностей логической модели данных. При создании каждой таблицы проектировщик должен рассмотреть и учесть ряд факторов:

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

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

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

o       определить ряд параметров, связанных с характером хранения таблицы в физической базе данных;

o       определить ограничения на значения колонок, исходя из ряда бизнес-правил.

·        Создание связывающих таблиц, необходимых для разрешения отношения "многие-ко-многим", если они имеют место в логической модели базы данных. В рамках ER-диаграмм это отношение может быть уже разрешено. Тогда речь пойдет только о его реализации в командах SQL.

·        Принять решение о способе поддержки ссылочной целостности в базе данных. Если будет решено поддерживать ссылочную целостность на уровне команд SQL, то специфицировать ограничения ссылочной целостности. Эта задача решается в четыре этапа:

o       идентифицировать первичные ключи каждой таблицы;

o       построить индексы первичного ключа;

o       определить внешние ключи в дочерних таблицах, если необходимо;

o       построить команды SQL, которые идентифицируют внешние ключи в дочерних таблицах и правила поддержки ссылочной целостности;

o       Если необходимо, построить представления внешней схемы базы данных.

 

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

Перейдем теперь к построению бизнес-модели этапа проектирования физической модели реляционной базы данных - созданию первой итерации внутренней схемы базы данных. Из сказанного в предыдущих разделах настоящей лекции понятен следующий алгоритм действий:

Создание объектов для хранения данных

   Создание таблиц

      Идентифицировать таблицу

      Определение типов данных колонок

      Определение первичного ключа

      Добавление ограничений

   Создание таблиц для взаимосвязи "многие-ко-многим"

   Создание индексов

   Создание представлений

   Создание других объектов базы данных

   Проверка корректности созданной физической модели

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

  Бизнес-модель этапа проектирования - создание физической модели реляционной базы данных: учет влияния транзакций

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

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

На этом этапе проектирования физической модели реляционной базы данных проектировщик базы данных:

· исходя из требований к характеру обработки данных, определяет тип приложения базы данных;

· по имеющимся требованиям и описаниям выполняет систематизацию и описание по возможности всех транзакций к базе данных;

· отталкиваясь от исходной документации, определяет возможные размеры таблиц, а если это невозможно, делает предположения об их возможном размере;

· исходя из фактических размеров таблиц и требований к производительности выполнения транзакций, определяет критические транзакции;

· для каждой критической транзакции необходимо оценить кардинальность каждой колонки, задействованной в транзакции и, по возможности, кардинальность выборки;

· далее, рассматривая в первую очередь критические транзакции и таблицы, которые в них участвуют, проектировщик базы данных принимает субъективные решения по изменению структуры таблиц внутренней схемы базы данных, исходя из тех механизмов, которые ему предоставляет конкретная СУБД;

· по завершении изменения структур таблиц проектировщик базы данных документирует эти изменения, приводя обоснование своих решений для администратора базы данных.

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

Перейдем теперь к построению бизнес-модели этапа проектирования физической модели реляционной базы данных: учет влияния транзакций. Из сказанного в предыдущих разделах настоящей лекции понятен следующий алгоритм действий:

Определение основного типа приложения базы данных

   Документирование и описание транзакций

   Определение критических транзакций

   Для каждой критической транзакции:

      Определение таблиц транзакции

      Определение способа повышения производительности

         Денормализация таблицы?

         Разбиение таблицы?

         Секционирование таблицы?

         Кластеризация таблицы?

         Построение дополнительных индексов?

         Изменение структуры внутренней схемы базы данных

         Документирование изменений

   Для каждой таблицы базы данных

      Выбор индексов

         Определение транзакций таблицы

         Определение кардинальности таблиц

         Определение кардинальности колонок

         Определение индексов

         Изменение внутренней схемы

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

На этом мы заканчиваем рассмотрение задач проектировщика базы данных по созданию физической модели реляционной базы данных с учетом влияния транзакций. Главная цель этого этапа - видоизменить последовательность команд SQL для создания объектов хранения данных с учетом влияния транзакций на производительность базы данных.

 

Краткое рассмотрение задач создания серверного кода и подготовки скрипта

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

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

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

Приложения формируют запросы в форме команд SQL к базам данных, отправляют их серверам баз данных, получают запрашиваемые данные и обрабатывают их.

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

Работа приложения по второй схеме основывается на использовании так называемого серверного кода (server-side code) - любого кода, выполняемого компьютером, на котором установлена СУБД. Ядро СУБД выполняет этот код в базе данных и возвращает приложению только результат. Например, это может быть несколько колонок строки или вычисленное значение.

Использование серверного кода может значительно сократить объем сетевого трафика и тем самым увеличить производительность базы данных в целом. Однако СУБД должна иметь встроенные средства для распознавания и обработки такого кода. Многие фирмы - производители промышленных СУБД, в том числе и Oracle, предлагают процедурные расширения SQL, с помощью которых можно выполнять построчную обработку данных, использовать циклы, сложные вычисления и операции управления данными.

PL/SQL является таким расширением SQL в СУБД Oracle 9i. Он позволяет создавать серверный код в виде объектов реляционной базы данных, таких, как хранимые процедуры, функции, пакеты и триггеры. Проектировщик реляционной базы данных, который использует для создания базы данных СУБД Oracle, имеет возможность рассмотреть создания таких объектов с целью сокращения сетевого трафика или принять решение о переносе определенного объема обработки на сервер, особенно в тех случаях, когда эта обработка выполняется очень интенсивно. Например, несколько строк разных таблиц проверяются перед вставкой новой строки.

Таким образом, разработка серверного кода сводится к решению следующих подзадач:

· принятие решения и создание хранимых процедур;

· принятие решения и создание функций;

· принятие решения и создание пакетов;

· принятие решения и создание триггеров.

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

Проектировщик базы данных, выполнив предыдущие задачи, фактически выполнил свою основную работу над созданием скрипта для базы данных. Если работа по проектированию базы данных закончена, зачем проектировщику еще что-то делать, кроме того как проанализировать и проверить проделанную работу, отредактировать окончательный вариант скрипта и создать физическую базу данных? Принято считать, что задача создания базы данных, так же как и управление базой данных, является задачей администратора базы данных. Значит, можно задокументировать проделанную работу и передать ее администратору базы данных.

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

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

·  требования к размещению и хранению объектов базы данных на физических носителях в рамках операционной системы, т.е. привязка объектов базы данных к файлам операционной системы.

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

Таким образом, задача создания скрипта базы данных состоит из решения крупных подзадач:

·  создание пользователей, их идентификация и назначение им привилегий;

·  привязка разработанных объектов реляционной базы данных к параметрам физического хранения базы данных с помощью создания специальных объектов базы данных;

·  создание инсталляционного скрипта;

·  документирование базы данных.

В этой лекции мы рассмотрели, в чем состоит сложный процесс проектирования базы данных, принципы построения бизнес-модели проектирования базы данных и основные фрагменты типовой бизнес-модели. Автор надеется, что предложенная бизнес-модель будет использована, достроена и доработана слушателями в процессе их самостоятельной работы.

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