Абстракция хранимых данных

Абстракция хранимых данных

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

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

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

* Большие составные символьные ключи, составленные из столбцов реальных данных.

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

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

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

Отбрасывание идеологии электронных таблиц

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

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

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

Таблицы для вывода

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

Пользовательский интерфейс

Клиентские приложения в системе, где информационные сервисы предприятия имеют серверную программу, которая является полнокровной СУБД с мощными возможностями обработки данных, не изменяют вводимые пользователем данные после выполнения синтаксического разбора их исходного вида и упаковывания кода в подготовленные контейнеры - в структуры транспортных функций API. Циклам FOR над сотнями и тысячами строк в клиентском буфере набора данных нет места на клиентском компьютере в системах клиент-сервер.

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

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

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

Модель хранения реляционных данных

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

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

В процессе логического анализа первичный ключ (primary key) устанавливается для всех сгруппированных данных. Логический первичный ключ помогает определить, какой элемент (или группа элементов) способен однозначно идентифицировать группу связанных данных. Физическое проектирование таблиц будет отображать логическую группировку и уникальность характеристик модели данных, хотя структуры таблиц и ключевые столбцы, созданные в черновом варианте, не часто в точности соответствуют модели. Например, в таблице Employee уникальный ключ состоит из полей имени и фамилии и др. Поскольку составной уникальный ключ в модели данных включает элементы большого размера, которые могут приводить человека к ошибкам, в таблицу должен быть добавлен столбец в качестве суррогатного первичного ключа.

Реляционные СУБД предполагают, что каждая строка в каждой таблице имеет уникальный столбец для однозначной идентификации строк, для проверки соответствия условиям поиска и для связи элементов данных и потоков[7].

Отношения

Отношения в модели представлены ключами в таблицах. Теоретически каждое отношение в модели должно быть реализовано в виде пары связанных между собой ключей. Когда ключи связаны между собой через ограничение внешнего ключа, таблицы становятся связанными в сеть зависимостей, которые отображают взаимодействие групп данных независимо от контекста. Основные правила логики сервера ссылаются на эти зависимости для поддержания ссылочной целостности базы данных. Стандарты SQL формулируют правила, описывая как зависимости целостности должны работать. От разработчика реляционной СУБД зависит решение, каким образом будут реализовываться и поддерживаться эти зависимости.

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

Реляционная СУБД может реализовать отношения, которые не используют ключей. Например, она может получать наборы данных, основываясь на сравнении значений или на выражениях, включающих значения различных столбцов одной таблицы или столбцов из нескольких таблиц.

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

Поделитесь на страничке

Следующая глава >

Похожие главы из других книг:

Разделители в хранимых процедурах

Из книги автора

Разделители в хранимых процедурах Обратите внимание, что оператор внутри процедуры заканчивается точкой с запятой (;). Как известно, точка с запятой является стандартным разделителем команд в SQL - она является сигналом интерпретатору SQL, что текст команды введен полностью


Работа с массивами в хранимых процедурах

Из книги автора

Работа с массивами в хранимых процедурах Массивы, как было сказано в главе "Типы данных", позволяют хранить в одном поле набор данных какого-нибудь одного элементарного типа. Однако "простым" SQL-запросом данные не извлечь и не изменить. Необходим особый подход для работы с


Вызов хранимых процедур InterBase с использованием стандартного синтаксиса ODBC

Из книги автора

Вызов хранимых процедур InterBase с использованием стандартного синтаксиса ODBC Как известно, InterBase использует два типа хранимых процедур" так называемые selectable-процедуры и executeable-процедуры; при этом процедуры разного типа отличаются способом вызова в SQL. В отличие от других ODBC-


Создание и запуск хранимых процедур

Из книги автора

Создание и запуск хранимых процедур С помощью представления можно контролировать данные, возвращаемые SQL Server, однако существует еще более мощное средство — хранимые процедуры (stored procedures). Хранимые процедуры подобны представлениям, но могут выполнять более сложные


Запуск хранимых процедур в окне программы SQL Query Analyzer

Из книги автора

Запуск хранимых процедур в окне программы SQL Query Analyzer Для запуска хранимых процедур (а также представлений и других команд SQL) можно воспользоваться программой SQL Query Analyzer. Таким образом можно протестировать созданную хранимую процедуру или представление. Для запуска


Отображение текста существующих представлений или хранимых процедур

Из книги автора

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


Выполнение хранимых процедур с помощью DbCommand

Из книги автора

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


5.2. Синтаксис хранимых процедур

Из книги автора

5.2. Синтаксис хранимых процедур Сохраненная подпрограмма является процедурой или функцией. Сохраненные подпрограммы созданы командами CREATE PROCEDURE и CREATE FUNCTION. Процедура вызывается, используя инструкцию CALL, и может только передавать обратные значения, используя переменные


Преимущества использования хранимых процедур

Из книги автора

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


Компиляция хранимых процедур и триггеров

Из книги автора

Компиляция хранимых процедур и триггеров Для компиляции любого файла скрипта вы должны включить в файл, по крайней мере, одну "пустую строку" после последнего оператора или комментария. Чтобы сделать это, нажмите, по меньшей мере, один раз клавишу <Return> (Enter) в вашем


Создание хранимых процедур

Из книги автора

Создание хранимых процедур В вашем скрипте или в isql начните с установки символа терминатора, который будет использован для отметки конца синтаксиса CREATE PROCEDURE. Следующий пример устанавливает символ терминатора в &:SET TERM &;Синтаксис оператора:CREATE PROCEDURE


Изменение хранимых процедур

Из книги автора

Изменение хранимых процедур Firebird 1.0.x предоставляет два способа изменения хранимых процедур с использованием операторов DDL, a Firebird 1.5 добавляет еще и третий. Это:* оператор ALTER PROCEDURE, который изменяет определение существующей хранимой процедуры, сохраняя ее


Удаление хранимых процедур

Из книги автора

Удаление хранимых процедур Оператор DROP PROCEDURE удаляет существующую хранимую процедуру из базы данных. Вы можете использовать этот оператор везде, где можно использовать операторы DDL.! ! !ПРИМЕЧАНИЕ. Операторы DDL не могут выполняться как операторы PSQL. При этом в Firebird 1.5


4.2. Абстракция данных

Из книги автора

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