Л е к ц и я №01. Информационные технологии баз данных.

Л е к ц и я №01. Базы данных.
Информационные технологии баз данных.
1.
2.
3.
4.
5.
Понятие БД........................................................................................................................................................ 1
Предметная область и модель организации данных. ................................................................................... 1
Проектирование реляционных баз данных. ................................................................................................... 6
Технологии и модели вычислений. ............................................................................................................... 13
Распределенные информационные системы. ............................................................................................. 17
СЛАЙД №2
1. Понятие БД
Базой данных является представленная в объективной форме совокупность самостоятельных материалов (статей, расчетов, нормативных актов, судебных решений и иных подобных
материалов), систематизированных таким образом, чтобы эти материалы могли быть
найдены и обработаны с помощью ЭВМ (Гражданский кодекс РФ, ст. 1260).
Существует множество других определений понятия «база данных», так или иначе сводящихся
к понятию «совокупность хранимых данных». Однако большинство из этих определений не
позволяет отличить базу данных от объектов, которые базой данных заведомо не являются,
например, от архивов документов, картотек, библиотек и т.п. Таким образом, база данных есть
не просто совокупность хранимых данных (записей, документов, фактов и т.п.), но такая совокупность, которая обладает, по меньшей мере, тремя важными свойствами (признаками):
1. База данных хранится и обрабатывается в вычислительной системе. Таким образом,
любые внекомпьютерные хранилища информации (архивы, библиотеки и т. п.) базами данных не являются.
2. Данные в базе данных хорошо структурированы (систематизированы). Под структурированностью в данном случае понимается явное выделение составных частей (элементов),
связей между ними, а также типизация элементов и связей, при которой с каждым типом
элемента или связи соотносится определённая семантика и допустимые операции.
3. Структура базы данных обеспечивает эффективный поиск и обработку данных. Эффективность здесь главным образом определяется тем, как соотносятся гибкость и мощность возможностей (поиска и обработки) с затратами усилий и ресурсов.
Из трёх перечисленных признаков только первый является строгим, а два других допускают
различные трактовки и различные степени оценки. Не существует возможности строго формально определить, является ли некоторая совокупность данных на компьютере базой данных
или нет. Можно лишь установить некоторую степень соответствия требованиям к БД.
В такой ситуации не последнюю роль играет общепринятая практика. В соответствии с ней,
например, не называют базами данных файловые архивы или электронные таблицы, несмотря на то, что они в некоторой степени обладают признаками БД. Принято считать, что эта
степень в большинстве случаев недостаточна (хотя могут быть исключения).
Базой данных часто ошибочно называют систему управления базами данных. Необходимо
различать хранимые данные (собственно БД) и программное обеспечение, предназначенное
для организации и ведения базы данных (СУБД).
СЛАЙД №3
2. Предметная область и модель организации данных.
Основным назначением информационных систем является оперативное обеспечение пользователя информацией о внешнем мире путем реализации вопросно-ответного отношения. Во-
2
просно-ответные отношения, получая интерпретацию во внешнем мире (мире вне информационной системы), позволяют выделить для информационной системы определенный его фрагмент - предметную область, - который будет воплощен в автоматизированной информационной системе. Информация о внешнем мире представляется в информационной системе (ИС) в
форме данных. Это ограничивает возможности смысловой интерпретации информации и конкретизирует семантику ее представления в ИС. Совокупность этих выделенных для ИС
данных, связей между ними и операций над ними образует информационную и функциональную модели предметной области, описывающие ее состояние с определенной точностью.
Важно понимать, что информационная и функциональная модели предметной области создаются на этапе анализа требований к базе данных и не содержат предположений о технологии реализации базы данных. Они строятся независимо от выбираемой модели данных (сетевой, иерархической, реляционной, объектно-ориентированной, многомерной и т.д.), поддерживаемой СУБД, модели вычислений, программно-аппаратной платформы для базы данных.
Информационная и функциональная модели предметной области являются входными данными для процесса проектирования базы данных. Поэтому проектировщик должен уметь правильно интерпретировать их в ходе решения своих проектных задач.
Понятие предметной области базы данных является одним из базовых понятий информатики и не имеет точного определения. Его использование в контексте ИС предполагает
существование устойчивой во времени соотнесенности между именами, понятиями и
определенными реалиями внешнего мира, не зависящей от самой ИС и ее круга пользователей. Таким образом, введение в рассмотрение понятия предметной области базы данных
ограничивает и делает обозримым пространство информационного поиска в ИС и позволяет
выполнять запросы за конечное время.
Совокупность реалий (объектов) внешнего мира - объектов, о которых можно задавать вопросы, - образует объектное ядро предметной области, которое имеет онтологический (явный)
статус. Нельзя получить в ИС ответ на вопрос о том, что ей неизвестно. Термин объект является первичным, неопределяемым понятием. Синонимами термина "объект" являются "реалия,
сущность, вещь". Однако термин сущность понимается нами несколько уже, как компонент модели предметной области, т.е. как уже выделенный на концептуальном уровне объект для базы данных. Таким образом, выделяемые в предметной области объекты превращаются
аналитиками (а не проектировщиками базы данных) в сущности. Сущность предметной области является результатом абстрагирования реального объекта путем выделения и фиксации
набора его свойств. Сущность является результатом абстрагирования реального объекта, т.е.
в нашем контексте имеет гносеологический статус. Хотя далее в контексте сущность нередко
отождествляется с объектом.
СЛАЙД №4
Рис. 2.1. Классификации объектов предметной области
3
Примерами сущностей (с точки зрения ИС) или объектов (с точки зрения внешнего мира) являются: отдельный студент, группа студентов, аудитория, время занятий, слова, числа, символы. Обычно считается, что быть объектом - это значит быть дискретным и различимым. Примеры "не-объектов" - это мир, время, смысл, хотя и такие категории могут сохраняться в базе
данных.
С объектами связано две проблемы: идентификация и адекватное описание. Для идентификации используют имя. При этом предполагается, что происходит отказ от его смысла, который присущ естественному языку. Используется только указательная функция имени. Имя это прямой способ идентификации объекта. К косвенным способам идентификации объекта
относят определение объекта через его свойства (характеристики или признаки).
Объекты взаимодействуют между собой через свои свойства, что порождает ситуации. Ситуации - это взаимосвязи, выражающие взаимоотношения между объектами. Ситуации в
предметной области описываются посредством высказываний о предметной области с использованием исчисления высказываний и исчисления предикатов, т.е. формальной, математической логики. Например, высказывание "Программист и менеджер есть служащие компании"
описывает отношение включения. Таким образом, вся информация об объектах и сущностях
предметной области описывается с помощью утверждений на естественном языке.
Методы математической логики позволяют формализовать эти утверждения и представить их
в виде, пригодном для анализа.
СЛАЙД №5
Информационная модель предметной области базы данных
Одним из ключевых моментов создания ИС с целью автоматизации информационных процессов организации является всестороннее изучение объектов автоматизации, их свойств,
взаимоотношений между этими объектами и представление полученной информации в виде
информационной модели данных.
Информационная модель данных предназначена для представления семантики предметной
области в терминах субъективных средств описания - сущностей, атрибутов, идентификаторов сущностей, супертипов, подтипов и т.д.
Информационная модель предметной области базы данных содержит следующие основные конструкции:






