Проектирование внутреннего уровня БД
Проектирование внутреннего уровня БД заключается в преобразовании логической модели данных в такую форму, которая позволит реализовать данный проект в среде выбранной СУБД. Исходными данными для проведения этого этапа является полученная на ранних этапах проектирования логическая структура БД (ДЛМ БД). В результате должна быть получена физическая модель БД, представленная на языке определения данных выбранной СУБД. Чаще всего это SQL команды, описывающие объекты БД (SQL скрипты).
Разработчик физической модели БД (эту функцию выполняет администратор БД) должен хорошо знать функциональные возможности выбранной СУБД, понимать все её достоинства и недостатки. На данном этапе проектирования БД должны быть определены и реализованы способы размещения данных в среде хранения и способы доступа к этим данным на физическом уровне. Хотя для организации физической модели могут быть использованы и файловые системы, в большинстве случаев для реализации баз данных используется физическая организация файлов, которыми непосредственно управляет СУБД. Как правило, СУБД для платформы IBM PC не предоставляют проектировщику никаких возможностей выбора или изменения способа организации файлов БД. Настройка среды хранения и настройка оптимальной работы СУБД, а, следовательно, и БД, является сложной задачей и требует определенных профессиональных знаний и навыков. Мы рассмотрим часть видов работ на этапе физического проектирования БД: выбор СУБД и проектирование ряда объектов БД.
Выбор реляционной СУБД
СУБД значительно различаются по своим характеристикам и функциям. Первые программные продукты такого рода были разработаны для больших ЭВМ в конце 1960—х годов и выполняли достаточно простые операции. С тех пор СУБД постоянно совершенствовались, а функции их расширялись. Усовершенствования касались не только обработки данных, СУБД также снабжались функциями, упрощающими создание приложений БД.
При появлении персональных компьютеров начался бурный рост популярности настольных реляционных СУБД (dBase, FoxPro, Paradox), а затем их сетевых многопользовательских версий, позволяющих обрабатывать данные, находящиеся в общедоступном месте в сети. В многопользовательских настольных СУБД появились механизмы блокировок частей данных, что позволило реализовать обращение к одним и тем же данным нескольких пользователей одновременно. Их недостатки (низкая производительность и степень защиты данных, ограниченное число пользователей) отсутствуют в СУБД, появившихся на следующих этапах развития данного программного продукта. Это, так называемые, серверные СУБД.
Серверные СУБД предназначены для архитектуры вычислительной среды «клиент—сервер», основанной на централизации хранения и обработки данных на одном выделенном более мощном компьютере, называемом сервером базы данных. Сервер БД отвечает за работу с файлами БД, поддержку ссылочной целостности, резервное копирование и восстановление БД, параллельную работу с данными большого числа пользователей, обеспечение авторизованного доступа к данным, ведение данных и их обработку. Основным преимуществом серверных СУБД является обеспечение высокой безопасности и надежности данных.
В настоящее на рынке программных продуктов насчитывается несколько сотен реляционных СУБД.
Основным принципом при выборе СУБД является определение такого программного продукта, который в наибольшей степени соответствует требованиям, определенным характером решаемой задачи автоматизации.
Решить эту задачу непросто:
— во—первых, требования к СУБД, по мере освоения пользователями её функциональных особенностей, меняются – требуются новые возможности. Так, например, сначала была реализована локальная версия БД, затем потребовалась сетевая. Либо потребовалось увеличение скорости обработки данных, наиболее полная поддержка ограничения целостности данных, определяемых предметной областью и т.п.;
— во—вторых, СУБД имеют большое число параметров, их трудно сравнивать;
— в—третьих, зачастую используют либо не лицензионные, либо свободно распространяемые программные продукты и поэтому разработчики не имеют доступа к качественной технической документации.
Каждый программный продукт, и СУБД в частности, может сопровождать информация следующего вида:
— сведения разработчиков и рекламная информация продавцов;
— информация, предоставляемая на различных форумах конечными пользователями, разработчиками программного обеспечения для БД, администраторами, имеющих опыт работы с БД;
— информация профессиональных аналитиков и экспертов.
Выбор СУБД удобно проводить в 3 этапа.
1 Этап качественного оценивания предлагаемых показателей пригодности программного продукта, уменьшающий, таким образом, область выбора.
2 Этап оценки технических характеристик выбранных систем более детально.
3 Этап оценки производительности оставшихся продуктов по различным критериям для принятия окончательного решения.
К показателям пригодности относятся следующие характеристики СУБД:
— полнота функциональности СУБД (развитый интерфейс пользователя, позволяющий осуществлять различные операции с БД: создание БД; создание и модификация объектов БД; ввод, обновление информации; реализация запросов и вывод результатов на печать);
— возможность реализации сервера БД;
— наличие встроенных средств разработки программ для работы с БД (клиентских приложений);
— поддержка объектов БД, позволяющих хранить логику предметной области и логику обработки данных;
— требования к квалификации пользователей;
— удобство и простота использования;
— сложность процедуры установки;
— сложность интерфейса пользователя;
— простота выполнения обычных операций с БД;
— наличие подсказок помощи;
— модель представления данных;
— возможность обеспечения целостности данных на уровне СУБД;
— автоматическая генерация кода пользовательского приложения, разрабатываемого в среде СУБД визуально;
— наличие средств автоматизации проектирования БД;
— качество средств защиты и контроля данных (поддержка внутренних ограничений модели данных и ограничений предметной области; средства для реализации функций резервного копирования и восстановления БД);
— поддержка сетевых протоколов, обеспечивающих работу СУБД в различных сетях;
— наличие средств разграничения прав пользователя;
— поддержка стандартных интерфейсов: ODBC, SQL и др.;
— фирма – разработчик;
— наличие документации или книг на рынке;
— высокая уверенность в появлении новой версии;
— стоимость.
К техническим характеристикам СУБД относятся:
— операционная система, под управлением которой работает СУБД;
— потребность в оперативной памяти
— ограничение на максимальный объем БД;
— перечень объектов БД, поддерживаемых СУБД;
— ограничение на количество одновременных подключений пользователей;
— ограничения на операции над данными;
— максимальные размеры поля таблицы, числа полей в таблице, размер строки, количества строк в таблице; число таблиц, которые можно обрабатывать одновременно;
— средства поддержки ограничений целостности БД;
— возможности средств формулировки и выполнения запросов (навигационная обработка, работа с языками запросов QBE, SQL);
— возможность сохранения запросов в БД;
— поддержка многопользовательской работы с БД (виды блокировок, средства обработки транзакций);
— наличие различных генераторов (интерфейса, отчетов, выполняемых модулей);
— наличие средств импорта и экспорт данных, в частности в web—формат.
Задача определения производительности СУБД является достаточно сложной. Решить её могут только высокопрофессиональные специалисты, владеющие методиками измерения производительности программных продуктов. Одна из методик – это использование тестов TPC, разработанных Transaction processing Performance Council — Советом по производительности систем обработки транзакций; тесты, не относящиеся к семейству TCP — Wisconsin Benchmark и AS3AP.
Производительность СУБД оценивается следующими характеристиками:
— временем выполнения запросов;
— скоростью поиска информации в неиндексированных полях;
— временем выполнения операций импортирования базы данных из других форматов;
— скоростью создания индексов и выполнения таких массовых операций, как обновление, вставка, удаление данных;
— максимальным числом параллельных обращений к данным в многопользовательском режиме;
— временем генерации отчета.
На производительность СУБД также оказывает большое влияние качество проекта БД.
Сведения о некоторых наиболее популярных СУБД приведены в таблице 25.
Таблица 25 – Современные СУБД
| Продукт | Фирма производитель | URL |
| Настольные, для создания локальных БД | ||
| Visual dBase | dBase, Inc. | http://www.dbase2000.com |
| Paradox | Corel | http://www.corel.com |
| Microsoft Access | Microsoft | http://www.microsoft.com |
| Microsoft FoxPro | ||
| Microsoft Visual FoxPro | ||
| Серверные СУБД | ||
| Oracle | Oracle Corp | http://www.oracle.com |
| Microsoft SQL Server | Microsoft | http://www.microsoft.com |
| Informix | Informix | http://www.informix.com |
| Sybase | Sybase | http://www.sybase.com |
| IBM DB2 | IBM | http://www—4.ibm.com |
Объекты БД
Рассмотрим некоторые объекты БД, поддерживаемые современными системами управления базами данных (таблица 26).
Таблица 26 – Объекты БД
| Объект | Описание | Комментарий |
| SCHEMA Схема | Именованный набор (множество) объектов БД, управляемых одним пользователем. | БД может включать набор разных схем. |
| DOMAIN Домен | Объект, который может использоваться как альтернатива типу данных для столбца (ов) таблицы, таблиц. Домен определяет тип данных и может также задавать некоторые другие ограничения атрибута, значения по умолчанию. | Создатели реляционной базы данных настоятельно рекомендовали использовать домены. |
| TABLE Таблица | Фундаментальная информационная структура реляционных БД. | Поддерживается всеми реляционными СУБД |
| INDEX Индекс | Хранит последовательность упорядочивания данных в столбце (столбцах) таблицы по возрастанию или убыванию. | Создаются только те индексы, которые реально необходимы |
| SEQUENCES Последователь—ность | Объект схемы данных, генератор порядковых номеров, используемых для автоматической генерации значений уникальных и первичных ключей. | Использование последовательности увеличивает конкурентоспособность приложений БД |
| PROCEDURE Процедура | Хранимый в БД программный модуль, написанный на процедурном языке СУБД и используемым разными пользователями БД | Используются для реализации бизнес—правил предметной области |
| TRIGGER Триггер | Хранимая процедура, которая автоматически выполняется СУБД при внесении изменений в указанную таблицу (вставка, обновление, удаление данных). | Всегда связан с конкретной таблицей |
| VIEW Представление, просмотр | Виртуальная таблица, которая создается только по вызову и обрабатывается как таблица, затем удаляется. | Хранятся в виде SQL—запросов, используются для удобного представления данных или для реализации разграничения прав доступа пользователей. |
| ROLE Роль | Именованный набор прав на множество объектов базы данных. | Применяются для эффективного управления привилегиями пользователей БД. |
| CURSOR Курсор | Указатель, используемый для перемещения по наборам записей при их обработке. | Поддерживает текущую позицию данных в БД |
| USERS Пользователи | Пользователь БД | Применяется для разграничения прав доступа к объектам БД |
Различные СУБД поддерживают различный набор объектов, хранимых в БД.
Современные серверные СУБД поддерживают все перечисленные в таблице 26 объекты базы данных. Наиболее своеобразной, в плане поддерживаемых объектов БД, является СУБД Access. Несмотря на это, средствами СУБД Access можно реализовать все предъявляемые к реляционной БД требования.
Физическая модель БД
Описание физической модели базы данных включает в себя описание объектов БД. Есть несколько способов, с помощью которых структура объектов БД описывается для СУБД. Чаще всего для этого создается текстовый файл, который описывает эти структуры. Язык, используемый для определения структур объектов БД, называется языком определения данных (ЯОД). Альтернативой текстовому описанию является визуальный (графический) способ задания структур объектов БД, используемый, например, в СУБД Access.
Схема БД состоит из набора определений, выраженных на ЯОД. В результате компиляции команд, созданных на ЯОД, создается системный каталог (словарь данных), в котором хранятся метаданные, т.е. данные, описывающие объекты БД. Метаданные упрощают способы доступа и управления объектами БД.