Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ
Шрифт:
* Распространенная избыточность структур, которая перешла от электронных таблиц к базам данных с одними и теми же элементами данных, повторяющихся во многих таблицах.
* Иерархические структуры первичных ключей (нужны во многих настольных системах баз данных для реализации зависимостей), что нарушает уточненную модель ограничений внешнего ключа в зрелых реляционных базах данных.
* Большие составные символьные ключи, составленные из столбцов реальных данных.
* Недостатки нормализации, приводящие к большому количеству записей содержащих много повторяющихся групп и редко требуемой информации.
* Большое количество частично совпадающих друг с другом индексов, не являющихся необходимыми.
Это не говорит
Общей характеристикой приложений настольных баз данных является то, что они предоставляют интерфейс в виде таблицы: данные представляются в виде строк и столбцов с полосами прокрутки и другими элементами навигации для просмотра с первой строки до последней. Часто эти таблицы представляют собой визуальную структуру, которая в точности воспроизводит структуру метаданных исходных таблиц. Обычная ловушка- импортировать такие таблицы в систему клиент-сервер и считать, что задача миграции выполнена.
Перенос таких старых баз данных в систему клиент-сервер обычно требует большего, чем создание программы конвертирования данных. Выполните ваше конвертирование и будьте готовы рассматривать объекты вашей базы данных как основу для дальнейшей работы. Запланируйте выполнить заново анализ и новое проектирование полученного абстрактного стиля базы данных в структуры, которые будут хорошо работать в новом окружении. В Firebird очень просто создать новые таблицы и записать в них данные. Для хранения используйте простые ключи; преобразовывайте структуры больших таблиц в группу связанных нормализованных отношений; переносите группы повторяющихся столбцов в отдельные таблицы; изменяйте структуры ключей, которые уменьшают уровень зависимостей; устраняйте дублирование данных и т.д.
Если вы находитесь в недоумении по поводу нормализации и выделения главных признаков, посмотрите специальные книги или сайты. Начните работу с небольших моделей данных (подмножество из пяти или шести основных таблиц является идеальным) вместо того, чтобы использовать базу данных из 200 таблиц, как если бы это было единой задачей, которую вы должны решить за один день. Таким образом, конвертирование становится упреждающей практикой самообучения, а быстрое решение трудных задач становится более интуитивным. Например, изучите хранимые процедуры и триггеры и проверьте, что вам известно о написании модулей конвертирования данных.
Основной частью начального проектирования реляционной базы данных является представление всех любимых отчетов, электронных таблиц и наиболее используемых отображений в виде таблиц базы данных. Все это является выходными данными, которые выбираются с помощью запросов и хранимых процедур.
Клиентские приложения в системе, где информационные сервисы предприятия имеют серверную программу, которая является полнокровной СУБД с мощными возможностями обработки данных, не изменяют вводимые пользователем данные после выполнения синтаксического разбора их исходного вида и упаковывания кода в подготовленные контейнеры - в структуры транспортных функций API. Циклам FOR
Разработчик приложения должен постоянно думать о стоимости лишней работы. Передача огромного объема данных по сети для просмотра перегружает сеть и разочаровывает пользователя. Необходимо сосредоточиться на эффективных способах показа информации пользователям и на получении данных от них- инструкции и новые данные, которые люди хотят добавлять. Разработка пользовательского интерфейса должна фокусироваться на быстрых и интуитивно понятных техниках получения вводимых строк и быстрой передачи их на сервер для требуемой обработки.
Разработчики систем клиент-сервер могут научиться многому, просматривая интерфейсы различных сайтов, даже если их приложения не разрабатываются для работы в Интернете, потому что браузер является очень тонким клиентом.
Короткие быстрые запросы держат пользователя в курсе о состоянии базы данных и уменьшают загрузку сети. Эффективные клиенты базы данных предоставляют детализированный интерфейс поиска, а не браузер таблиц, и ограничивают набор строк в количестве не более чем 200.
Реляционные базы данных используют надежные структуры данных с высоким уровнем абстракции для эффективного получения предсказуемых корректных результатов операций. Полный анализ сущностей и процессов вашей системы является основной деятельностью, таким образом вы приходите к логической модели, которая свободна от избыточности и представляет любое отношение.
В процессе логического анализа первичный ключ (primary key) устанавливается для всех сгруппированных данных. Логический первичный ключ помогает определить, какой элемент (или группа элементов) способен однозначно идентифицировать группу связанных данных. Физическое проектирование таблиц будет отображать логическую группировку и уникальность характеристик модели данных, хотя структуры таблиц и ключевые столбцы, созданные в черновом варианте, не часто в точности соответствуют модели. Например, в таблице Employee уникальный ключ состоит из полей имени и фамилии и др. Поскольку составной уникальный ключ в модели данных включает элементы большого размера, которые могут приводить человека к ошибкам, в таблицу должен быть добавлен столбец в качестве суррогатного первичного ключа.
Реляционные СУБД предполагают, что каждая строка в каждой таблице имеет уникальный столбец для однозначной идентификации строк, для проверки соответствия условиям поиска и для связи элементов данных и потоков [7] .
Отношения в модели представлены ключами в таблицах. Теоретически каждое отношение в модели должно быть реализовано в виде пары связанных между собой ключей. Когда ключи связаны между собой через ограничение внешнего ключа, таблицы становятся связанными в сеть зависимостей, которые отображают взаимодействие групп данных независимо от контекста. Основные правила логики сервера ссылаются на эти зависимости для поддержания ссылочной целостности базы данных. Стандарты SQL формулируют правила, описывая как зависимости целостности должны работать. От разработчика реляционной СУБД зависит решение, каким образом будут реализовываться и поддерживаться эти зависимости.
7
Строго говоря, наличие уникального ключа в таблице не является обязательным для реляционных баз данных, хотя его наличие весьма желательно.
– Прим. перев.