диаграммы "сущность-связь" (Entity - Relationship Diagrams);
определения сущностей;
уникальные идентификаторы сущностей;
определения атрибутов сущностей;
отношения между сущностями;
супертипы и подтипы.
Внимание! Элементы информационной модели данных предметной области являются
входными данными для решения задачи проектирования базы данных - создания логической модели данных.
СЛАЙД №6
Понятие функциональной модели предметной области базы данных
Вторым ключевым моментом создания ИС с целью автоматизации информационных процессов организации является анализ функционального взаимодействия объектов автомати-
4
зации. Результаты такого анализа многогранны. Аналитики представляют их в виде функциональной модели предметной области базы данных. Функциональная модель предметной области является собирательным понятием. Состав функциональной модели существенно зависит от контекста конкретного ИТ-проекта и может быть представлен посредством довольно
широкого спектра документов в виде текстовой и графической информации. К рассмотрению
таких документов проектировщик баз данных должен подходить с учетом следующих двух положений:


главное назначение ИС является базовым критерием оценки достаточности предоставляемой информации;
функциональная модель предназначена для описания процессов обработки данных
в рамках выделенной предметной области с различных точек зрения.
Описать процессы обработки информации всесторонне с помощью одной описательной модели сложно. В последнее время предпринимаются некоторые успешные попытки разработать
унифицированную модель в рамках объектно-ориентированного анализа и проектирования
(OOA&D) с помощью UML-конструкций. В настоящих лекциях мы основываемся только на результатах структурного анализа предметной области как наиболее прагматичном подходе для
проектирования классических реляционных баз данных. Использование объектноориентированного подхода к проектированию баз данных - это предмет отдельного курса лекций.
Определим функциональную модель предметной области базы данных как совокупность
некоторых моделей, предназначенных для описания процессов обработки информации.
Будем называть эти модели конструкциями функциональной модели. Ниже приведен перечень
основных конструкций функциональной модели, необходимые для выполнения проектирования реляционных баз данных.


Модели процессов:
o бизнес-модель процессов (иерархия функций системы);
o модель потока данных.
Модели состояний:
o модель жизненного цикла сущности;
o набор спецификаций функций системы (требования);
o описание функций системы через сущности и атрибуты;
o бизнес-правила, которые реализуют функции.
Внимание! Элементы информационной модели предметной области являются входными
данными для задачи создания логической модели данных. Элементы функциональной модели
предметной области являются входными данными для задачи проектирования приложений
базы данных и, частично, для задачи создания физической модели базы данных.
СЛАЙД №7
Контроль качества результатов анализа предметной области
Предположим, что проектировщик баз данных получил от аналитиков набор материалов с результатами анализа предметной области базы данных. Задача проектировщика - произвести контроль качества предоставленных результатов анализа в целях обеспечения их полноты
и достоверности.
Первое, что необходимо сделать, - составить перечень полученных документов и проверить,
все ли необходимые документы присутствуют. Проектировщику должны быть представлены:
 Информационная модель предметной области базы данных;
5
 Совокупность частных моделей, которые относятся к функциональной модели предметной
области базы данных;
 Общесистемные требования и решения.
В то же время надо помнить, что не все конструкции могут оказаться нужными для решения
задач проектирования. Так, например, диаграмма потоков данных непосредственно влияет на
принятие решения о числе баз данных, подлежащих реализации в рамках системы. И если уже
решено, что база данных будет одна, то принимать во внимание эту диаграмму не нужно. Также часто обходятся без диаграммы жизненных циклов сущностей и диаграммы состояний.
Второе, далее проектировщик должен классифицировать представленные модели по типам и
для каждой модели проверить выполнение присущих ей правил.
В классической теории баз данных, модель данных есть формальная теория представления и
обработки данных в системе управления базами данных (СУБД), которая включает, по меньшей мере, три аспекта:
1) Аспект структуры: методы описания типов и логических структур данных в базе данных.
Аспект структуры определяет, что из себя логически представляет база данных;
2) Аспект манипуляции: методы манипулирования данными. Аспект манипуляции определяет способы перехода между состояниями базы данных (то есть способы модификации
данных) и способы извлечения данных из базы данных;
3) Аспект целостности: методы описания и поддержки целостности базы данных. Аспект целостности определяет средства описаний корректных состояний базы данных.
Модель данных — это абстрактное, самодостаточное, логическое определение объектов,
операторов и прочих элементов, в совокупности составляющих абстрактную машину доступа к
данным, с которой взаимодействует пользователь. Эти объекты позволяют моделировать
структуру данных, а операторы — поведение данных.
Каждая БД и СУБД строится на основе некоторой явной или неявной модели данных. Все
СУБД, построенные на одной и той же модели данных, относят к одному типу. Например, основой реляционных СУБД является реляционная модель данных, сетевых СУБД — сетевая модель данных, иерархических СУБД — иерархическая модель данных и т.д.
В литературе, статьях и в обиходной речи иногда встречается использование термина «модель
данных» в смысле «схема базы данных» («модель базы данных»). Такое использование является неверным, на что указывают многие авторитетные специалисты, в том числе Кристофер
Дейт. Модель данных есть теория, или средство моделирования, в то время как модель базы
данных (схема базы данных) есть результат моделирования. Соотношение между этими понятиями аналогично соотношению между языком программирования и конкретной программой
на этом языке.
Модели баз данных:


Иерархические базы данных состоит из объектов с указателями от родительских объектов к потомкам, соединяя вместе связанную информацию. Иерархические базы данных могут быть представлены как дерево, состоящее из объектов различных уровней. Верхний
уровень занимает один объект, второй — объекты второго уровня и т. д. Между объектами
существуют связи, каждый объект может включать в себя несколько объектов более низкого уровня. Такие объекты находятся в отношении предка (объект более близкий к корню) к
потомку (объект более низкого уровня), при этом возможно, когда объект-предок не имеет
потомков или имеет их несколько, тогда как у объекта-потомка обязательно только один
предок. Объекты, имеющие общего предка, называются близнецами.
Сетевые К основным понятиям сетевой модели базы данных относятся: уровень, элемент (узел), связь. Узел — это совокупность атрибутов данных, описывающих некоторый
6



