Logo    
Деловая газета CitCity.ru CITKIT.ru - все об Open Source Форумы Все публикации Учебный центр Курилка
CitForum    CITForum на CD    Подписка на новости портала Море(!) аналитической информации! :: CITFORUM.RU
IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

07.06.2017

Google
WWW CITForum.ru
С Новым годом!
2005 г.

Дилемма инкапсуляции и оптимизации запросов

Майкл Блаха, Modelsoft Consulting Corp, ODBMS.ORG
Перевод - Сергей Кузнецов

Предисловие переводчика

В 2005 г. Майкл Блаха специально для портала www.odbms.org написал статью "Дилемма инкапсуляции и оптимизации запросов". Статья показалась нам интересной в двух отношениях. Во-первых, в ней используется непривычная для нас трактовка термина "инкапсуляция". По Блахе методы объекта являются инкапсулированными, если из них вызываются только методы объектов-соседей данного объекта по связям. Такой метод объектно-ориентированного программирования соответствует требованиям закона Деметры (или закона хорошего стиля программирования), сформулированного Карлом Либерхером, Яном Холландом и Артуром Райлом (Karl Lieberherr, Ian Holland, Arthur J. Riel) еще в 1988 г. Во-вторых, автор достаточно убедительно показывает, что подобная инкапсуляция конфликтует с такими методами формулировки запросов к базам данных, которые дают возможность оптимизатору запросов производить наиболее эффективные планы. Как утверждает автор (и с этим трудно не согласиться), этот конфликт является непреодолимым в принципе. Но, поскольку при наличии этого конфликта нужно продолжать создавать качественные и эффективные приложения, автор дает несколько практических советов, которые, хотя и являются достаточно очевидными, могут пригодиться на практике.

Аннотация

Между целями инкапсуляции и оптимизации запросов имеется фундаментальный, неразрешимый конфликт [1] [2].

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

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

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

1. Инкапсуляция

Принцип инкапсуляции выразительно устанавливается законом Деметры [3]. «Для любого класса C и для любого метода M, связанного с C, все объекты, которым M посылает сообщение, должны быть экземплярами классов, ассоциированными со следующими классами:

  • Классами аргументов M (включая C).
  • Классами переменных экземпляра C

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

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

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

У инкапсуляции имеются две основные мотивировки:

  1. Упрощение изменений. Инкапсуляция минимизирует зависимость метода от других классов.
  2. Уменьшение сложности программирования. Инкапсуляция ограничивает число типов, которые должны быть известны программисту при написании метода.

При отсутствии инкапсуляции в пределе метод мог бы обходить все ассоциации модели классов.

2. Оптимизация запросов

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

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

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

3. Пример

На рис. 1 показана часть диаграммы классов системы резервирования авиационных билетов. Авиалинии (Airlines) совершают рейсы между Аэропортами (Airports). ОписаниеРейса (FlightDescription) – это опубликованное описание воздушного путешествия между двумя Аэропортами (Airports). В отличие от этого, Рейс (Flight) – это реальный рейс самолета в конкретную дату. Атрибут частота (frequency) показывает дни недели, для которых применимо ОписаниеРейса. Атрибуты начальнаяДействующаяДата (startEffectiveDate) и конечнаяДействующаяДата (stopEffectiveDate) показывают период времени, в течение которого действует данное ОписаниеРейса.

Примером ОписаниеРейса является TW 250 из St. Louis в Milwaukee. Осенью 1995 г. рейс TW 250 по расписанию должен был отбывать в 7:42 утра, расчетное время полета составляло час пятнадцать минут, рейс должен был выполняться в каждый день недели, кроме субботы, и всегда самолетом DC9. Реальный Рейс TW 250 был, например, выполнен 23 октября 1995 г. со временем убытия в 7:42 утра и временем в пути один час пятнадцать минут.

В каждом ОписанииРейса присутствует ОписаниеСамолета (AircraftDescription). Например, в соответствии с ОписаниемРейса, рейс TW 250 должен был выполняться на самолете DC9. В отличие от этого, Рейсу соответствует реальный физический Самолет (Aircraft), у которого имеется уникальный регистрационныйНомер (registrationNumber).


