Информационные системы с базами данных

Итерационная процедура построения информационных систем

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

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

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

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

Разработчики ИС фактически всегда находятся в методике "из-середины" (midlle of design). Есть некоторая основа (уже созданная или создаваемая), и вокруг нее следует развиваться в различных направлениях, не сильно ломая сложившиеся традиции. Таким образом, постулируется итерационный подход в разработке и создании информационных систем. И, как следует из вышесказанного, он определяется не желанием теоретиков ИС, а жизненной необходимостью.

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

Что является основной особенностью технологии реализации итерационного подхода разработки и сопровождения ИС? Основная особенность реализации концепции разработки ИС, ориентированной на интегрированные процессы, - это наличие или отсутствие сборочного конвейера, поскольку необходимо собирать воедино многие технологические процессы обработки информации. При объединении технологических процессов обработки информации увеличивается скорость прохождения информации в системе, принятие решений на основе информационных потоков становится частью процесса обработки информации (и более состоятельной), уменьшается иерархия управленческих структур.

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

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

Концепция баз данных

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

Основные подходы к обработке информации в автоматизированных информационных системах

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

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

Торжество концепции независимости программ от данных привело к формированию в 1962 году концепции базы данных (БД) и созданию на ее основе метода баз данных для решения задач обработки информации. До середины 60-х годов прошлого века основной концепцией построения программного обеспечения являлась концепция файловой системы и так называемый позадачный метод. Такой подход по-прежнему остается доминирующим в разработке и функционировании несущих операционных платформ. В конце 80-х годов прошлого века была предложена концепция объектно-ориентированных баз данных и объектно-ориентированный подход разработки программ на основе обработки событий. На рис. 1.3 представлены основные черты для каждой из указанных выше концепций. На рис. 1.4 проведено сопоставление основных методов обработки данных.

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

Концепция баз данных

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

Что же принято понимать под базой данных? Базу данных в общем случае можно определить как унифицированную совокупность хранимых и воспроизводимых данных, используемых в рамках организации (Engles R.A., 1972 г.). Однако понятие базы данных не основывается в настоящее время на единой концепции, скорее это целое семейство связанных между собой понятий из предметной области, программного и аппаратного обеспечения, анализа и моделирования данных и приложений. Мы дадим несколько определений базы данных.

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

Такое деление средств манипулирования данными и их представления является в определенной степени условным. Язык определения данных служит для описания логической структуры (схемы) БД, а в некоторых случаях и способов хранения и доступа к данным. Язык манипулирования данными предоставляет алгоритмические средства построения приложений для обработки сохраняемых в БД элементов данных.

Системы управления базами данных

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

Однако после признания концепции БД прошло почти четыре года, прежде чем в 1966 году была создана первая СУБД. На рис. 1.5 представлены основные функции СУБД.

Модели данных

Понятие о модели данных

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

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

Что же такое модели данных? В самом общем случае модель данных - это логическое представление данных и совокупность операций над ними.

Можно рассмотреть несколько аспектов моделирования в обработке данных:

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

Информационная модель данных

На рис. 1.6 иллюстрируется общее содержание понятия модели данных, сложившееся к настоящему времени.

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

Концепция трех схем

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

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

Исследовательская группа по СУБД ANSI/X3/SPARC пришла к выводу, что для создания идеальной среды управления данными необходимо определение их с третьей, промежуточной точки зрения (концепция трех схем ANSI/X3/SPARC ). Эта точка зрения (называемая концептуальной схемой) сводится к единообразному определению данных в рамках предметной области, не ориентированному на какое-либо конкретное использование их и не зависящему от того, как данные физически обрабатываются на компьютере (рис. 1.7).

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

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

Основные типы моделей и их эквивалентность

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

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

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

Общие принципы классификации СУБД

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

Так, СУБД CDS/ISIS в первую очередь ориентирована на поддержку работы с документом, который состоит из определенного числа рубрик, проиндексированных по тезаурусу ключевых слов. СУБД ADABAS хорошо подходит для организации фактографических БД, а СУБД ORACLE - для БД смешанного типа. Во избежание несуразностей с использованием определенной модели данных, БД, за редким исключением, целесообразно классифицировать по типу используемой модели в СУБД. Отметим, что классификация БД далеко не завершенная область исследований: попытки ввести новые типы БД продолжаются (активные, дедуктивные, нечеткие реляционные, графические БД и т.д.).

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

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

Обзор основных моделей данных

Тремя основными типами моделей структурированных данных являются иерархическая, сетевая и реляционная. Первые две из них основаны на представлении информации об объектах в виде плоского графа.

Иерархическая модель

Иерархическая модель данных организует данные в виде древовидной структуры и является реализацией логических связей между данными типа родовидовых отношений или отношений "часть-целое". Примером простого иерархического представления может служить административная структура организации.

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

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

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

Между исходным узлом и порожденными узлами по условию модели существует связь "один-ко-многим" (или "многие-к-одному").

Иерархия должна удовлетворять следующим условиям:

К основным недостаткам иерархической модели можно отнести:

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

Предположим, что каждый преподаватель может читать несколько дисциплин, а каждый студент также может изучать несколько дисциплин.

Один из возможных вариантов построения иерархической модели может быть таковым. Корневым узлом является студент (Номер студента, ФИО, Номер группы). Для каждого студента при данном представлении имеется экземпляр корневого узла. Преподаватель и дисциплина объединяются в один порожденный узел (Табельный номер преподавателя, ФИО, Ученое звание, Кафедра, Дисциплина, Дата экзамена, Оценка, Зачет).