объект. На схеме иерархического дерева узлы представляются вершинами графа. В сетевой структуре каждый элемент может быть связан с любым другим элементом. Сетевые базы данных подобны иерархическим, за исключением того, что в них имеются указатели в
обоих направлениях, которые соединяют родственную информацию. Несмотря на то, что
эта модель решает некоторые проблемы, связанные с иерархической моделью, выполнение простых запросов остается достаточно сложным процессом. Также, поскольку логика
процедуры выборки данных зависит от физической организации этих данных, то эта модель
не является полностью независимой от приложения. Другими словами, если необходимо
изменить структуру данных, то нужно изменить и приложение.
Реляционные. Слово «реляционный» происходит от relation (отношение). Для работы с
реляционными БД применяют реляционные СУБД. Использование реляционных баз данных было предложено доктором Коддом из компании IBM в 1970 году. Целью нормализации
(1НФ, 2НФ, 3НФ, НФБК, 4НФ, 5НФ, ДКНФ (доменно-ключевая)) является устранение недостатков структуры базы данных, приводящих к вредной избыточности в данных, которая в
свою очередь потенциально приводит к различным аномалиям и нарушениям целостности
данных.
Многомерные Программное обеспечение OLAP используется при обработке данных из
различных источников. Эти программные продукты позволяют реализовать множество различных представлений данных и характеризуются тремя основными чертами: многомерное
представление данных; сложные вычисления над данными; вычисления, связанные с изменением данных во времени.
Объектно-ориентированные база данных, в которой данные оформлены в виде моделей
объектов, включающих прикладные программы, которые управляются внешними событиями. Результатом совмещения возможностей БД и возможностей ООЯП являются Объектноориентированные системы управления базами данных (ООСУБД). ООСУБД позволяет работать с объектами баз данных также как с объектами в программировании на ООЯП.
ООСУБД расширяет языки программирования, прозрачно вводя долговременные данные,
управление параллелизмом, восстановление данных, ассоциированные запросы и другие
возможности. Объектно-ориентированные базы данных обычно рекомендованы для тех
случаев, когда требуется высокопроизводительная обработка данных, имеющих сложную
структуру.
СЛАЙД №8
3. Проектирование реляционных баз данных.
Цели проектирования
Только небольшие организации могут обобществить данные в одной полностью интегрированной базе данных. Чаще всего администратор баз данных (даже если это группа лиц) практически не в состоянии охватить и осмыслить все информационные требования сотрудников организации (т.е. будущих пользователей системы). Поэтому информационные системы больших
организаций содержат несколько десятков БД, нередко распределенных между несколькими
взаимосвязанными ЭВМ различных подразделений. (Так в больших городах создается не одна,
а несколько овощных баз, расположенных в разных районах.)
Отдельные БД могут объединять все данные, необходимые для решения одной или нескольких прикладных задач, или данные, относящиеся к какой-либо предметной области (например,
финансам, студентам, преподавателям, кулинарии и т.п.). Первые обычно называют прикладными БД, а вторые – предметными БД (соотносящимся с предметами организации, а не с ее
информационными приложениями). (Первые можно сравнить с базами материальнотехнического снабжения или отдыха, а вторые – с овощными и обувными базами.)
 Предметные БД позволяют обеспечить поддержку любых текущих и будущих приложений,
поскольку набор их элементов данных включает в себя наборы элементов данных прикладных БД. Вследствие этого предметные БД создают основу для обработки неформализован-
7
ных, изменяющихся и неизвестных запросов и приложений (приложений, для которых невозможно заранее определить требования к данным). Такая гибкость и приспосабливаемость позволяет создавать на основе предметных БД достаточно стабильные информационные системы, т.е. системы, в которых большинство изменений можно осуществить без
вынужденного переписывания старых приложений.
 Прикладные БД, основывая проектирование текущих и предвидимых приложениях, позволяют существенно ускорить создание высокоэффективной информационной системы, т.е.
системы, структура которой учитывает наиболее часто встречающиеся пути доступа к данным. Поэтому прикладное проектирование до сих пор привлекает некоторых разработчиков. Однако по мере роста числа приложений таких информационных систем быстро увеличивается число прикладных БД, резко возрастает уровень дублирования данных и повышается стоимость их ведения.
Таким образом, каждый из рассмотренных подходов к проектированию воздействует на результаты проектирования в разных направлениях. Желание достичь и гибкости, и эффективности привело к формированию методологии проектирования, использующей как предметный,
так и прикладной подходы. В общем случае:
 Предметный подход используется для построения первоначальной информационной
структуры, а
 Прикладной – для ее совершенствования с целью повышения эффективности обработки
данных.
При проектировании ИС необходимо провести анализ целей этой системы и выявить требования к ней отдельных пользователей (сотрудников организации). Сбор данных начинается с
изучения сущностей организации и процессов, использующих эти сущности. Сущности группируются по «сходству» (частоте их использования для выполнения тех или иных действий) и по
количеству ассоциативных связей между ними (самолет – пассажир, преподаватель – дисциплина, студент – сессия и т.д.). Сущности или группы сущностей, обладающие наибольшим
сходством и (или) с наибольшей частотой ассоциативных связей объединяются в предметные
БД. (Нередко сущности объединяются в предметные БД без использования формальных методик – по «здравому смыслу»). Для проектирования и ведения каждой предметной БД (нескольких БД) назначается АБД, который далее занимается детальным проектированием базы.
Основная цель проектирования БД – это сокращение избыточности хранимых данных, а
следовательно, экономия объема используемой памяти, уменьшение затрат на многократные
операции обновления избыточных копий и устранение возможности возникновения противоречий из-за хранения в разных местах сведений об одном и том же объекте. Так называемый,
«чистый» проект БД («каждый факт в одном месте») можно создать, используя методологию
нормализации отношений. И хотя нормализация должна использоваться на завершающей проверочной стадии проектирования БД, мы начнем обсуждение вопросов проектирования с рассмотрения причин, которые заставили Кодда создать основы теории нормализации.
Надо разбивать универсальное отношение, потому что при использовании такого отношения
возникает несколько проблем:
1. Избыточность. Данные практически всех столбцов многократно повторяются. Повторяются и некоторые наборы данных.
2. Потенциальная противоречивость (аномалии обновления). Вследствие избыточности можно обновить поле в одной строке, оставляя его неизменным в других. Следовательно, при обновлениях необходимо просматривать всю таблицу для нахождения и изменения
всех подходящих строк.
3. Аномалии включения. В БД не может быть записан новый поставщик ("Няринга", Вильнюс,
Литва), если поставляемый им продукт (Огурцы) не используется ни в одном блюде. Можно,
конечно, поместить неопределенные значения в столбцы Блюдо, Вид, Порций и Вес (г) для
8
этого поставщика. Но если появится блюдо, в котором используется этот продукт, не забудем ли мы удалить строку с неопределенными значениями?
4. Аномалии удаления. Обратная проблема возникает при необходимости удаления, т.к. при
удалении могут быть утрачены сведения.
В чем состоит преимущество ориентации на автоматизацию основных бизнес-процессов при
автоматизации организации или предприятия? Традиционно и повсеместно используемым
подходом (особенно на начальных этапах развития информационной инфраструктуры организации) является применение так называемого позадачного метода решения задач автоматизации, направленного на решение достаточно простых и понятных руководству задач. Например,
учет заказов, выписка счетов, подготовка документов.
Конъюнктурное преимущество такого метода очевидно: достаточно быстро может быть получен результат, существование модной ныне ИТ-службы оправдано, внутренние инвестиции
быстро вернулись. В принципе, с точки зрения системного анализа это является порочной
практикой. Однако он существует, поскольку позволяет, с одной стороны, вроде бы не отставать от жизни (наличие ИС в организации зачастую является одним из определяющих факторов ее конкурентоспособности), а с другой - экономить денежные средства на автоматизации.
Вышеуказанный подход позволяет использовать служащих с невысокой квалификацией. Рано
или поздно это становится тормозом в развитии информационной инфраструктуры организации.
Низкая отдача уже существующей ИС организации на текущем этапе ее эксплуатации также
становится тормозящим фактором. Изменение направлений бизнеса организации и ряд других
факторов приводят к вопросу пересмотра отношения к ИС в организации, т.е. к извечному вопросу - переделать или начать с начала. Начать сначала всегда выгодней. Можно применить
уже хорошо отработанные в информатике методики проектирования «сверху-вниз» или «снизувверх». Однако рано или поздно опять встанет вопрос о соответствии требованиям сегодняшнего дня.
Значительная часть проектов в области информационных технологий направлена на разработку и создание информационных систем, в рамках которых осуществляется обработка данных
различной сложности. Целью таких проектов является разработка и создание информационной
системы с базами данных. Практически во всех таких проектах решается задача проектирования баз данных определенного типа. Решение задачи проектирования повышает вероятность
того, что разрабатываемая информационная система будет удовлетворять заданным функциональным и информационным требованиям с учетом заданных ограничений.
СЛАЙД №9
Примеры функциональных требований: выдача отчетов по продажам по регионам; выдача
отчетов по продажам по кварталам; автоматический расчет скидок на товары при увеличении
объема закупаемой партии и т.п.
Примеры ограничений: максимальное время, отпущенное на проект; количество денежных
средств, которое можно на него потратить. Следует также учитывать технологические средства, доступные при реализации проекта, например требование реализации базы данных в архитектуре «файл-сервер».
В эксплуатации база данных и ее окружение должны удовлетворять набору требований по
ряду укрупненных (интегрированных) параметров, таких как:




