Дж. Рамбо, М. Блаха - UML 2.0 - Объектно-ориентированное моделирование и разработка (1158633), страница 102

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 102)

° Интерфейс программирования приложений (АР1). Более удачная альтернатива предыдушему методу — инкапсулировать запросы на чтение и запись из базы ланных внутри специальных методов приложения, которые все вместе будут предоставлять интерфейс к базе данных. Эти методы можно написать на фирменном языке доступа к базе данных, таком как Огас!е Р1 /БО1., или на стандартном языке типа ОПВС или )1)ВС. Интерфейс изолирует взаимодействие с базой данных от остальных частей приложения. АР1 помогает разделить задачи управления данными, логику приложения и пользовательский интерфейс, что согласуется с принципами инкапсуляции.

° Хранимые процедуры. Хранимая процедура (згогед ргоседиге) — это программный код, храняшийся в базе данных. Некоторые РСУБД требуют использования таких процедур для достижения максимальной эффективности. Эти процедуры позволяют приложениям совместно использовать некоторую функциональность. Однако не рекомендуется помешать функциональность, относяшуюся только к конкретному приложению, внутрь базы данных, потому что ее сможет использовать любое приложение, а это противоречит принципам инкапсуляции.

Правила работы с хранимыми процедурами разные в разных СУБД. ° Язык четвертого поколения. Язык четвертого поколения (1оцггл-йепегаг1оп 1апйцайе — 401.) — это каркас для приложений баз данных, обеспечивающий вывод на экран, простейшие расчеты и формирование отчетов. Языки четвертого поколения широко распространены и позволяют значительно сократить сроки разработки приложения.

Они особенно удобны для простых приложений и для прототипирования. Для приложений со сложной логикой они не пригодны. ° Общий уровень. Общий уровень скрывает базу данных и прелоставляет простые команды для доступа к данным (такие как КеИесоЫС1оелКеу и гаигелесогг1) [В!аЬа-98). Вы можете писать код приложения с использованием команд этого уровня и игнорировать существование базы данных.

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

Например, РСУБД сначала обрашаются к системным таблицам, а затем к данным. Приложения, управляемые метаданными, могут быть достаточно сложны. Эта методика подходит для каркасов (см. раздел 14) и для самообучаюшихся приложений. 430 Глава 19 е Базы данных В некоторых случаях бывает полезно сочетать различные методики в одном приложении. Например, разработчик может использовать ЛР1 и реализовать часть функциональности в виде хранимых процедур. В табл.

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

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

° Обработка недостающих данных. Нужно решить, что делать с недостающими данными. Можете ли вы добыть их откуда-либо еше, оценить возможные значения или просто ввести нулевые значения? Тут вам могут помочь пользователи системы. ° Перенос данных. Необходимость переноса данных из одного приложения в другое возникает довольно часто. Для такой операции удобно использовать стандартный язык, например ХМ1.. ° Слияние данных.

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

° Изменение структуры данных. Обычно исходные структуры отличаются от целевых, поэтому данные приходится корректировать. Например, одно приложение может хранить телефонный номер в единственном поле; другое может хранить код страны, код города и местный номер раздельно в трех полях. Одинаковые по смыслу поля могут иметь разные названия, типы данных и размеры. Данные могут быть закодированы по-разному, например, пол может быть мужским или женским, М или Ж, 1 или 2 и т. д. Обработку данных следует начинать с их загрузки во вспомогательные таблицы, отражаюшие структуру оригинала. Например, если старое приложение использует файлы, а новое будет работать с реляционной базой данных, разумно будет создать по одной таблице для каждого файла. Каждый столбец файла отображается в столбец соответствующей таблицы, с тем же типом и размером данных.

Большинство РСУБД с легкостью могут выполнить такую операцию. 19.6. Реализация функциональности 431 После того как данные будут загружены во вспомогательные таблицы базы данных, с ними уже можно работать посредством команд 5О) . Это часто оказывается проще, чем писать программу на каком-либо другом языке.

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

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

Инкапсуляция и оптимизация запросов В разделе 15.10.1 мы подчеркнули важность инкапсуляции (сокрытия информации). Из этого следовало, что возможности прослеживания модели классов следует ограничивать. К сожалению, принципы инкапсуляции противоречат принципам оптимизации запросов РСУБД. В соответствии с принципами инкапсуляции, объект должен обрашаться только к непосредственно связанным с ним объектам. Обращение к прочим объектам осуществляется посредством методов промежуточных объектов. Инкапсуляция увеличивает устойчивость приложения: локальные изменения в модели приложения вызывают локальные (а не глобальные) изменения в коде.

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

Простого решения этого противоречия для РСУБД не сушествует. Возможны три различные ситуации: ° Запутанная программа. Если программный код достаточно сложен, а падение производительности не слишком велико, этот код следует инкапсулировать. ° Простая программа и хорошая производительность запросов. Запросы следует формулировать широко, если это повышает производительность РСУБД, а программный код и сами запросы не слишком сложны для формулирования и переформулирования при возможных изменениях модели классов. 432 Глава 19 ° Базы данных ° Простая программа и низкая производительность запросов.

Как это ни странно, иногда фрагментация запросов приводит не к падению, а к повышению производительности. Идеального оптимизатора запросов не существует, иногда его приходится направлять вручную. 19.6.4. Использование кода Я~~ Методы всегда можно написать на каком-нибудь языке программирования, но иногда оптимальной альтернативой этому является использование кода БЯ1.. Опытный разработчик пишет запросы ЯЯ). быстрее, чем код программы. Более того, код ЯЯ1. выполняется быстрее, содержит меньше ошибок и легче поддается расширению.

Характеристики

Список файлов книги