Рис. 1. Модель классов UML для системы резервирования авиационных билетов

Модель позволяет отвечать на запросы, подобные следующему: «Найти Авиалинию, выполняющую рейсы на указанном Самолете». Инкапсуляция привела бы к следующей последовательности вызовов методов. (Заметим, что единственным осмысленным путем является Aircraft.Flight.FlightDescription.Airline.)

  1. Aircraft.getAirline() вызывает Flight.getAirline() для каждого Рейса данного Самолета. Модель классов допускает наличие нескольких Авиалиний для одного Самолета, хотя это не предусматривается. (В модели классов отсутствует ограничение, которое могло бы предотврарить это явление.) В код приложения пришлось бы вставить соответствующую проверку, которая выдавала бы в данном случае код ошибки.
  2. Flight.getAirline() вызывает FlightDescription.getAirline().
  3. FlightDescription.getAirline() возвращает Airline.

В качестве альтернативы можно было бы написать следующий SQL-запрос. (Это код расчитан на MS SQL Server и предполагает наличие очевидной схемы базы данных.)

SELECT DISTINCT(FD.airlineID)
FROM Aircraft AS Ac
INNER JOIN Flight AS F
ON Ac.aircraftID = F.aircraftID
INNER JOIN FlightDescription AS FD
ON F.flightDescriptionID = FD.flightDescriptionID
WHERE Ac.aircraftID = theGivenAircraft

Теперь рассмотрим влияние пересмотра модели. Модель на рис. 1 нехороша тем, что в ней не поддерживаются сквозные полеты. Авиакомпании регулярно организуют рейсы, которые начинаются в одном городе, делают остановки в одном или нескольких промежуточных городах и завершаются в городе назначения. У всей последовательности рейсов имеется единый номер рейса, но присутствуют промежуточные аэропорты, отличные от аэропортов отправления и прибытия. Для поддержки сквозных рейсов на рис. 2 добавляется ОписаниеЭтапаРейса (FlightLegDescription).


Рис. 2. Пересмотренная модель классов UML для системы резервирования авиационных билетов с добавлением класса FlightLegDescription

Это исправление влияет на ассоциацию между Flight и FlightDescription. Соответственно, требуется переписать метод Flight.getAirline(), чтобы он вызывал новый метод FlightLegDescription.getAirline(). Никакие другие исправления в предыдущих методах не требуются. Так что при использовании искапсуляции небольшое изменение модели классов влияет только на непосредственно воздействуемые методы. В отличие от этого, сложные запросы к СУБД затрагивают много классов, поэтому вероятность потребности их переписывания гораздо больше.

4. Анализ в сравнении с проектированием

Следует прояснить один аспект нашего обсуждения. Согласование инкапсуляции и оптимизации запросов – это проблема проектирования, а не анализа. Целью анализа является понимание приложения. На этом этапе нас не заботит точное конструирование окончательного кода.

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

5. Что же делать?

Мы разъяснили суть конфликта между инкапсуляцией и оптимизацией запросов, но что же в связи с этим может сделать разработчик?

  1. Программные приложения. Здесь нет проблем, поскольку в языках программирования нет оптимизатора запросов. Нужно просто инкапсулировать код, следуя советам литературы, посвященной объектно-ориентированному программированию.
  2. Приложения ООСУБД. Обычно следует склоняться к инкапсуляции. В настоящее время у большинства ООСУБД имеются достаточно слабые оптимизаторы запросов, не слишком стимулирующие формулировку широких запросов.
  3. Приложения РСУБД. В этом случае нет простого ответа. Имеются три разных случая.
  • Сложное программирование. Если программирование является сложным, а требования к производительности не слишком велики, следует инкапсулировать код.
  • Простое программирование и хорошая эффективность обработки запросов. Если свободно формулируемые запросы существенно повышают производительность РСУБД, а программирование кода и запросов является относительно простым, можно согласиться с переписыванием приложения при изменении модели.
  • Простое программирование и плохая эффективность выполнения запросов. Как это не парадоксально, иногда можно повысить эффективность путем фрагментации запросов. Оптимизаторы запросов не являются совершенными, и иногда может потребоваться помочь оптимизатору вручную. В этом случае вы смешиваете инкапсуляцию и оптимизацию запросов, пишите запросы, обходящие несколько классов, но меньшее число, чем в предыдущем случае.

