Проектирование баз данных

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

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

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

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

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

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

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

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

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

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

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

• принятие решения и создание хранимых процедур;
• принятие решения и создание функций;
• принятие решения и создание пакетов;
• принятие решения и создание триггеров.

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

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

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

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

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

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

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

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

Заключение.

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

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

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

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

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

Использована  литература:

1. Корнеев  В.В., Гараев А.Ф., Васютин С.И., Райх В.В

Базы  данных. Интеллектуальная обработка  информации

М.: Нолидж, 2000

2. Туманов  В.Е.

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

БИНОМ. Лаборатория знаний, Интернет-университет  информационных технологий - ИНТУИТ.ру, 2007