Функциональность и адаптируемость;
Производительность обработки транзакций;
Пропускная способность;
Время реакции;
9

Безопасность.
Это далеко не полный перечень параметров, по которым выставляются требования к базам
данных, однако он содержит параметры, требования по которым выставляются наиболее часто.
Такие параметры иногда находятся в противоречии друг к другу. Так, высокие требования по
функциональности на данном конкретном оборудовании могут вступать в конфликт с высокими
требованиями по производительности. Например, отчеты могут генерироваться в течение нескольких часов и снизить в это время реакции пользователей, работающих с системой в диалоговом режиме.
СЛАЙД №10
Параметры, выражающие требования к базе данных, могут ранжироваться посредством присвоения приоритетов. Присвоение высшего приоритета требованию создать структуру данных
для достижения системой максимально возможной производительности может привести к тому, что при проектировании базы данных требование обеспечить удобство работы определенной категории пользователей будет рассматриваться через призму производительности.
Например, в системе бронирования авиабилетов в транснациональной авиакомпании время
отклика на запрос не должно превышать 15-30 секунд. Поэтому, если это требование не будет
удовлетворяться, то потребуется «разгрузить» приложение оператора.
Таким образом, процесс проектирования базы данных заключается в достижении компромиссов между функциональными, информационными, аппаратными, архитектурными и
технологическими требованиями к базе данных и строится на информированном принятии
решений по структуре базы данных.
Определение 1. Проектирование базы данных - это поиск способов удовлетворения функциональных требований средствами имеющейся компьютерной технологии с учетом заданных ограничений.
Как правило, ИТ-проекты по созданию базы данных включают в себя следующие этапы: определение стратегии построения системы, анализ требований к базе данных, проектирование
базы данных, реализация базы, тестирование и внедрение базы данных. Этап проектирования базы данных считается одним из самых сложных "размытых" этапов создания базы данных, который не имеет явно выраженного начала и окончания. По сравнению с анализом требований к базе данных или разработкой приложений, проектирование базы данных, по мнению многих ведущих специалистов, является плохо структурированной задачей. Если все этапы создания базы данных перекрываются друг с другом в своей последовательности, то этап
проектирования перекрывается со всеми остальными этапами. Проектирование начинается с
момента принятия стратегических решений и продолжается на этапах реализации и тестирования.
Процесс проектирования базы данных охватывает несколько основных сфер.
 Проектирование объектов базы данных (таблицы, представления, индексы, триггеры, хра-
нимые процедуры, функции, пакеты) для представления данных предметной области в базе
данных.
 Проектирование интерфейса взаимодействия с базой данных (формы, отчеты и т.д.), т.е.
проектирование приложений, которые будут сопровождать данные в базе данных и реализовывать вопросно-ответные отношения на этих данных.
 Проектирование баз данных под конкретную вычислительную среду или информационную технологию (архитектура "клиент-сервер", параллельные архитектуры, распределенная
вычислительная среда).
10
 Проектирование баз данных под назначение системы (интеллектуальный анализ данных,
OLAP, OLTP и т.д.).
Отметим, что приложения работы с базой данных проектируются одновременно с физической
схемой базы данных, а не отдельно! Зачастую вычислительная среда задается в качестве
входных условий проектирования, но иногда проектирование следует проводить с учетом возможного перехода в будущем на другую аппаратную платформу или технологию.
Внимание! Базы данных всегда проектируются под конкретное назначение системы.
Техника проектирования баз данных может измениться в целом и в деталях в зависимости от
назначения системы. Например, следует различать проектирование систем складирования
данных и проектирование так называемых OLTP-систем, ориентируемых на оперативную обработку транзакций. В данном учебном курсе рассматривается проектирование баз данных в
основном для OLTP-систем. Именно на таких системах исторически сложилась техника проектирования баз данных.
СЛАЙД №11
Известно, что база данных:






Имеет свою внутреннюю архитектуру;
Имеет свое собственное лингвистическое содержание;
Действует в рамках некоторой внешней среды;
Имеет свои средства взаимодействия с внешней средой;
Функционирует на конкретной программно-аппаратной платформе;
Поддерживается в рамках определенных организационно-технологических мероприятий.
Таким образом, база данных является сложным многокомпонентным объектом, объединяющим
аппаратное обеспечение, программное обеспечение, информацию в виде данных и персонал.
Основной задачей проектировщика базы данных является обоснованный выбор такой ее
структуры, которая обеспечит согласованное взаимодействие всех ее компонентов согласно
заданным функциональным требованиям в рамках заданных ограничений.
СЛАЙД №12
Мы не будем рассматривать вопросы анализа предметной области. Эта задача предшествует
проектированию базы данных, и решают ее аналитики. Однако проектировщик баз данных
должен знать результаты выполнения этой задачи и уметь правильно интерпретировать их в
ходе проектирования. Результаты анализа предметной области базы данных, а именно модели данных предметной области на семантическом уровне, являются исходными данными
для решения задач проектирования базы данных. Поэтому проектировщик должен знать концепции, лежащие в основе моделирования данных предметной области, и конструкции, образующие совокупность этих моделей.
Процесс проектирования базы данных может быть представлен в виде модели бизнеспроцессов. Обычно проектировщики не создают бизнес-модель процесса проектирования базы
данных. А напрасно! Бизнес-модель процесса проектирования позволяет:




