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

. ! .

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

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

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

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

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

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

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

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

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

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

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

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

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