Читать интересную книгу Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ - Хелен Борри

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

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

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

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

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

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

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

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

Модель данных <> база данных

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

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

Одна база данных или много?

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

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

Физические объекты

Таблицы

Таблица базы данных обычно визуализируется в виде двумерного блока, состоящего из столбцов (вертикальная размерность) и строк (горизонтальная размерность). Хранимые атрибуты индивидуальных элементов данных задаются в столбцах (обычно связанных с или зависящих от другого столбца) и строках. Таблица может иметь любое количество строк (до 232) или совсем ни одной строки. Хотя каждая строка в одной таблице совместно использует спецификации ее столбцов с любой другой строкой, строки не зависят от других строк в той же таблице.

! ! !

СОВЕТ. Firebird поддерживает техники реализации ссылающихся на себя таблиц - структура строк, которая задает зависимости между строками в той же таблице. Подробности см. в разд. "Ссылающиеся на себя отношения" главы 17.

. ! .

Файлы и страницы

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

В рамках файла сервер Firebird управляет блоками диска одного размера, называемыми страницами базы данных. Он управляет некоторыми различными "типами" страниц в соответствии с хранимыми типами данных - например, обычные столбцы таблицы, BLOB, индексы. Когда требуется, сервер размещает новый блок в файловой системе хоста. Все страницы независимо от типа имеют одинаковый размер. Размер страницы должен быть указан в операторе CREATE DATABASE. Он может быть изменен только при выполнении резервного копирования и восстановления базы данных с новым размером страницы при использовании утилиты gbak.

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

Столбцы и поля

Обобщенно, столбец является совокупностью атрибутов, определяющих элемент данных, который может быть сохранен в одной указанной ячейке в структуре строки таблицы слева направо. При этом столбцы фактически не существуют в таблицах базы данных. Каждый раз, когда запрос обращается к серверу, этот запрос задает набор столбцов и одну или более операций, выполняемых над этими столбцами. Столбцы не обязательно должны располагаться в том же порядке слева направо, как они были определены в таблице. Например, оператор SELECT FIELD3, FIELD1, FIELD2 FROM ATABLE;

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

Некоторые люди используют термин "поле" вместо столбца, например: "У меня есть таблица TABLEI, содержащая три поля". Часто книги по реляционным базам данных не одобряют использование "поле" как замена для "столбец", предпочитая использовать "поле" в смысле "значение в столбце" или "ссылка на столбец".

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

КлючиПервичный ключ

Основной частью процесса проектирования базы данных является выделение в логической модели базы данных для каждой таблицы одного уникального столбца или структуры из нескольких столбцов, которая отличает каждую строку от любой другой строки в таблице. Такой уникальный столбец или комбинация столбцов является логическим первичным ключом (primary key). Когда вы создаете вашу физическую модель, вы используете ограничение PRIMARY KEY, чтобы сообщить СУБД, какой столбец или столбцы формируют такую уникальную идентификационную структуру. На таблицу вы можете определить только одно ограничение PRIMARY KEY. Синтаксис рассматривается в разд. "Ограничения" главы 16.