Отобразить субъективное мнение проектировщика баз данных на процесс проектирования
конкретной базы данных;
Учесть особенности ИТ-проекта, в рамках которого проектируется база данных;
Достаточно быстро составить план проектирования конкретной базы данных;
Просчитать длительность проектных работ (создать временную модель проектирования).
11
Рассмотрим типовую бизнес-модель процесса проектирования базы данных. На рис. 3.1 приведена контекстная диаграмма процесса проектирования базы данных.
Рис. 3.1. Контекстная диаграмма процесса проектирования базы данных
Как видно из рисунка, на вход процесса проектирования базы данных подаются:
 Информационная модель предметной области базы данных: диаграммы «сущностьсвязь» (ER-диаграммы);
 Функциональная модель предметной области базы данных: бизнес-модель процессов,
диаграммы потока данных (DF-диаграммы), диаграммы состояний, диаграммы жизненных циклов сущностей, спецификации на системы (требования), бизнес-правила;
 Общесистемные требования и ограничения;
 Задачи обратного влияния.
Могут быть представлены и другие документы.
Примечание. Под задачами обратного влияния здесь понимается совокупность проблем,
которые возникают в процессе разработки приложений базы данных, ее тестирования,
опытной и промышленной эксплуатации и приводят к модификации физической модели базы данных. Примером такой задачи является настройка операторов SELECT с целью увеличения производительности выборки.
На выходе процесса проектирования базы данных формируются следующие результаты:
 Физическая модель базы данных, которая может быть преобразована в скрипт для создания базы данных;
 Физическая база данных;
 Спецификация модулей приложений базы данных;
 План тестирования базы данных.
По требованию может быть разработана и другая документация.
СЛАЙД №13
Такими задачами (этапами) являются:

Сбор и анализ входных данных;
12







Создание логической модели базы данных;
Создание физической модели базы данных: внутренняя схема;
Создание физической модели базы данных: учет влияния транзакций;
Создание серверного кода;
Проектирование модулей приложений базы данных;
Контроль качества проектирования базы данных;
Задачи обратного влияния.
Сбор и анализ входных данных - это начальный этап проектирования, на котором осуществляется сбор и контроль качества результатов анализа предметной области базы данных, готовится план проектирования базы данных.
В ходе контроля качества основными моментами деятельности являются контроль ERдиаграмм и контроль диаграмм функциональной модели предметной области. На основании
ER-диаграмм создается логическая модель реляционной базы данных; на основании диаграмм
функциональной модели разрабатывается серверный код и проектируются модули приложений базы данных.
Важным результатом систематизации является вывод о достаточности требований и реализуемости базы данных. Заказчик должен точно знать, что он получит и чего не получит в результате создания базы данных! Особенно важно указать, чего он не получит. Анализ требований
на реализуемость базы данных в рамках конкретного ИТ-проекта служит основой для принятия
решения менеджером проекта о возможности реализации проекта в целом.
Создание логической модели базы данных - это этап, на котором на основании информационной модели предметной области базы данных создается логическая структура базы данных, независимая от ее реализации.
Результатом проектирования логической модели базы данных является нормализованная схема отношений базы данных. Отметим, что в ходе выполнения этапа создания логической модели базы данных могут быть созданы новые объекты базы данных, не предусмотренные в
информационной модели предметной области, например связывающая сущность при нормализации отношения со степенью связи "многие-ко-многим". Иногда на этом этапе принимается
решение о выборочной денормализации отношений.
Создание физической модели базы данных:
А). Внутренняя схема – это этап, на котором на основании логической модели базы данных
создается физическая структура базы данных, зависимая от ее реализации. На этом этапе выполняется преобразование отношений логической модели реляционной базы данных в команды создания объектов физической базы данных, в результате чего создается так называемая
внутренняя схема базы данных. Дополнительно может быть создана так называемая внешняя
схема базы данных, которая отражает точку зрения пользователей на данные в базе данных.
Полученный скрипт может быть применен для создания физической базы данных.
Основная цель решения этой задачи: преобразовать логическую модель реляционной базы
данных в последовательность команд SQL для создания объектов реляционной базы данных.
Таким образом, проектировщик базы данных отображает отношения логической модели реляционной базы данных (сущности предметной области, представленные в нормализованной
форме на ER-диаграммах) в таблицы и индексы реляционной базы данных.
В). Учет влияния транзакций – это этап, на котором анализируются возможные транзакции
системы, выполняется, в случае необходимости, денормализация отношений для обеспечения
более высокой производительности базы данных. На этом этапе создается скрипт создания
физической базы данных. В результате проектировщик базы данных создает физическую мо-
13
дель базы данных, которая учитывает характер обработки данных в базе данных, выраженный
через учет влияния транзакций.
Следует еще раз отметить субъективный характер принятия решений проектировщиком базы
данных из-за отсутствия во многих случаях точных сведений о характере выполнения транзакций в системе. Большинство решений принимается на основе эвристических правил и личного
опыта проектировщика. Метод работы проектировщика базы данных сводится к изменению
структуры объектов базы данных на основе перебора возможных способов повышения производительности, их сопоставления и обоснованного выбора подходящего решения.
Главная цель этого этапа - видоизменить последовательность команд SQL для создания объектов хранения данных с учетом влияния транзакций на производительность базы данных.
Создание серверного кода – это этап, на котором на основании функциональной модели
предметной области базы данных создается серверный код базы данных в виде триггеров,
хранимых процедур и пакетов. Эти модули создаются проектировщиком базы данных и выполняются сервером.
Профессиональная задача проектирования баз данных - разработка серверного кода базы
данных - возникает, как правило, в многопользовательской вычислительной среде.
В многопользовательских системах пользователи совместно используют вычислительные ресурсы, в частности ресурсы дисковой памяти и оперативной памяти процессора. Вычислительные ресурсы могут быть сконцентрированы в одном месте (централизованные вычисления)
или быть рассредоточенными в различных узлах, объединенных в компьютерную сеть (распределенные вычисления). СУБД в любом случае призвана координировать и осуществлять
доступ пользователей к базам данных и их объектам.
Задача проектирования базы данных - подготовка инсталляционного скрипта для создания
базы данных - в определенной степени завершающая для самостоятельной работы проектировщика базы данных. Такой скрипт - это один из главных результатов его работы.
Проектирование модулей приложений – это этап, на котором создаются спецификации модулей приложений, разрабатываются стратегии тестирования базы данных и приложений, создается план тестирования приложений базы данных и готовятся тестовые данные.
Контроль качества проектирования базы данных заключается в проверке качества результатов проектирования на каждом его этапе.
Учет задач обратного влияния заключается в настройке некоторых транзакций к базе данных и локальном перепроектировании базы данных согласно требованиям, поступающим с
других этапов создания базы данных.
Как правило, последние четыре из сформулированных нами задач решаются в соответствии с
правилами и стандартами, принятыми в конкретной организации.
СЛАЙД №14
4. Технологии и модели вычислений.
Взгляд на использование компьютеров меняется в процессе их применения в различных сферах человеческого труда: большие вычислительные центры с мощными компьютерами, средние по мощности ЭВМ для автоматизации технологических процессов, персональные компьютеры, компьютеры, объединенные сетью коммуникаций. Неизменным остается требование
пользователей к вычислительным ресурсам для удовлетворения потребностей в информации
– время процессора (быстродействие), оперативная память, дисковое пространство и т.п. Про-
14
блема совместного использования ресурсов является одной из ключевых проблем решения
любых прикладных задач на ЭВМ, в том числе и создания ИС. Решение этой проблемы приводит к разработке новых компьютерных технологий, которые являются сложным синтезом изменений в аппаратном и программном обеспечении. Основой таких модификаций как аппаратного, так и программного обеспечения являются модели вычислений.
Что принято понимать под моделью вычислений? Обычно под моделью вычислений подразумевают совокупность аппаратно-программных средств, схему их взаимодействия между собой
и пользователями, т.е. постулируется ответ на вопросы, каким образом и какие вычислительные ресурсы используются в процессе выполнения вычислений. Поскольку понятие модели
вычислений связано как и с аппаратным, так и с программным обеспечением, то нередко в качестве синонима слова модель используется слово архитектура. За всю историю развития вычислительной техники было предложено не так уж много моделей вычислений.
Централизованные вычисления:


Модель вычислений с использованием централизованной хост-ЭВМ;
Модель с автономными персональными вычислениями;
Распределенные вычисления:



Модель вычислений «файл-сервер»;
Модель вычислений «клиент-сервер»;
Модель «вычисление по требованию».
1. Исторически одной из первых моделей вычислений является модель с использованием
централизованной хост-ЭВМ. В такой схеме вычислений пользователь получает доступ к
вычислительным ресурсам ЭВМ через сеть неинтеллектуальных терминалов (т.е. терминалов, не обладающих никакими вычислительными возможностями). Центральный компьютер
полностью отвечает за взаимодействие с пользователем и управление данными в многопользовательской среде.


Преимуществом такой модели вычислений является их централизация. Централизованные системы позволяют совместно использовать вычислительные ресурсы (диски,
принтеры, оперативную память) с высокой эффективностью, а также обеспечивать высокую надежность и актуальность хранимых данных.
Самым большим недостатком такой схемы вычислений является линейная зависимость вычислительной мощности центральной ЭВМ от числа пользователей и, как
следствие, высокая стоимость аппаратуры и программного обеспечения. Несмотря на
устойчивую тенденцию снижения стоимости оборудования, такие системы по-прежнему
остаются одними из дорогостоящих (отношение «цена/производительность» остается
достаточно высокой).
2. В 80-е годы прошлого века появились персональные компьютеры и рабочие станции.
Независимые друг от друга, предоставляющие вычислительные возможности, которые сопоставимы с большими ЭВМ, доступные по цене широкому кругу потребителей (отношение
«цена/производительность» в данном случае гораздо ниже, чем при использовании больших
ЭВМ). Персональные компьютеры положили конец централизованному подходу в обработке
данных и обозначили переход к распределенным вычислениям.


Преимуществом такой модели вычислений является их автономность в использовании вычислительных ресурсов, т.е. централизованное использование компьютера, но на
рабочем месте и независимо от других таких же компьютеров. В данном случае можно
подобрать персональный компьютер адекватно решаемому кругу задач.
Однако у независимых персональных вычислений есть и свои проблемы. Эти проблемы порождают распределенность данных (невозможность совместной работы с данны-
15
ми различных пользователей) по персональным компьютерам в случае, когда эти данные должны использоваться совместно в рамках одной организации. При этом выигрыш
в отношении "цена/производительность" компенсируется потерями в производительности труда коллективов, работающих с распределенными таким образом данными.
Проблемы совместного использования данных, расположенных на персональных компьютерах, привели к разработке концепции локальной вычислительной сети, которая восстанавливает преимущества коллективных вычислений и сохраняет простоту использования персональных компьютеров. Наличие вычислительной сети компьютеров характерно для всех моделей распределенных вычислений.
3. Модель вычислений «файл-сервер» (или архитектура «файл-сервер») основывается на
понятии сервера. Термин сервер имеет двойственный смысл. С одной стороны, сервер есть
узел вычислительной сети (компьютер с сети), предназначенный для предоставления совместно используемых ресурсов и услуг, а с другой - программный компонент, предоставляющий общий функциональный сервис другим программным компонентам вычислительной
сети.
Файловый сервер является обычно центральным узлом сети, на котором хранятся файлы
коллективного пользования и который является также концентратором совместно используемых периферийных устройств (например, принтера или дискового накопителя большой емкости). Файловый сервер не принимает участия в обработке приложения. Он выполняет сетевой транспорт совместно используемых данных (часто пересылая файл целиком конечному пользователю).


Преимуществом такой модели является, несомненно, корпоративное использование
территориально распределенных вычислительных ресурсов, имеющее одним из своих
следствий создание глобальных вычислительных систем и новых технологий обмена
информацией.
Однако у такой модели есть два крупных недостатка при разработке многопользовательских приложений.
 Интенсивный обмен данными (рост трафика сети) приводит к быстрому достижению
ее пропускной способности и тем самым к снижению (из-за увеличения времени
реакции приложения за счет времени ожидания) производительности многопользовательской системы.
 Обеспечение согласованности данных, т.е. одновременного разделения доступа