Литература

[1] Michael Blaha and William Premerlani. Object-Oriented Modeling and Design for Database Applications. Upper Saddle River, New Jersey: Prentice Hall, 1998.

[2] Michael Blaha and James Rumbaugh. Object-Oriented Modeling and Design with UML, Second Edition. Upper Saddle River, New Jersey: Prentice Hall, 2005.

[3] K. Lieberherr, I. Holland, and A. Riel. Object-oriented programming: An objective sense of style. OOPSLA’88 as ACM SIGPLAN 23, 11 (November 1988), 323–334.

Об авторе

Майкл Блаха (Michael Blaha) защитил кандидатскую диссертацию в области баз данных в Университете им. Вашингтона г. Санкт-Луи, шт. Миссури. Восемь лет он проработал в Центре исследований и разработок компании General Electric в компании Джеймса Рэмбо (James Rumbaugh). С 1993 г. Блаха является консультантом и преподавателем в областях моделирования, архитектуры программного обеспечения, проектирования баз данных и обратной инженерии. Блаха - автор четырех книг и многочисленных статей. В 2005 г. вышло второе издание его книги (в соавторстве с Рэмбо) "Объектно-ориентированное моделирование и проектирование c использованием UML" (Object-Oriented Modeling and Design with UML, Second Edition, Prentice Hall, 2005, ISBN 0130159204).

Подписка на новости IT-портала CITForum.ru
(библиотека, CITKIT.ru, CitCity)

Новые публикации:

24 декабря

