Хелен Борри - Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ

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

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

! ! !

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

. ! .

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

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

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

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

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

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

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

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

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

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

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

Эта фаза может быть одной из наиболее сложных задач для проектировщика базы данных, особенно в окружении, где> бизнес был приспособлен к работе с электронными таблицами и настольными базами данных. Прискорбно, что даже в среде клиент-сервер можно найти слишком много медленно работающих, подверженных разрушению баз данных, которые были "спроектированы" с использованием отчетов и электронных таблиц в качестве своей основы [32] Существует море литературы, содержащей описания техник эффективного анализа задач бизнеса для проектировщика реляционных баз данных, размышления об уровне нашей профессиональности. Автор особенно рекомендует Data Modeling Essentials: Analysis, Design and Innovation, 2nd Edition by Graeme C. Simsion (Coriolis, 2000). .

Тот "мир", который был получен в процессе описания и анализа, является черновиком для структур ваших данных. Считается, что логическая модель должна описывать отношения и наборы. Обычная ошибка (и западня, присущая всем инструментам CASE) слепо транслировать модель данных в схему базы данных. В сложных системах управления базами данных, таких как Firebird, структура таблицы не всегда представляет оптимальный объект, из которого должны отыскиваться данные. Запросы, просмотры, массивы, вычисляемые столбцы и хранимые процедуры выбора являются лишь небольшой частью доступных механизмов поиска и хранения, которые будут влиять на вашу реализацию модели при физическом проектировании.

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

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