Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ

Глава 14 начнется с изложения базовых правил разработки моделей в реляционных базах данных. Глава закончится разделом о работе со скриптами БД.

ЧАСТЬ IV. База данных и ее объекты.

ГЛАВА 14. Чертежная доска для базы данных.

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

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

Пользователь SYSDBA и пароль

Во всех версиях Firebird, включая 1.5, пользователь SYSDBA имеет полные права ко всем базам данных на сервере. Инсталляционные скрипты устанавливают базу данных безопасности с паролем по умолчанию masterkey.

Некоторые релизы 1.5 для Linux запускают скрипт, который генерирует новый пароль для пользователя SYSDBA. Вы можете посмотреть сгенерированный пароль в файле SYSDBA.password в корневом каталоге Firebird.

! ! !

ВНИМАНИЕ! Пароль masterkey широко известен. Убедитесь, что вы изменили его на малопонятную восьмисимвольную строку. См. инструкции в главе 34.

. ! .

Метаданные

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

В этом разделе в деталях рассматриваются концепции, терминология и язык определения данных.

Язык определения данных

Основные структуры базы данных - ее таблицы, просмотры и индексы - создаются с использованием подмножества языка SQL Firebird, известного как язык определения данных (Data Definition Language, DDL). Оператор DDL начинается с одного из ключевых слов CREATE, ALTER, RECREATE или DROP, которые означают создание, изменение, пересоздание или удаление одного объекта, соответственно. База данных, ее объекты, правила и отношения объединяются для формирования структуры реляционной базы данных.

Системные таблицы

Firebird хранит метаданные в множестве таблиц, которые он создает прямо в базе данных, - в системных таблицах. Идентификаторы всех системных таблиц начинаются с символов "RDB$". Например, таблица, которая хранит определения и другую информацию о структурах всех таблиц в вашей базе данных, называется RDB$RELATIONS. Связанная с ней таблица RDB$RELATION_FIELDS хранит информацию и описания всех столбцов в каждой таблице.

Такая "база данных в базе данных" является высоко нормализованной. Операторы DDL разработаны для выполнения безопасных операций с таблицами метаданных и в полном соответствии с каскадными эффектами.

Возможно изменение данных в системных таблицах посредством обычных операций SQL. Некоторые инструменты администратора, такие как isql и gfix, выполняют внутренние изменения данных в системных таблицах. При этом, будучи сложной системой управления базами данных, Firebird не была разработана в предположении, что конечный пользователь будет манипулировать строками системных таблиц.

! ! !

ВНИМАНИЕ! Не рекомендуется пренебрегать операторами DDL и самостоятельно изменять системные таблицы с помощью кода приложений или через интерактивные инструменты. Системные таблицы являются "мета-метаданными" любой базы данных. Любое вмешательство человека, скорее всего, приведет к непредсказуемым повреждениям.

. ! .

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

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

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

Хорошее проектирование базы данных имеет несколько преимуществ.

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

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

* Предоставляет естественную, простую в понимании структуру информации. Хорошее проектирование делает запросы более понятными - мала вероятность того, что пользователи привнесут несогласованность в данные или что им потребуется вводить избыточные данные.

* Удовлетворяет требованиям пользователей к производительности. Хорошее проектирование базы данных обеспечивает лучшую производительность. Если таблицы будут слишком большими или будет слишком много (или слишком мало) индексов, результатом станет долгое ожидание. Если база данных является слишком большой с высоким объемом транзакций, проблемы производительности, как результат плохого проектирования, будут увеличиваться.

* Изолирует систему от ошибок проектирования в последующих циклах разработки.

Описание и анализ

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

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