CITKIT.ru:

  • Новогодние поздравления
  • Сергей Кузнецов. Цикл Операционные системы: Ностальгия по будущему:

  • Алексей Федорчук. OpenSolaris 2008.11 Release

  • Сергей Голубев:

  • Евгений Чайкин aka StraNNik (Блогометки):

    17 декабря

  • С.Д.Кузнецов. Базы данных. Вводный курс

    10 декабря

    CITKIT.ru:

  • OpenSolaris 2008.11 Release

  • Альтернативные ОС: две грустные истории (С.Кузнецов)
  • Nokia N810 — доведение до ума
  • CitCity:

  • Платформа 2009: заоблачные перспективы Microsoft

    4 декабря

  • Лекция С.Д.Кузнецова Понятие модели данных. Обзор разновидностей моделей данных

    CITKIT.ru:

  • OpenSolaris 2008.11 Release. Первые впечатления

  • Linux vs FreeBSD: продолжим "Священные войны"?

  • Nokia N810 as is

  • Индульгенция для FOSS

  • Друзья СПО'2008

    26 ноября

  • Нечеткое сравнение коллекций: семантический и алгоритмический аспекты

    CitCity:

    CITKIT.ru:

  • Глава из книги А.Федорчука
    Сага о FreeBSD:
  • 19 ноября

  • Проблемы экономики производства крупных программных продуктов

  • Язык модификации данных формата XML функциональными методами

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

    Заметки к книге:

  • FreeBSD: монтирование сменных устройств и механизм HAL
  • Текстовый редактор ee

    12 ноября

  • Правило пяти минут двадцать лет спустя, и как флэш-память изменяет правила (Гоц Грейф, перевод: Сергей Кузнецов)

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:
  • OSS в России: взгляд правоведа (В.Житомирский)

  • Новая статья из цикла С.Голубева "Железный марш":

    29 октября

  • О некоторых задачах обратной инженерии

  • Веб-сервисы и Ruby

  • Тестирование web-приложений с помощью Ruby

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

  • PuppyRus Linux - беседа с разработчиком (С.Голубев)

  • Сергей Кузнецов. Заметка не про Linux

    22 октября

  • Обзор методов описания встраиваемой аппаратуры и построения инструментария кросс-разработки

    CITKIT.ru:

  • Сергей Кузнецов. Почему я равнодушен к Linux

  • Глава из книги А.Федорчука
    Сага о FreeBSD:
  • Что надо иметь
    3. Базовые познания

    CitCity:

  • Управление IT-инфраструктурой на основе продуктов Microsoft

    15 октября

  • Методы бикластеризации для анализа интернет-данных

    CitCity:

  • Разъемы на ноутбуках: что они дают и зачем их так много?
  • AMD Puma и Intel Centrino 2: кто лучше?

    CITKIT.ru:

  • Новый цикл статей С.Голубева
    Железный марш:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

    8 октября

  • Автоматизация тестирования web-приложений, основанных на скриптовых языках
  • Опыт применения технологии Azov для тестирования библиотеки Qt3

    Обзоры журнала Computer:

  • SOA с гарантией качества
  • Пикоджоуль ватт бережет
  • ICT и всемирное развитие

    CitCity:

  • Пиррова победа корпорации Microsoft

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

    Статья из архива:

  • Я живу в FreeBSD (Вадим Колонцов)

    Новые Блогометки:

  • Перекройка шаблона Blogger или N шагов к настоящему
  • Blogger. Comment style
  • Screenie или глянцевый снимок экрана

    2 октября

    CITKIT.ru:

  • Сага о FreeBSD (А. Федорчук)

    Zenwalk: пакет недели

  • Банинг — интеллектуальное развлечение (С.Голубев)

    CitCity:

    25 сентября

  • Клермонтский отчет об исследованиях в области баз данных

    CITKIT.ru:

  • Пользователям просьба не беспокоиться... (В.Попов)

  • Снова про ZFS: диск хорошо, а два лучше
  • Командная оболочка tcsh (А.Федорчук)

    Zenwalk: пакет недели

    17 сентября

  • T2C: технология автоматизированной разработки тестов базовой функциональности программных интерфейсов
  • Технология Azov автоматизации массового создания тестов работоспособности

    CITKIT.ru:

  • FreeBSD: ZFS vs UFS, и обе-две — против всех (А.Федорчук)

    Zenwalk: пакет недели

  • Дачнет — практика без теории (С.Голубев)

    10 сентября

  • За чем следить и чем управлять при работе приложений с Oracle
  • Планировщик заданий в Oracle
    (В.Пржиялковский)

    CITKIT.ru:

  • Microsoft: ответный "боян" (С.Голубев)

  • Причуды симбиоза, или снова "сделай сам" (В.Попов)

  • Файловые системы современного Linux'а: последнее тестирование
  • Zsh. Введение и обзор возможностей
    (А.Федорчук)

    Описания пакетов Zenwalk: Zsh, Thunar, Thunar-bulk-rename, Xfce4-places-plugin, Xfce4-fsguard-plugin

    Блогометки:

  • Google Chrome
  • Лончер для ASUS Eee PC 701

    3 сентября

    CITKIT.ru:

  • Заметки о ядре (А.Федорчук):

    Добавлены описания пакетов Zenwalk: Galculator, Screenshot, Gnumeric, Pidgin

    В дискуссинном клубе:

  • И еще о Википедии и Google Knol

  • Лекция для начинающего линуксоида (С.Голубев)

    26 августа

  • Транзакционная память (Пересказ: С. Кузнецов)

    CITKIT.ru:

  • Открыт новый проект Zenwalk: пакет недели

  • Статья Текстовые процессоры и их быстродействие: конец еще одной легенды?

    21 августа

    CITKIT.ru:

  • Почему школам следует использовать только свободные программы (Ричард Столлман)
  • Беседа Сергея Голубева с учителем В.В.Михайловым

  • Википедия или Гуглезнание? Приглашение к обсуждению (Алексей Федорчук)
  • Народная энциклопедия от Google (StraNNik)

  • Обзор Mandriva 2009.0 Beta 1 Thornicrofti
  • Новичок в Линукс: Оптимизируем Mandriva 2008.1

  • Книга Zenwalk. Приобщение к Linux:

    13 августа

    CitCity:

  • Мирный Atom на службе человеку. Обзор платы Intel D945GCLF с интегрированным процессором
  • Обзор процессоров Intel Atom 230 на ядре Diamondville

  • iPhone - год спустя. Скоро и в России?

    CITKIT.ru:

  • Интермедия 3.4. GRUB: установка и настройка (из книги Zenwalk. Приобщение к Linux)

    6 августа

  • СУБД с хранением данных по столбцами и по строкам: насколько они отличаются в действительности? (Пересказ: С. Кузнецов)

    CITKIT.ru:

  • Интермедия 2.2. Что неплохо знать для начала (из книги Zenwalk. Приобщение к Linux)

  • И снова про шрифты в Иксах (А.Федорчук)

  • 20 самых быстрых и простых оконных менеджеров для Linux

  • Дело о трех миллиардах (С.Голубев)

    30 июля

  • OLTP в Зазеркалье (Пересказ: С. Кузнецов)

    CitCity:

  • Будущее BI в облаках?
  • Тиражные приложения и заказная разработка. Преимущества для заказчика
  • Дискуссия со сторонниками заказной разработки

    CITKIT.ru:

  • Новые главы книги Zenwalk. Приобщение к Linux:
  • Глава 8. Пакеты: средства установки, системы управления, системы построения
  • Глава 9. Zenwalk: репозитории, пакеты, методы установки

    23 июля

    CITKIT.ru:

  • Все против всех. 64 vs 32, Intel vs AMD, tmpfs vs ext3
  • Две головы от Intel

  • Zenwalk: обзор штатных приложений (глава из книги "Zenwalk. Приобщение к Linux")

  • Нормально, Григорий...

    16 июля

    Обзоры журнала Computer:

  • Перспективы и проблемы программной инженерии в XXI веке
  • Большие хлопоты с большими объемами данных
  • Перспективы наноэлектроники

    CITKIT.ru:

  • Интермедия о лицензиях (А.Федорчук. "Zenwalk. Приобщение к Linux")

  • Есть ли будущее у KDE?

  • Linux в школе: альтернативный вариант в задачах

  • Шифр (приключения агента Никодима)

    10 июля

    CITKIT.ru:

  • Новые разделы книги А. Федорчука Zenwalk. Приобщение к Linux:
  • Интермедия вступительная. Linux или GNU/Linux? Как вас теперь называть?
  • Глава 5. Среда Xfce
  • Глава 6. Xfce: приложения и плагины

  • ZUR (Zenwalk User Repository) FAQ

    2 июля

  • Персистентность данных в объектно-ориентированных приложениях (С. Кузнецов)

    CITKIT.ru:

  • Новые разделы книги А. Федорчука Zenwalk. Приобщение к Linux:
  • Интермедия 1.2. Дорога к Zenwalk'у. Период бури и натиска
  • Интермедия 3.3. Немного о Linux'е и "железе"
  • Глава 4. Настройка: инструментами и руками
  • Интермедия 4.1. Zenpanel и конфиги: поиски корреляции

  • Интервью с Жан-Филиппом Гийоменом, создателем дистрибутива Zenwalk

  • Linux в школе: первые итоги (С. Голубев)

    25 июня

    CITKIT.ru:

  • Zenwalk. Приобщение к Linux (А. Федорчук)

  • Логика и риторика (С.Голубев)

  • Технология Tru64 AdvFS

  • Ханс Райзер предлагает отвести полицейских к телу Нины

    18 июня

  • Проекты по управлению данными в Google (Пересказ: С. Кузнецов)

    CITKIT.ru:

  • ОС и поддержка "железа": мифы и реальность (А. Федорчук)

  • Linux в школе: другие дистрибутивы

  • Пинок (С. Голубев)

    4 июня

  • Ландшафт области управления данными: аналитический обзор (С. Кузнецов)

    CITKIT.ru:

  • Linux в школе: слово заинтересованным лицам

  • SlackBuild: пакеты своими руками

  • Linux от компании Novell. Установка и обзор openSUSE Linux

    Все публикации >>>




  • IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

    Информация для рекламодателей Пресс-релизы — pr@citcity.ru
    Послать комментарий
    Информация для авторов
    Rambler's Top100 This Web server launched on February 24, 1997
    Copyright © 1997-2017 CIT, © 2001-2017 CIT Forum
    Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. Подробнее...