При такой организации данных достаточно легко получать ответы на запросы типа "выдать информацию о сдаче экзаменов студентами по различным дисциплинам". Однако при ответе на вопрос, какие преподаватели принимают экзамены по ВТ, необходимо просмотреть все записи порожденных узлов для каждого корневого узла. Для этого вопроса более подходит модель, в которой корневым узлом является преподаватель (Табельный номер преподавателя, ФИО, ученое звание, кафедра), а порожденным является студент (номер студента, ФИО, номер группы, дисциплина, дата сдачи, оценка, зачет).

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

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

Первопричиной этих проблем является то обстоятельство, что иерархическая модель не поддерживает отношение M:N.

Основной единицей обработки здесь является запись, к которой применимы операции ЗАПОМНИТЬ, МОДИФИЦИРОВАТЬ, УДАЛИТЬ, ИЗВЛЕЧЬ, НАЙТИ. В операциях создания и уничтожения связей для этой модели нет необходимости потому, что все связи предопределены заранее древовидной структурой отношений. Операция "найти" сводится к одной из трех процедур обхода дерева.

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

Сетевая модель данных

Остановимся на понятии сетевой структуры, положенной в основу сетевой модели данных. Рассмотрим отношение между следующими объектами: Студенческий коллектив, Студенческая группа, Комната в общежитии и Студент. Взаимосвязь между этими объектами не является иерархической, так как порожденный элемент Студент имеет два исходных - Студенческая группа и Комната в общежитии. Такие отношения, когда порожденный элемент имеет более одного исходного, описываются в виде сетевой структуры. В такой структуре любой элемент может быть связан с любым другим элементом.

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

Рассмотрим, как в сетевой модели будут представлены взаимосвязи между объектами. В нашем примере присутствуют два вида взаимосвязей: 1:M (Учебная группа - Студент) и M:1 (Студент - Комната в общежитии). Сетевые структуры, которые имеют такие связи между исходными и порожденными узлами, порожденными и исходными узлами, относят к простым сетевым структурам. Сложной сетевой структурой называют такую структуру, в которой присутствует хотя бы одна связь типа N:M. Примером такой связи является отношение Студент - Преподаватель. Такое разделение сетевых структур обусловлено технологическими сложностями реализации взаимосвязи N:M. Причем некоторые СУБД не обрабатывают сложных сетевых структур ( СЕТОР, DNS, DBMS ).

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

Набор данных имеет следующие свойства:

Необходимо различать тип и экземпляр набора. Предварительно поясним различие между понятиями "тип" и "экземпляр" записи. Например, Студент является типом записи, а строка, содержащая информацию о конкретном студенте, является экземпляром типа записи Студент. Аналогичное различие существует между типом и экземпляром набора данных. Например, тип набора Состав группы, а его экземпляр содержит один экземпляр типа записи владельца Учебная группа и N экземпляров типа записи-члена Студент. Определенный экземпляр типа записи-члена не может одновременно принадлежать более чем одному экземпляру типа записи-владельца. Уникальность владельца типа набора является обязательным элементом сетевой модели данных. С этой точки зрения иерархическая модель является частным случаем сетевой модели данных.

Концепция сетевой модели данных связана с именем Ч. Бахмана, известного специалиста в области обработки данных, который оказал определяющее влияние на создание проекта DBTG CODASYL (1971 год). Сетевая модель данных является моделью объектов-связей, где допускаются только бинарные связи типа "многие-к-одному", что позволяет использовать для представления данных простую модель ориентированных графов. В некоторых определениях сетевой модели допускаются связи типа "многие-ко-многим", но требование бинарности связи остается в силе.

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

Для моделирования представления данных в сетевой модели используются следующие элементы данных:

На рис. 1.9 приведен фрагмент описания схемы БД (описание статьи записи) на примере записи из БД "Кадры", предназначенной для автоматизации работы отдела кадров организации. Для описания записи используется язык описания данных СODASYL. Описание схемы БД в CODASYL состоит из четырех статей:

Элементы данных сетевой модели допускают обработку следующими операциями, множество которых составляет язык манипулирования данными:

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

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

Модели вычислений

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

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

Централизованные вычисления:

Распределенные вычисления:

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

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

Самым большим недостатком такой схемы вычислений является линейная зависимость вычислительной мощности центральной ЭВМ от числа пользователей и, как следствие, высокая стоимость аппаратуры и программного обеспечения. Несмотря на устойчивую тенденцию снижения стоимости оборудования, такие системы по-прежнему остаются одними из дорогостоящих (отношение "цена/производительность" остается достаточно высокой).

В 80-е годы прошлого века появились персональные компьютеры и рабочие станции. Независимые друг от друга, предоставляющие вычислительные возможности, которые сопоставимы с большими ЭВМ, доступные по цене широкому кругу потребителей (отношение "цена/производительность" в данном случае гораздо ниже, чем при использовании больших ЭВМ). Персональные компьютеры положили конец централизованному подходу в обработке данных и обозначили переход к распределенным вычислениям.

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

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

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

Модель вычислений "файл-сервер" (или архитектура "файл-сервер") основывается на понятии сервера. Термин сервер имеет двойственный смысл. С одной стороны, сервер есть узел вычислительной сети (компьютер с сети), предназначенный для предоставления совместно используемых ресурсов и услуг, а с другой - программный компонент, предоставляющий общий функциональный сервис другим программным компонентам вычислительной сети.

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

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

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

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

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

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

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

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

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

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

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

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

Литература: [1], [2], [10], [12], [21], [29], [34], [36], [40], [41], [47].