Введение в системы БД (542480), страница 212
Текст из файла (страница 212)
Это позволяет оптимизатору оценивать размер промежуточных результатов типа ТЕМР1 и ТЕМР2. Распространение обновлении. Алгоритмом распространения обновления в системе БРР-1 предусматривается "немедленное распространение" (понятие первичной копии в ней не вводится). Управление параллельностью. Управление параллельностью основано не на механизме блокировок, а на методе синхронизации с использованием временнык отметок. Цель выбора этого метода состоит в попытке избежать дополнительных накладных расходов на отправку сообщений о блокировке, однако расплатой за это будет относительно небольшая степень параллельности! Дополнительные подробности в этой книге не приводятся, хотя в аннотации к (!5.3) очень кратко описана основная идея.
Более подробную информацию можно получить в [20.6) и (20.13]. Управление восстановлением. Восстановление основано на протоколе четырехфазной фиксации, который был выбран для того, чтобы в случае выхода из строя координирующего узла обеспечить большую гибкость всего процесса, чем при использовании обычного протокола двухфазной фиксации. При такой организации управления, к сожалению, процесс, в целом, значительно усложняется. Дополнительные подробности в этой книге не приводятся.
Каталог. Каталог управляется так же, как и обычные пользовательские данные, т.е. он может быть произвольно фрагментирован, а сами фрагменты могут быть реплицированы и распространяться произвольным образом, как и любые другие данные. Преимушества такого подхода очевидны, а недостатки, к сожалению, состоят в том, что, поскольку система не обладает никакими сведениями о расположении произвольной части каталога, ей для хранения таких сведений необхолимо придерживать каталог более высокого уровня, который полностью реплицируется, т.е. на каждом узле должна храниться его копия.
20.35.Бе!!пЯег Р. О., Аг)!Ьа М Е. Ассезз Ра(Ь Бе)есйоп !п Р(з(г!Ьцзес$ Ра!а Вазе МапаЕешеп( Бумешз /! Б.М. Рееп апг) Р. Нашшегз!еу, Ргос.!пб Сопб Оп Раза Вазез. — АЬегбееп, Бсог!апб; Епй!апс): Неумел апд Болз Егб., 1980. См. комментарий к 120.39). 20.36.БгопеЬга)гег М. М., Ыецйо!б Е. !. РцвНЬцгеб Раса Вазе Уегз(оп об !пбгез д Ргос. 2пб Вег)г!еу Сопб Оп Р(згг!Ьцгеб Ра!а МапаЕешепг апг( Сошрцгег Хеьчог(гз. — 3-очтепсе Вег)г!еу (.аЬогагогу, Мау, 1977.
810 Часть г'. Дополнительные аспекты Работы [20.17], [20.36) и [20.37] связаны с прототипом распределенной системы |ХОКЕБ. Распределенная система О|в!с!Ьисес| 1п8гев состоит из нескольких копий программного обеспечения Оп!чегв!су 1пйгев, установленных и запущенных на нескольких компьютерах РОР-!! в фирмы ОЕС. Она поддерживает независимость от расположения (как в системах БОО-1 и Кч), независимость от фрагментации, репликацию данных лля фрагментов и независимость от репликации.
В отличие от систем БОО-! и Кч в системе О!всг!Ьисес!!пйгев не предполагается, что передача данных в сети обязательно должна быть медленной; наоборот, эта система спроек- тирована как для медленных сетей дальней связи, так и для сравнительно быстрых локальных сетей. Причем оптимизатор запросов может обнаружить разницу между двумя этими случаями. Алгоритм оптимизации запросов является расширением стратегии декомпозиции системы !пйгев, описанной в главе 17, Более подробно он рассматривается в [20.17). В системе О|вспЬцсес| |пйгев обеспечиваются два алгоритма распространения обновления: "эффективный" алгоритм, согласно которому обновляется первичная копия и управление возврашается данной транзакции (причем распространение обновлений выполняется параллельно с помошью набора подчиненных процессов), а также "надежный" алгоритм, согласно которому все копии обновляются одновременно [20.37).
В обоих случаях управление параллельностью основано на механизме блокировки, а управление восстановлением — на протоколе двухфазной фиксации (с некоторыми усовершенствованиями). Что касается каталога, в системе О!вспЬцсес! |пйгев используется полная репликация для некоторых частей каталога, в основном тех, которые содержат логическое опи- синие видимых для пользователя переменных-отношений, а также описание того, как эти переменные-отношения фрагментированы.
К тому же с полной репликацией комбинируются элементы локальных каталогов других частей, например описывающих локальные физические структуры хранения, локальную статистику базы данных (используемую оптимизатором), а также ограничения целостности и пра- вила безопасности. 20.37.БСопеЪга!сег М. К. Сопсцгепсу СопСго! апс| СопывСепсу об Ми!йр!е Сор|ев |и ОВСпЬШеб !пйгев 0 1ЕЕЕ Тгапвасс|опв оп Бойсчаге Епй!пеег!п8. — Мау, 1979.
— 5, № 3. См. комментарий к [20.36]. 20.38,%еп-Буап Ь! апс! С!!Коп С. Бешапс!с 1псейгайоп |и Несего8епеоцв ОасаЬавев Ь|в!п8 Хейга! ХеСччог1св I/ Ргос. 20СЬ!пс. Сопб оп Чесу 1.агйе Овса Вавев. — Бапйайо, СМ!е, БерсешЬег, ! 994. 2039.\У|11!ашв К. ес а!. Кч: Ап Очегчсечгобсйе Агсййессиге I! Р. БсЬецегпсапп. !спргоч|п8 ОасаЬаве ()ваЬ~11су апс! Кевропв!чепевв. — Хеч Чог|с, Х,Чл Аеас!ешу Ргевв, 1982. (Эта работа также опубликована в виде отчета: |ВМ Кевеагсй К13325.— ОесешЬег, 1981.) В работах [20.12), [20.29], [20.35] и [20.39] обсуждается система К', которая является распределенной версией системы Буыесп К.
В системе Кч обеспечивается независимость от расположения, но не поддерживаются фрагментация и репликация, а значит, не обеспечивается независимость от фрагментации и репликации. По той же причине для данной системы не возникает вопрос о распространении обновления. Управление параллельностью основано на механизме блоки- Глава 20. Распределенные базы данньп 811 ровки (обратите внимание, что существует только одна копия любого блокируемого объекта; при этом вопрос о первичной копии также не возникает). Управление восстановлением основано на протоколе двухфазной фиксации, но с некоторыми усовершенствованиями.
20.40.%опй Е. Кегг[ет[пй Вгврегзег1 Васа ггогп БВВ-1: А Бузгегп 1ог В[згг[Ьнгей ВагаЬазез. (Опубликовано в [20.41.) См. комментарий к [20.341. 20.41 Уп С. Т., СЬапа С. С. ВиапЬшеб ()негу Ргосезз1па II АСМ Сошр. Зпгч. — 1984.— 16, № 4. Здесь представлен материал по методам оптимизации запросов в распределенных системах, а также приведена обширная библиография.
812 Часть К Дополнительные аспекты Естественно, то, что мы называем банком данных (дага ыоге), тогда чаше всего представляло собой просто набор файлов — производственные данные хранились илн в отдельных файлах, или в не реляционных базах данных (реляционные системы еше только начинали разрабатываться). И даже в последнем случае данные извлекались из базы данных и копировались в файлы, прежде чем они могли быть обработаны системой поддержки принятия решений.
Так продолжалось почти до начала 80-х годов, пока для систем поддержки принятия решений вместо простых файлов не начали использоваться реляционные базы данных. На самом деле поддержка принятия решений, обработка произвольных (ад 'пос) запросов и выдача отчетов были первыми практическими задачами, использовавшими реляционную технологию. Хотя в иастояшее время Я)Ь-продукты получили широкое распространение, идея процесса извлечения, т.е.
копирования данных нз одной операционной среды в какую- либо другую среду не утратила своей значимости. Скопированные данные пользователи могут обрабатывать, как им угодно, без вмешательства в операционную среду. И, конечно, очень часто причиной выполнения таких выборок данных бывает необходимость поддержки принятия решений. Из вышесказанного должно быть ясно, что поддержка принятия решений не является частью самой технологии баз данных. Это скорее одно из прииенений данной технологии (хотя и очень важное), нли, точнее, несколько видов такого применения, отдельных, ио связанных между собой, перечислим зти виды: крапилин!а данных (с!ага иаге1зоцзе), магазины данных (дага шап), банки оперативных данных (орегайопа! дага ыоге), оперативная аналитическая обработка (ОЬАР— оп1ше апа1уйса1 ргосезгйи), тногоиврные базы данных н разработка данных.
Все эти технологии поддержки принятия решений будут рассмотрены в последуюших разделах. Предостережение. Сразу же отметим, что единственное, что объединяет упомянутые технологии, — это то, что в них редко следуют соответствующим логическим принципам проектирования. Практика систем поддержки принятия решений, к сожалению,— вовсе не наука, как можно было представить, и часто является совершенно надуманной.
В частности, наблюдается тенденция к смещению акцентов в сторону физических, а не логических соображений (в действительности различия между физическими и логическими аспектами в области систем поддержки принятия решений часто очень расплывчаты). Отчасти именно поэтому в примерах данной главы будет использоваться язык ВОЬ, а не ТцзоНа! О. Также мы будем применять "менее строгую" терминологию языка БОЬ, употребляя такие термины, как "строки", "столбцы" и "таблицы", вместо терминов "кортежи", "атрибуты" и "переменные-отношения".
Также мы будем использовать термины логическая схеиа и физическая схема в качестве синонимов терминов концептуазыгоя схема и внутренняя схема соответственно, как они были названы в главе 2. План этой главы таков. В разделе 21.2 приволятся аспекты, связанные с практикой проектирования приложений поддержки принятия решений, которые мы считаем неверными. В разделе 2!.3 описан наш собственный подход относительно этих же аспектов. Затем в разделе 21.4 обсуждаются вопросы подготовки данных (т.е. процесс получения оперативных данных в том виде, в котором они могут быть пригодными для выполнения задач поддержки принятия решений); здесь же кратко рассказывается о банках оперативных данных.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