к одним и тем же данным группой пользователей. Обычно файл блокируется для
других пользователей, когда его начинает обрабатывать приложение. В случае, когда часть файла реплицируется на конечный узел для обработки, снижается актуализация данных, что может быть неприемлемо для систем оперативной обработки
информации.
4. Модель вычислений «клиент-сервер» явилась следующим шагом в развитии распределенных вычислений, объединив в себе преимущества коллективных вычислений в сети компьютеров с доступом к совместно используемым данным и высокие характеристики производительности вычислений с центральной ЭВМ. Основными понятиями данной модели являются сервер баз данных, клиентское приложение и сеть.
Основное назначение сервера баз данных - оптимальное управление разделяемыми ресурсами на уровне данных для множества клиентов. На этом уровне достаточно эффективно решаются задачи обеспечения согласованности данных, их актуальности, защиты и целостности.
Клиентское приложение является частью системы, которая обеспечивает интерфейс приложения с серверов баз данных. Логика приложения может быть полностью реализована на клиентской части системы, а обработку данных забирает на себя сервер баз данных.
16
Сеть и коммуникационное программное обеспечение являются средствами передачи данных.
Реализация этой компоненты модели обеспечивает прозрачность сервера баз данных по отношению к клиенту.
Рис. 1.10. Преимущества и недостатки модели вычислений "клиент-сервер"
Несмотря на то, что модель вычислений "клиент-сервер" является высокопроизводительной
распределенной моделью вычислений, она, помимо очевидных преимуществ, имеет присущие
ей недостатки (рис. 1.10). Кроме того, другие модели вычислений также продолжают развиваться, обеспечивая приемлемые значения отношения "цена-производительность".
5. Модель «вычисления по требованию» или GRID является в настоящее время одной из
перспективных распределенных моделей вычислений. Суть ее состоит в использовании вычислительных ресурсов, расположенных в локальной или глобальной вычислительной сети,
аналогично тому, как мы в быту используем электричество, совершенно не отдавая себе отчета в том, с какой электростанции оно поступает к нам в дом.
В этой модели вычислений заявленные в сети GRID вычислительные ресурсы (компьютеры
или кластеры ЭВМ) предоставляют свои свободные вычислительные ресурсы согласно правилам обслуживания заданий в очереди. Таким образом, находясь в России, вы можете запустить свою задачу на компьютере в Австралии, совершенно об этом не зная.
В этой лекции мы рассмотрели ряд основных понятий и терминов, которые потребуются проектировщику реляционных баз данных в процессе решения им своих профессиональных задач. В
последующих лекциях мы последовательно и детально рассмотрим основные профессиональные задачи проектировщика реляционных баз данных.
6. Пиринговые системы (peer-to-peer, P2P) – это такие компьютерные сети, в которых не используется классическая схема клиент-сервер, разделяющая множество всех узлов на два
подмножества – серверов и клиентов. В пиринговой сети все узлы "равны" в том смысле, что
каждый из них по отношению к другому (другим) может выполнять функции как клиента, так
и сервера. Эти сети называют еще одноранговыми.
17
Возникновение пиринговых сетей связано с тремя факторами.
1. Процессор обычной клиентской машины мало загружен. Особенно в офисах, где машины используются преимущественно для подготовки документов, для набора текстов и
т.п. То же касается и подавляющего большинства домашних компьютеров.
2. Многие пользователи хранят на своих компьютерах коллекции файлов (тексты статей
определенной тематики, художественные фотографии и др.), которые могут быть интересны и другим пользователям. Но при этом владельцы этих коллекций не готовы сделать свой компьютер полноценным сервером в сети из-за его недостаточной мощности,
необходимости круглосуточной работы, финансовых и других причин.
3. Определенная часть пользователей хотела бы более активно участвовать в «общественной жизни» сети, не ограничиваясь обсуждением различных вопросов на форумах
и в чатах. Они готовы участвовать в каком-либо полезном "общем деле".
Пиринговые сети разнообразны. Основной целью одних является обмен музыкальными и видео файлами. В других реализуются проекты поиска лекарства от рака, третьи тренируются во
взломе известных шифров на основе распределенных вычислений, четвертые ищут внеземные цивилизации на основе данных, получаемых с радиотелескопов.
С математической точки зрения пиринговая сеть может быть представлена графом неопределенного вида: нет какой-либо стандартной архитектуры сети (например, звезды или кольца).
Более того, этот граф – динамический, так как отдельные пользователи включаются в сеть и
выходят из ее состава в произвольные моменты времени. Любой пользователь, играющий
роль сервера, в любой момент времени может превратиться в клиента на некоторый отрезок
времени. Но может и пребывать одновременно в положении и сервера и клиента.
Исследования в области пиринговых сетей начались в связи с успешным функционированием
таких систем как Napster, Gnutella и Freenet
СЛАЙД №15
5. Распределенные информационные системы.
В одной из своих статей в 2001 году Дж. Бэкус отметил, что компьютерная революция испытала три волны. Первая волна началась с коммерциализацией кремниевых чипов и продолжалась 10-15 лет. Вторая волна связана с развитием технологий программного обеспечения и
началась приблизительно в середине 80-х годов XX века. Третья волна началась в конце 90-х
годов XX века и связана с развитием сетей и использованием их для коммуникаций компьютеров.
Третья волна послужила источником последующего бума информационных технологий. Рост
технологических возможностей привел к тому, что компьютерные устройства стали значительно меньше по размерам и быстрее.
В последние годы появилось несколько новых направлений компьютерных исследований. В
самостоятельную дисциплину оформляется сетевой компьютинг, разработка распределенных систем.
В основе технологий распределенных систем лежат удаленный доступ, высокая степень доступности ресурсов, устойчивость к сбоям и отказам, удаленное взаимодействие пользователей.
В настоящее время развитие распределенных и параллельных систем стимулируется такими
задачами как информационный поиск и создание механизмов индексирования для поисковых
машин, обеспечение мобильного мультимедиа, построение мультиагентных интеллектуальных
систем, хранение терабайтных и пентабайтных массивов данных, обработка естественных
18
языков, исследования в биоинформатике. Традиционные задачи моделирования в науке и технике, как и раньше, требуют все больших мощностей.
Эти задачи выдвигают требования к компьютерным системам, которые не могут быть удовлетворены в рамках просто "высокопроизводительных вычислений", например, с помощью параллельных суперкомпьютеров.
Архитектура Грид. Одним из новых направлений в распределенных системах, в рамках которых есть надежда продвинуться вперед в удовлетворении перечисленных требований, является Grid computing – обработка информации в суперсетях (Грид).
В основе Грида лежат (в дополнение к распределенному компьютингу) федеративное объединение сообществ пользователей (без жесткой централизации), виртуализация ресурсов, стандартизация, маскирование неоднородности условий работы.
Под сообществом или виртуальной организацией понимается множество распределенных в
сети ресурсов, управляемых по одним и тем же правилам; можно понимать также некоторую
область администрирования. Виртуализация означает, что ресурсы в сообществе представлены так, что скрыто их местонахождение и принадлежность (правило не без исключений).
Стандартизация означает, что федерация построена на открытых стандартах, протоколах и
интерфейсах. Маскирование неоднородностей означает, что программное обеспечение промежуточного уровня в Грид должно обеспечить "стирание различий" между программными
обеспечениями промежуточного уровня виртуальных организаций.
Можно написать условную "формулу":
Грид компьютинг = распределенный компьютинг + {федеративное объединение сообществ, виртуализация, стандартизация, маскирование неоднородностей}
Грид отличается от Интернета (точнее, его службы WWW) прежде всего тем, что поддерживает
не только работу с распределенной информацией, но и использование распределенных вычислительных мощностей для выполнения приложений пользователей.
Грид характеризуется огромным (а часто, неопределенным) количеством взаимодействующих
однородных и неоднородных компьютеров. Неоднородных – не только с аппаратной точки зрения, но и работающих с разными программными платформами, разными языковыми средствами.
Конечно, гораздо меньше проблем было бы, если бы все процессоры были одинаковы, а приложения функционировали на одной программной платформе. Но это линия развития суперкомпьютеров, супердорогих и относительно малочисленных в мире. Она существует и пока никуда не исчезает. Суперкомпьютеры – это "мамонты", но, возможно, они не вымрут. Суперкомпьютеры используются там, где они нужны относительно малому числу пользователей для решения сложных задач. На сегодня – это оборонные задачи (системы ПВО), задачи прогноза
погоды и др.
Суперкомпьютеры мало доступны массовому пользователю, кроме тех случаев, когда суперкомпьютер (обычно, принадлежащий крупному научному центру) включается в Грид.
Надо заметить, что многие современные вычислительные комплексы, подпадающие под понятие "суперкомпьютер", строятся по кластерной схеме, т.е. их архитектуры движутся в сторону
распределенных систем.
19
Грид привлекателен тем, что его почти не надо создавать – он вырастает сам. Это объективная реальность, как говорят философы. Только его рост нужно направлять, культивируя положительные изменения и своевременно предупреждая проблемы. Но для этого нужен план.
Грид требует переосмысления применяемых вычислительных моделей, средств их поддержки.
Здесь недостаточно традиционных постулатов "открытых систем" – обеспечения интероперабельности систем управления различными ресурсами, масштабируемости и проч. Эти постулаты не теряют своего значения. Но требуется создание новых абстракций, языков программирования, средств поддержки для того, чтобы Грид был более эффективным.
Для динамического и адаптивного распределения ресурсов и управления ресурсами требуется
развитие новых моделей и методов. Причем эти методы должны учитывать, что, одновременно, и сами приложения, пользующиеся этими ресурсами, изменяются в процессе работы.
Что касается конечного пользователя, то ему требуется определенная унификация в доступе к
различным ресурсам Грид, несмотря на их разнородность и принадлежность многообразным
собственникам.
Распределенные системы и Грид используют несколько уровней децентрализации данных и
управления для того, чтобы адаптироваться к требованиям приложения. Децентрализация касается пространственного (географического) распределения, доступности данных, надежности
хранения и использования, а также способов вычисления и коммуникации.
Приведенные выше требования предполагают высокую степень "прозрачности", при которой
нижние уровни реализации скрыты, а на уровне приложения используются только значимые
для этого уровня концепции.
Следуя традиционному построению распределенных систем, можно описать архитектуру Грид,
состоящую из четырех слоев:
1. Пользовательские интерфейсы, приложения и среда решения задач (problem-solving
envieronment).
2. Средства разработки, программные модели, языки программирования.
3. Промежуточное программное обеспечение (middleware) Грид: управление ресурсами;
фиксация информации и ее обнаружение; программное обеспечение безопасности; доступ к памяти; различные службы (вычислительные и коммуникационные).
4. Неоднородные ресурсы и инфраструктура сетей.
В настоящее время не существует единой модели вычислений в Гриде. Однако можно выделить несколько типичных задач, которые должны решать пользователи. Это – запуск и выполнение заданий, управление данными, формирование потоков работ (workflow), работа в режиме on-line при совместных проектах и др.
Эти приложения требуют большей, чем имеется сегодня, стандартизации и унификации интерфейсов для достижения интеграции отдельных служб и обеспечения координации в работе.
Они требуют развития и поддержки концепции виртуальных ресурсов, ресурсов – данных и ресурсов – вычислительных мощностей.
Мобильный компьютинг. Самостоятельным направлением является мобильный компьютинг.
В его основе (в дополнение к распределенному компьютингу) лежат:
1. Сети, обеспечивающие подключение к ним в любой географической точке (сотовые
и проч.);
2. Мобильный доступ к информации (возможность получения информации при перемещении пользователя),
20
3. Адаптивность приложений,
4. Чувствительность к местоположению,
5. Энергонезависимость систем.
Грид и мобильный компьютинг – это параллельные линии развития. Они не совпадают, поскольку базируются на разных моделях пользователя. В Гриде – это пользователь, находящийся в одном из узлов решетки (grid – решетка, в переводе с английского), и имеющий возможность унифицированным образом использовать ресурсы (информационные, вычислительные), находящиеся в любых доступных в данный момент узлах решетки. Под доступностью понимается согласие владельцев этих узлов, поскольку физическая доступность обеспечена
априори. Решетка – топологическое образование: расстояния между узлами, как правило, не
имеют значения.
В мобильном компьютинге другая модель пользователя. Это человек, движимый своими целями и перемещающийся в пространстве. Среда (сеть) обеспечивает перемещение сервисов,
необходимых пользователю, вслед за ним. Эти сервисы, по преимуществу, информационные
(по крайней мере, в настоящее время). Географический аспект, расстояния играют в мобильном компьютинге важную роль. Они являются частью характеристик среды.
Тотальный компьютинг. Английский термин pervasive computing обозначает проникающий,
распространяющийся повсюду, всеобъемлющий, глубоко влияющий (компьютинг). Тотальный
компьютинг ставит во главу угла конечного пользователя, который должен получать вычислительное обслуживание непрерывно, 24 часа в сутки, 7 дней в неделю, причем обслуживание
самого разного рода – от научных вычислений до управления кухонными агрегатами.
М.Сатьянараян формулирует четыре новые области исследований в дополнение к областям
мобильного компьютинга, вместе с ним образующие область тотального компьютинга:
1. Эффективное использование персонального умного пространства, имея в виду
окружающие нас на работе, в транспорте, дома устройства с компьютерным управлением, необходимыми датчиками и исполнительными механизмами;
2. Невидимость (умного пространства) – минимальное отвлечение внимания пользователя на управление окружающими вещами;
3. Местная масштабируемость; имеется в виду обычное в программном обеспечении понятие масштабируемости с поправкой на то, что она должна иметь место для любой
точки персонального умного пространства, обладающей вычислительными ресурсами:
любая точка должна быть сделана настолько "мощной", насколько это необходимо
пользователю.
4. Маскирование неоднородностей; под неоднородностью понимаются различия как в
техническом плане (называемые, обычно, гетерогенностью), так и не технические – организационные структуры, бизнес-процессы, экономические факторы.
К этому можно еще добавить знание контекста. Т.е. пользователь существует в персональном
умном пространстве не "вслепую", а представляя себе, сознавая контекст. В некотором отношении это противоречит невидимости, однако, на самом деле, должен существовать разумный
баланс между невидимостью и знанием контекста.
Подытоживая написанное выше, можно привести следующую «формулу»:
тотальный компьютинг = мобильный компьютинг + {персональное умное пространство,
невидимость, местная масштабируемость, маскирование неоднородностей}
Распределенные вычисления традиционно следуют модели клиент-сервер. Вслед за этим и
Грид следует такой же модели. В парадигме тотального компьютинга все субъекты вычислений
могут быть равны. Они равные: посылают запросы и выполняют сервисы. В отличие от клиентсерверной модели технология "равный с равным" (peer-to-peer, P2P) стала интенсивно разви-
21
ваться относительно недавно. Технология P2P является перспективной и может стать альтернативой традиционным Web-сервисам.
Объединение направлений компьютинга Грид и тотального компьютинга сулит в будущем создание глобального умного пространства:
Глобальное умное пространство = Грид компьютинг + тотальный компьютинг
Оно отличается тем, что пространство становится уже не персональным (хотя, ближнее окружение, подпространство остается) как в тотальном компьютинге, а глобальным. В нем действует уже не один пользователь, а множество пользователей, каждый со своим персональным
подпространством. Но технические, технологические, информационные "барьеры" между подпространствами отсутствуют. Это не означает полной открытости. Любой пользователь может
применить для охраны своего пространства от несанкционированного доступа средства компьютерной безопасности. Правда, они тоже должны "поумнеть" по сравнению с современными
средствами информационной безопасности. Это еще одна перспективная задача.
Если перейти от моделей конечных пользователей к задачам, стоящим перед программистами
распределенных систем, то можно отметить все возрастающую важность программного обеспечения промежуточного уровня (middleware). Оно важно и для Грида и для тотального компьютинга. Многие считают, что middleware – это ключ к следующему поколению компьютинга.