2. ПРОЕКТИРОВАНИЕ АРХИТЕКТУРЫ БАЗЫ ДАННЫХ ДЛЯ ХРАНЕНИЯ ПАРАМЕТРОВ ФУНКЦИОНИРОВАНИЯ (ИНФО)ТЕЛЕКОММУНИКАЦИОННОГО ОБОРУДОВАНИЯ
2.1. Составные компоненты систем управления базами данных для хранения информации
В современных информационных системах информация обычно хранится с использованием автоматизированных банков данных. Банки данных могут быть очень большими и могут содержать разную информацию, используемую организацией.
Банк данных – это информационная система коллективного пользования, обеспечивающая централизованное хранение данных, их обновление и выдачу по запросам пользователей. Это комплекс аппаратного и программного обеспечения банка данных и персонала, обслуживающего его. Банк данных включает:
1. одну или несколько баз данных;
2. систему управления базами данных (СУБД);
3. персонал, обеспечивающий работу банка данных.
База данных – это совокупность определенным образом организованных данных, хранящихся в запоминающих устройствах ЭВМ. Обычно данные хранятся на жестком диске сервера организации.
В общем случае данные в базе данных (по крайней мере, в больших системах) являются интегрированными и разделяемыми. Эти два аспекта, интеграция и разделение данных, представляют собой наиболее важные преимущества использования банков данных на “большом” оборудовании и, по меньшей мере, один из них— интеграция — является преимуществом их применения и на “малом” оборудовании.
Под понятием интеграции данных подразумевается возможность представить базу данных как объединение нескольких отдельных файлов данных, полностью или частично исключающее избыточность хранения информации.
Под понятием разделяемости данных подразумевается возможность использования несколькими различными пользователями отдельных элементов, хранимых в базе данных. Имеется в виду, что каждый из пользователей сможет получить доступ к одним и тем же данным, возможно, даже одновременно (параллельный доступ). Такое разделение данных, с параллельным или последовательным доступом, частично является следствием того факта, что база данных имеет интегрированную структуру.
Одним из следствий упомянутых выше характеристик базы данных (интеграции и разделяемости) является то, что каждый конкретный пользователь обычно имеет дело лишь с небольшой частью всей базы данных, причем обрабатываемые различными пользователями части могут произвольным образом перекрываться. Иначе говоря, каждая база данных воспринимается ее различными пользователями по–разному. Фактически, даже те два пользователя базы данных, которые работают с одними и теми же частями базы данных, могут иметь значительно отличающиеся представления о них.
База данных характеризуется моделью данных, т. е. формой организации данных в ней. По типу модели данных БД делятся на сетевые, иерархические и реляционные. В настоящее время практически применяется только реляционная структура, в которой база данных состоит из одной или нескольких двумерных таблиц. Каждая реляционная таблица представляет собой двумерный массив и обладает следующими свойствами:
• каждый элемент таблицы — один элемент данных
• все ячейки в столбце таблицы однородные, то есть все элементы в столбце имеют одинаковый тип (числовой, символьный и т. д.)
¬ каждый столбец имеет уникальное имя
¬ одинаковые строки в таблице отсутствуют
¬ порядок следования строк и столбцов может быть произвольным
Такая модель хранения данных обеспечивает удобство использования базы данных на ЭВМ. Учитывая, что таблицы базы данных могут быть связаны определенными отношениями, такая модель обеспечивает целостность данных и отсутствие избыточности хранения. Поэтому она и используется в большинстве современных баз данных.
Система управления базами данных (СУБД) — специализированная программа или комплекс программ, предназначенная для организации и ведения базы данных. Она обеспечивает хранение данных и взаимодействие пользователя с БД, позволяя пользователям производить поиск, сортировку и выборку информации в базе данных, а некоторым пользователям – добавлять, удалять и изменять записи в БД. В зависимости от того, с какой базой данных работает СУБД, она может быть:
¬– иерархической
¬– сетевой
¬– реляционной
¬– объектно–реляционной
¬– объектно–ориентированной
Мы будем рассматривать реляционные системы управления базами данных.
Персонал, обеспечивающий работу банка данных, это администратор банка данных, а также инженеры и техники, обеспечивающие работу аппаратного обеспечения банка данных.
Таким образом, система управления базами данных является необходимой составной частью банка данных.
СУБД обычно содержит следующие компоненты:
¬– ядро, которое отвечает за управление данными во внешней и оперативной памяти,
¬– процессор языка базы данных, обеспечивающий оптимизацию запросов на извлечение и изменение данных и создание, как правило, машинно–независимого исполняемого внутреннего кода,
¬ подсистему поддержки времени исполнения, которая интерпретирует программы манипуляции данными, создающие пользовательский интерфейс с СУБД
¬ сервисные программы (внешние утилиты), обеспечивающие ряд дополнительных возможностей по обслуживанию информационной системы.
В связи с этим можно сформулировать основную функцию СУБД:
1. Определение данных.
СУБД должна предоставлять средства определения данных в виде исходной формы (схемы данных) и преобразования этих определений в соответствующую объектную форму. То есть СУБД преобразовывает данные в форму, необходимую для хранения их в базе данных.
2. Манипулирование данными.
СУБД должна быть способна обрабатывать запросы пользователя на выборку, изменение или удаление данных, уже существующих в базе, или на добавление в нее новых данных. То есть, СУБД обеспечивает интерфейс между пользователями и базами данных.
3. Управление хранением данных и доступом к ним.
СУБД осуществляет программную поддержку хранения данных в запоминающем устройстве ЭВМ и управляет всеми действиями, производимыми с данными.
4. Защита и поддержка целостности данных
СУБД должна контролировать пользовательские запросы и определять, кому доступны операции изменения данных, а кому доступны только операции получения данных. Также она следит за целостностью данных, хранящихся в БД. СУБД осуществляет журнализацию изменений, резервное копирование и восстановление базы данных после сбоев.
Таким образом, основная функция системы управления базами данных – осуществление интерфейса пользователя и базы данных. Большинство современных крупных банков данных рассчитаны на работу нескольких пользователей, поэтому СУБД осуществляет разделение времени между пользователями при одновременном их доступе к базе данных, а также разделение полномочий между разными типами пользователей. Например, бухгалтер на предприятии может только получать информацию из банка данных, а главный экономист может вносить изменения в банк данных.
СУБД выполняет эти функции с помощью определенного информационно–логического языка, или языка запросов. В большинстве СУБД для этого используется язык SQL.
СУБД реляционного типа освобождает пользователя от необходимости знать форматы хранения данных, методы доступа и методы управления памятью. Изменение физической структуры базы данных не влияет на работоспособность прикладных программ, работающих с нею.
По степени универсальности различают два класса СУБД:
¬– системы общего назначения;
¬– специализированные системы.
СУБД общего назначения не ориентированы на какую–либо предметную область или на информационные потребности какой–либо группы пользователей. Каждая система такого рода реализуется как программный продукт, способный функционировать на некоторой модели компьютеров в определенной операционной системе и поставляется многим пользователям как коммерческое изделие. Такие СУБД обладают средствами настройки на работу с конкретной базой данных. Специализированные СУБД создаются в редких случаях при невозможности или нецелесообразности использования СУБД общего назначения.
2.2. Уровни архитектуры ANSI/SPARC
Первая попытка создания стандартной терминологии и общей архитектуры СУБД была предпринята в 1971 году группой, называемой DBTG, которая признала необходимость использования двухуровневого подхода, построенного на основе использования системного представления – схемы, и пользовательских представлений –. подсхем. Сходные терминология и архитектура были предложены в 1975 году Комитетом планирования стандартов и норм Национального Института Стандартизации США (ANSI/SPARC), который признал необходимость использования трехуровневого подхода. Цель трехуровневой архитектуры заключается в отделении пользовательского представления базы данных от ее физического представления. Ниже перечислено несколько причин, по которым желательно выполнять такое разделение.
–Каждый пользователь должен иметь возможность обращаться к одним и тем же данным, используя свое собственное представление о них, должен иметь возможность изменять свое представление о данных, причем это изменение не должно оказывать влияния на других пользователей.
–Пользователи не должны непосредственно иметь дело с такими подробностями физического хранения данных в базе, как индексирование и хеширование.
–Внутренняя структура базы данных не должна зависеть от таких изменений физических аспектов хранения информации, как переключение на новое устройство хранения.
–АБД должен иметь возможность изменять концептуальную или глобальную структуру базы данных без какого–либо влияния на всех пользователей.
–Администратор базы данных (АБД)– должен иметь возможность изменять структуру хранения данных в базе, не оказывая влияния на пользовательские представления.
–Уровень, на котором воспринимают данные пользователи, называется внешним уровнем, тогда как СУБД и операционная система воспринимают данные на внутреннем уровне. Именно на внутреннем уровне данные реально сохраняются с использованием всех тех структур и файловой организации. Концептуальный уровень представления данных предназначен для отображения внешнего уровня на внутренний и обеспечения необходимой независимости друг от друга.
–Внешний уровень – представление базы данных с точки зрения пользователей. Этот уровень описывает ту часть базы данных, которая относится к каждому пользователю.
–Внешний уровень состоит из нескольких различных внешних представлений базы данных. Внешнее представление содержит только те сущности, атрибуты и связи «реального мира», которые интересны пользователю.
Помимо этого, различные представления могут по–разному отображать одни и те же данные. Некоторые представления могут включать производные или вычисляемые данные, которые не хранятся в базе данных как таковые, а создаются по мере надобности. Представления могут также включать комбинированные или производные данные из нескольких объектов.
–Концептуальный уровень – обобщающее представление базы данных. Этот уровень описывает то, какие данные хранятся в базе данных, а также связи, существующие между ними.
–Промежуточный концептуальный уровень содержит логическую структуру всей базы данных. Фактически, это полное представление требований к данным со стороны организации, которое не зависит от любых соображений относительно способа их хранения. На концептуальном уровне представлены следующие компоненты:
–все сущности, их атрибуты и связи;
–накладываемые на данные ограничения;
–семантическая информация о данных;
–информация о мерах обеспечения безопасности и поддержки целостности данных.
–Концептуальный уровень поддерживает каждое внешнее представление, в том смысле, что любые доступные пользователю данные должны содержаться (или могут быть вычислены) на этом уровне. Однако этот уровень не содержит никаких сведений о методах хранения данных.
Внутренний уровень – физическое представление базы данных в компьютере. Этот уровень описывает, как информация хранится в базе данных.
–Внутренний уровень описывает– физическую реализацию базы данных и предназначен для достижения оптимальной производительности и обеспечения экономного использования дискового пространства. Он содержит описание структур данных и организации отдельных файлов, используемых для хранения данных в запоминающих устройствах. На этом уровне осуществляется взаимодействие СУБД с методами доступа операционной системы с целью размещения данных на запоминающих устройствах, создания индексов, извлечения данных и т.д. На внутреннем уровне хранится следующая информация:
–распределение дискового пространства для хранения данных и индексов;
–описание подробностей сохранения записей;
–сведения о размещении записей;
–сведения о сжатии данных и выбранных методах их шифрования.
–Ниже внутреннего уровня находится физический уровень, который контролируется операционной системой, но под руководством СУБД.
–Физический уровень доступа к данным ниже СУБД состоит только из известных операционной системе элементов.
Общее описание базы данных называется схемой базы данных. Существует три различных типа схем базы данных, которые определяются а соответствии с уровнями абстракции трехуровневой архитектуры, как показано на рисунке 1. На самом высоком уровне имеется несколько внешних схем или подсхем, которые соответствуют разным представлениям данных. На концептуальном уровне описание базы данных называют концептуальной схемой, а на самом низком уровне абстракции — внутренней схемой.
–Концептуальная схема – описывает все элементы данных и связи между ними, с указанием необходимых ограничений поддержки целостности данных. Для каждой базы данных имеется только одна концептуальная схема. На нижнем уров¬не находится внутренняя схема, которая является полным описанием внутренней модели данных.
–Она содержит определения хранимых записей, методы представления, описания полей данных, сведения об индексах и выбранных схемах хеширования. Для каждой базы данных существует только одна внутренняя схема.
–СУБД отвечает за установление соответствия между этими тремя типами схем, а также за проверку их непротиворечивости. Иначе говоря, СУБД должна убедиться в том, что каждую внешнюю схему можно вывести на основе концептуальной схемы. Для установления соответствия между любыми внешней и внутренней схемами СУБД должна использовать информацию из концептуальной схемы. Концептуальная схема связана с внутренней схемой посредством концептуально внутреннего отображения. Оно позволяет СУБД найти фактическую запись или набор записей на физическом устройстве хранения, которые образуют логическую запись в концептуальной схеме, с учетом любых ограничений, установленных для выполняемых над данной логической записью операций, также позволяет обнаружить любые различия в именах объектов, именах атрибутов, порядке следования атрибутов, их типах данных и т.д. Наконец, каждая внешняя схема связана с концептуальной схемой с помощью внешне концептуального отображения. С его помощью СУБД может отображать имена пользовательского представления на соответствующую часть концептуальной схемы.
–Эти внешние представления сливаются воедино в одном концептуальном представлении. СУБД поддерживает внешне концептуальное отображение. Затем концептуальный уровень отображается на внутренний уровень, который содержит физическое описание структуры записи концептуального представления. На этом уровне определение структуры формулируется на языке высокого уровня. Эта структура содержит указатель, который позволяет физически связать все записи в единую цепочку. Порядок полей на внутреннем уровне отличается от порядка атрибутов, принятого на концептуальном уровне. Таков механизм, с помощью которого СУБД осуществляет концептуально внутреннее отображение.
–Важно различать описание базы данных и саму базу данных. Описанием базы данных является схема базы данных. Схема создается в процессе проектирования базы данных, причем предполагается, что она изменяется достаточно редко. Однако содержащаяся в базе данных информация может меняться часто. Совокупность информации, хранящейся в базе данных в любой определенный момент времени, называется состоянием базы данных. Следовательно, одной и той же схеме базы данных может соответствовать множество ее различных состояний. Схема базы данных иногда называется содержанием базы данных, а ее состояние — детализацией.
Рисунок 15 – ¬Реализация независимости от данных в трехуровневой архитектуре ANSI–SPARC
Независимость от данных.
–Основным назначением трехуровневой архитектуры является обеспечение независимости от данных, которая означает, что изменения на нижних уровнях никак не влияют на верхние уровни. Различают два типа независимости от данных: логическую и физическую.
–Логическая независимость от данных – логическая независимость от данных означает полную защищенность внешних схем от изменений, вносимых в концептуальную схему.
–Такие изменения концептуальной схемы, как добавление или удаление новых сущностей, атрибутов или связей, должны осуществляться без необходимости внесения изменений в уже существующие внешние схемы или переписывания прикладных программ. Ясно, что пользователи, для которых эти изменения предназначались, должны знать о них, но очень важно, чтобы другие пользователи даже не подозревали об этом.
–Физическая независимость от данных – физическая независимость от данных означает защищенность концептуальной схемы от изменений, вносимых во внутреннюю схему.
–Такие изменения внутренней схемы, как использование различных файловых систем или структур хранения, разных устройств хранения, модификация индексов или хеширование, должны осуществляться без необходимости внесения изме¬нений в концептуальную или внешнюю схемы.
–Принятое в архитектуре ANSI–SPARC двухэтапное отображение может сказываться на эффективности работы, но при этом оно обеспечивает более высокую независимость от данных. Для повышения эффективности в модели ANSI–SPARC допускается использование прямого отображения внешних схем на внутренние, без обращения к концептуальной схеме. Однако это снижает уровень независимости от данных, поскольку при каждом изменении внутренней схемы потребуется внесение определенных изменений во внешнюю схему и все зависящие от нее прикладные программы.
2.3. Архитектура многопользовательских систем управления базами данных для хранения параметров функционирования (инфо)телекоммуникационного оборудования
Приложения и информационные системы, актуальные для современного уровня развития технологий, могут похвастаться достижением настолько сложного и высокого уровня развития, что применение к ним термина «архитектура» уже давно никого не удивляет.
К сегодняшнему дню известно огромное количество понятий определения «архитектура информационной системы». Рассмотрим определение данного понятия из разных источников:
Архитектура представляет собой организационную структуру системы[1].
Архитектура информационной системы является концепцией, определяющей модель, структуру, выполняемые функции и взаимосвязь составных частей информационной системы.
Архитектура представляет собой базовую организация системы, воплощенную в ее компонентах, их отношениях между собой и с окружением, а также принципы, определяющие проектирование и развитие системы[3].
Архитектура является набором значимых решений по поводу организации системы программного обеспечения; набором структурных элементов и их интерфейсов, при помощи которых компонуется система, вместе с их поведением, которое определяется во взаимодействии между этими элементами; компоновкой элементов в постепенно укрупняющиеся подсистемы, а также стилем архитектуры, направляющим эту организацию – элементы и их интерфейсы, взаимодействия и компоновку[4].
Архитектура программы или компьютерной системы – это структура или структуры системы, которые включают элементы программы, видимые извне свойства этих элементов и связи между ними.
Архитектуру информационной системы можно рекурсивно разобрать на части, которые взаимодействуют при помощи интерфейсов, связи, которые соединяют части, и условия сборки частей. Части, которые взаимодействуют через интерфейсы, включают классы, компоненты и подсистемы.
Архитектура программного обеспечения системы или набора систем состоит из всех важных проектных решений по поводу структур программы и взаимодействий между этими структурами, которые составляют системы. Проектные решения обеспечивают желаемый набор свойств, которые должна поддерживать система, чтобы быть успешной. Проектные решения предоставляют концептуальную основу для разработки системы, ее поддержки и обслуживания.
Хотя определения несколько отличаются, можно заметить немалую степень сходства. Например, большинство определений указывают на то, что архитектура связана со структурой и поведением, а также только со значимыми решениями, может соответствовать некоторому архитектурному стилю, на нее влияют заинтересованные в ней лица и ее окружение, она воплощает решения на основе логического обоснования.
Под архитектурой программных систем будем понимать совокупность решений относительно:
– организации программной системы;
– выбора структурных элементов, составляющих систему и их интерфейсов;
– поведения этих элементов во взаимодействии с другими элементами;
– объединение этих элементов в подсистемы;
– архитектурного стиля, определяющего логическую и физическую организацию системы: статические и динамические элементы, их интерфейсы и способы их объединения.
Архитектура программной системы охватывает не только ее структурные и поведенческие аспекты, но и правила ее использования и интеграции с другими системами, функциональность, производительность, гибкость, надежность, возможность повторного применения, полноту, экономические и технологические ограничения, а также вопрос пользовательского интерфейса.
По мере развития программных систем все большее значение приобретает их интеграция друг с другом с целью построения единого информационного пространства предприятия. Как можно видеть из вышеприведенных определений интеграция является важнейшим элементом архитектуры.
Для того чтобы построить правильную и надежную архитектуру и грамотно спроектировать интеграцию программных систем необходимо четко следовать современным стандартам в этих областях. Без этого велика вероятность создать архитектуру, которая неспособна развиваться и удовлетворять растущим потребностям пользователей ИТ. В качестве законодателей стандартов в этой области выступают такие международные организации как SEI (Software Engineering Institute), WWW (консорциум World Wide Web), OMG (Object Management Group), организация разработчиков Java – JCP (Java Community Process), IEEE (Institute of Electrical and Electronics Engineers) и другие[.
Рассмотрим классификацию программных систем по их архитектуре:
¬– Централизованная архитектура;
¬– Архитектура «файл–сервер»;
¬– Двухзвенная архитектура «клиент–сервер»;
¬– Многозвенная архитектура «клиент–сервер»;
¬– Архитектура распределенных систем;
¬– Архитектура Веб–приложений;
¬– Сервис–ориентированная архитектура.
Необходимо иметь в виду тот факт, что, равно как и любую другую, приведенную классификацию нельзя назвать абсолютной. Так, в архитектуре некоторой ИС зачастую очевидны элементы влияния нескольких разных архитектурных взглядов.
Принято считать, что первой структурой организации работы информационной системы была архитектура файл–сервер. Такая архитектура осуществляет только извлечение информации из файлов базы данных и передачу ее клиенту для последующей обработки.
Усложнение решения задач, повсеместное распространение персональных компьютеров и вычислительных сетей способствовало становлению архитектуры файл–сервер. Технология файл–сервер обеспечивает назначение одного из компьютеров, состоящих в сети, в качестве выделенного сервера. На нем впоследствии и хранятся файлы базы данных.
Файлы, отобранные в соответствии с запросами пользователей, передаются напрямую с сервера на рабочие станции пользователей. После этого, на рабочих станциях пользователей реализуется основная часть обработки информации. В такой технологии центральный сервер является в большинстве случаев только хранилищем файлов, который при этом не участвует в обработке самой информации (Рисунок 1)
Рисунок 16 –¬ Архитектура «файл–сервер»
Работа построена следующим образом:
База данных в виде набора файлов находится на жестком диске специально выделенного компьютера (файлового сервера).
Существует локальная сеть, состоящая из клиентских компьютеров, на каждом из которых установлены СУБД и приложение для работы с БД.
На каждом из клиентских компьютеров пользователи имеют возможность запустить приложение. Используя предоставляемый приложением пользовательский интерфейс, он инициирует обращение к БД на выборку/обновление информации.
Все обращения к БД идут через СУБД, которая инкапсулирует внутри себя все сведения о физической структуре БД, расположенной на файловом сервере.
СУБД инициирует обращения к данным, находящимся на файловом сервере, в результате которых часть файлов БД копируется на клиентский компьютер и обрабатывается, что обеспечивает выполнение запросов пользователя (осуществляются необходимые операции над данными).
При необходимости (в случае изменения данных) данные отправляются назад на файловый сервер с целью обновления БД.
Результат СУБД возвращает в приложение.
Приложение, используя пользовательский интерфейс, отображает результат выполнения запросов[11].
В рамках архитектуры « файл–сервер « были выполнены первые версии популярных так называемых настольных СУБД, таких, как dBase и Microsoft Access.
В литературе указываются следующие основные недостатки данной архитектуры:
1. При одновременном обращении множества пользователей к одним и тем же данным производительность работы резко падает, т.к. необходимо дождаться пока пользователь, работающий с данными, завершит свою работу. В противном случае возможно затирание исправлений, сделанных одними пользователями, изменениями других пользователей.
2. Вся тяжесть вычислительной нагрузки при доступе к БД ложится на приложение клиента, так как при выдаче запроса на выборку информации из таблицы вся таблица БД копируется на клиентскую машину и выборка осуществляется на клиенте. Таким образом, неоптимально расходуются ресурсы клиентского компьютера и сети. В результате возрастает сетевой трафик и увеличиваются требования к аппаратным мощностям пользовательского компьютера.
3. Как правило, используется навигационный подход, ориентированный на работу с отдельными записями.
4. В БД на файл–сервере гораздо проще вносить изменения в отдельные таблицы, минуя приложения, непосредственно из инструментальных средств (например, из утилиты Database Desktop фирмы Borland для файлов Paradox и dBase); подобная возможность облегчается тем обстоятельством, что фактически у таких СУБД база данных – понятие более логическое, чем физическое, поскольку под БД понимается набор отдельных таблиц, сосуществующих в отдельном каталоге на диске. Все это позволяет говорить о низком уровне безопасности – как с точки зрения хищения и нанесения вреда, так и с точки зрения внесения ошибочных изменений.
5. Недостаточно развитый аппарат транзакций служит потенциальным источником ошибок в плане нарушения смысловой и ссылочной целостности информации при одновременном внесении изменений в одну и ту же запись.
6. Использование технологии «клиент – сервер» предполагает наличие некоторого количества компьютеров, объединенных в сеть, один из которых выполняет особые управляющие функции (является сервером сети).
Так, архитектура « клиент – сервер « разделяет функции приложения пользователя (называемого клиентом) и сервера. Приложение–клиент формирует запрос к серверу, на котором расположена БД, на структурном языке запросов SQL (Structured Query Language), являющемся промышленным стандартом в мире реляционных БД. Удаленный сервер принимает запрос и переадресует его SQL–серверу БД. SQL–сервер – специальная программа, управляющая удаленной базой данных. SQL–сервер обеспечивает интерпретацию запроса, его выполнение в базе данных, формирование результата выполнения запроса и выдачу его приложению–клиенту. При этом ресурсы клиентского компьютера не участвуют в физическом выполнении запроса; клиентский компьютер лишь отсылает запрос к серверной БД и получает результат, после чего интерпретирует его необходимым образом и представляет пользователю. Так как клиентскому приложению посылается результат выполнения запроса, по сети «путешествуют» только те данные, которые необходимы клиенту. В итоге снижается нагрузка на сеть. Поскольку выполнение запроса происходит там же, где хранятся данные (на сервере), нет необходимости в пересылке больших пакетов данных. Кроме того, SQL–сервер, если это возможно, оптимизирует полученный запростаким образом, чтобы он был выполнен в минимальное время с наименьшими накладными расходами. Архитектура системы представлена на Рисунке 2[13].
Все это повышает быстродействие системы и снижает время ожидания результата запроса. При выполнении запросов сервером существенно повышается степень безопасности данных, поскольку правила целостности данных определяются в базе данных на сервере и являются едиными для всех приложений, использующих эту БД. Таким образом, исключается возможность определения противоречивых правил поддержания целостности. Мощный аппарат транзакций, поддерживаемый SQL–серверами, позволяет исключить одновременное изменение одних и тех же данных различными пользователями и предоставляет возможность откатов к первоначальным значениям при внесении в БД изменений, закончившихся аварийно.
Рисунок 17 – ¬ Архитектура «клиент – сервер»
Итак, в результате работа построена следующим образом:
База данных в виде набора файлов находится на жестком диске специально выделенного компьютера (сервера сети).
СУБД располагается также на сервере сети.
Существует локальная сеть, состоящая из клиентских компьютеров, на каждом из которых установлено клиентское приложение для работы с БД.
На каждом из клиентских компьютеров пользователи имеют возможность запустить приложение. Используя предоставляемый приложением пользовательский интерфейс, он инициирует обращение к СУБД, расположенной на сервере, на выборку/обновление информации. Для общения используется специальный язык запросов SQL, т.е. по сети от клиента к серверу передается лишь текст запроса.
СУБД инкапсулирует внутри себя все сведения о физической структуре БД, расположенной на сервере.
СУБД инициирует обращения к данным, находящимся на сервере, в результате которых на сервере осуществляется вся обработка данных и лишь результат выполнения запроса копируется на клиентский компьютер. Таким образом СУБД возвращает результат в приложение.
Приложение, используя пользовательский интерфейс, отображает результат выполнения запросов.
Рассмотрим, как выглядит разграничение функций между сервером и клиентом.
Функции приложения–клиента:
– Посылка запросов серверу.
– Интерпретация результатов запросов, полученных от сервера.
– Представление результатов пользователю в некоторой форме (интерфейс пользователя).
Функции серверной части:
– Прием запросов от приложений–клиентов.
– Интерпретация запросов.
– Оптимизация и выполнение запросов к БД.
– Отправка результатов приложению–клиенту.
– Обеспечение системы безопасности и разграничение доступа.
– Управление целостностью БД.
– Реализация стабильности многопользовательского режима работы.
В архитектуре «клиент – сервер» работают так называемые «промышленные» СУБД. Промышленными они называются из–за того, что именно СУБД этого класса могут обеспечить работу информационных систем масштаба среднего и крупного предприятия, организации, банка. К разряду промышленных СУБД принадлежат MS SQL Server, Oracle, Gupta, Informix, Sybase, DB2, InterBase и ряд других.
Как правило, SQL–сервер обслуживается отдельным сотрудником или группой сотрудников (администраторы SQL–сервера). Они управляют физическими характеристиками баз данных, производят оптимизацию, настройку и переопределение различных компонентов БД, создают новые БД, изменяют существующие и т.д., а также выдают привилегии (разрешения на доступ определенного уровня к конкретным БД, SQL–серверу) различным пользователям.
Рассмотрим основные достоинства данной архитектуры по сравнению с архитектурой «файл–сервер»:
1. Существенно уменьшается сетевой трафик.
2. Уменьшается сложность клиентских приложений (большая часть нагрузки ложится на серверную часть), а, следовательно, снижаются требования к аппаратным мощностям клиентских компьютеров.
3. Наличие специального программного средства – SQL–сервера – приводит к тому, что существенная часть проектных и программистских задач становится уже решенной.
4. Существенно повышается целостность и безопасность БД[17].
К числу недостатков можно отнести более высокие финансовые затраты на аппаратное и программное обеспечение, а также то, что большое количество клиентских компьютеров, расположенных в разных местах, вызывает определенные трудности со своевременным обновлением клиентских приложений на всех компьютерах–клиентах. Тем не менее, архитектура « клиент – сервер « хорошо зарекомендовала себя на практике, в настоящий момент существует и функционирует большое количество БД, построенных в соответствии с данной архитектурой.
Как правило, части сети не являются равноправными полностью: некоторые обладают доступом к различным ресурсам (например – сканер, матрица, СУБД и др.), другие же обладают возможностью обращения к таким ресурсам.
Технология «клиент–сервер» представляет собой архитектуру программного комплекса, внутри которой осуществляется распределение прикладной программы по двум логически различным компонентам (клиент и сервер), которые взаимодействуют согласно схеме «запрос–ответ» и решают некоторые задачи (рисунок 18).
Рисунок 18 – ¬ Архитектура «Клиент – сервер»
Компьютер или программный продукт, который управляет и владеет некоторым ресурсом, называется сервером этого некоторого ресурса.
Клиентом называют такой компьютер или программу, который запрашивает и использует некоторый ресурс.
Сервер и клиент могут располагаться как на одном компьютере, так и на разных компьютерах, соединенных сетью. Кроме того, возможно возникновение такой ситуации, когда некая программа или их блок будут одновременно реализовывать функции сервера по отношению по отношению к одному блоку и функции клиента по отношению к другому.
Основной принцип технологии «Клиент–сервер» заключается в разделении функций приложения как минимум на три группы:
¬- модули интерфейса с пользователем;
Группа модулей интерфейса с пользователем также может быть названа логикой представления. Посредством взаимодействия с логикой представления пользователи могут успешно работать с приложением. Вне зависимости от определенных характеристик модулей интерфейса с пользователем, их задача состоит в обеспечении средств для максимально эффективного и оперативного обмена данными между пользователем и системой.
¬- модули хранения данных;
Группу модулей хранения данных также можно назвать бизнес–логикой. Модули хранения данных определяют конкретное предназначение приложения. Разделение приложения по границам между программами обеспечивает естественную основу для распределения приложения на нескольких компьютерах.
¬- модули обработки данных (функции управления ресурсами);
Данная группа также именуется логикой доступа к данным или алгоритмами доступа к данным. Алгоритмы доступа к данным исторически рассматривались как специфический для конкретного приложения интерфейс к механизму постоянного хранения данных наподобие файловой системы или СУБД. При помощи модулей обработки данных организуется специфический для приложения интерфейс к СУБД. При помощи интерфейса приложение управляет соединениями с базой данных и запросами к ней (перевод специфических для конкретного приложения запросов на язык SQL, получение результатов и перевод этих результатов обратно в специфические для конкретного приложения структуры данных)[20].
Каждая из перечисленных групп может быть претворена в жизнь вне зависимости от остальных. Так, не осуществляя изменения программ, применяемых для хранения и обработки данных, можно реализовать изменения интерфейса с пользователем таким образом, что одна и та же информация будет отображаться в виде таблиц, графиков или гистограмм. Очень простые приложения часто способны собрать все три части в единственную программу, и подобное разделение соответствует функциональным границам.
В соответствии с разделением функций в любом приложении можно выделить следующие компоненты:
¬- компонент представления данных;
¬- прикладной компонент;
¬- компонент управления ресурсом[21].
В классической архитектуре клиент–сервер приходится распределять три основные части приложения по двум физическим модулям. Обычно прикладной компонент располагается на сервере (например, сервере базы данных), компонент представления данных – на стороне клиента, а компонент управления ресурсом распределяется между клиентской и серверной частями. В этом заключается основной недостаток классической двухуровневой архитектуры.
В двухзвенной архитектуре при разбиении алгоритмов обработки данных разработчики должны иметь полную информацию о последних изменениях, внесенных в систему, и понимать эти изменения, что создает большие сложности при разработке клиент–серверных систем, их установке и сопровождении, поскольку необходимо тратить значительные усилия на координацию действий разных групп специалистов. В действиях разработчиков часто возникают противоречия, а это тормозит развитие системы и вынуждает изменять уже готовые и проверенные элементы.
Чтобы избежать несогласованности различных элементов архитектуры были созданы две модификации двухзвенной архитектуры «Клиент – сервер»: «Толстый клиент» («Тонкий сервер») и «Тонкий клиент» («Толстый сервер»).
В данных архитектурах разработчики попытались выполнять обработку данных на одной из двух физических частей – либо на стороне клиента («Толстый клиент»), либо на сервере («Тонкий клиент).
Каждый подход имеет свои недостатки. В первом случае неоправданно перегружается сеть, потому что по ней передаются необработанные, а значит, избыточные данные. Кроме того, усложняется поддержка системы и ее изменение, так как замена алгоритма вычислений или исправление ошибки требует одновременной полной замены всех интерфейсных программ, а иначе могут возникнуть ошибки или несогласованность данных. Если же вся обработка информации выполняется на сервере, то возникает проблема описания встроенных процедур и их отладки. Систему с обработкой информации на сервере абсолютно невозможно перенести на другую платформу (ОС), что является серьезным недостатком[22].
Есди все–таки разрабатывается двухуровневая классическая архитектура «Клиент – сервер», то необходимо помнить, что архитектура «Толстый сервер» аналогична архитектуре «Тонкий клиент» (Рисунок 19).
Рисунок 19 ¬¬¬– ¬ Архитектура «Тонкий клиент»
Передача запроса от клиента на сервер, обработка запроса сервером и передача результата клиенту. При этом архитектуры имеют следующие недостатки:
¬– усложняется реализация, так как языки типа SQL не приспособлены для разработки подобного ПО и нет хороших средств отладки;
¬– производительность программ, написанных на языках типа SQL, значительно ниже, чем созданных на других языках, что имеет важное значение для сложных систем;
¬– программы, написанные на СУБД–языках, обычно работают недостаточно надежно; ошибка в них может привести к выходу из строя всего сервера баз данных;
¬– получившиеся таким образом программы полностью непереносимы на другие системы и платформы.
¬– архитектура «Тонкий сервер» аналогична архитектуре «Толстый клиент».
Обработка запроса происходит на стороне клиента, то есть происходит передача клиенту всех необработанных данных с сервера. При этом архитектуры имеют следующие недостатки:
¬ — усложняется обновление ПО, поскольку его замену нужно производить одновременно по всей системе;
¬- усложняется распределение полномочий, так как разграничение доступа происходит не по действиям, а по таблицам;
¬- перегружается сеть вследствие передачи по ней необработанных данных;
¬ — слабая защита данных, поскольку сложно правильно распределить полномочия.
Трехуровневая архитектура «клиент–сервер».
С середины 90–х годов прошлого века признание специалистов получила трехзвенная архитектура «Клиент – сервер», которая разделила информационную систему по функциональным возможностям на три отдельных компонента: логика представления, бизнес–логика и логика доступа к данным. В отличие от двухзвенной архитектуры в трехзвенной появляется дополнительное звено – сервер приложений, который предназначен для осуществления бизнес–логики, при этом полностью разгружается клиент, который направляет запросы промежуточному программному обеспечению, и максимально используются все возможности серверов[25].
В технологии трехуровневой архитектуры, как правило, клиент не перегружается функциями обработки информации, а только реализует свою основную функцию – является системой представления данных, поступающих с сервера приложений. Подобный интерфейс может быть реализован при помощи стандартных методов и средств Web–технологии, таких как браузер, CGI и Java.
Такой подход позволяет уменьшить объем данных, которые передаются от сервера к клиенту и обратно, а это, в свою очередь, предоставляет возможность подключения клиентских компьютеров даже по медленным линиям (например, по телефонным каналам). Помимо всего прочего, клиентская часть может быть так просто организована, что в большинстве случаев возможна ее организация при помощи самого простого браузера.
Это также предоставляет возможность быстрого и безболезненного внесения всех необходимых изменений в клиентскую часть, если это станет необходимо.
Сервер приложений – это программное обеспечение, которое является промежуточным слоем между клиентом и сервером (Рисунок 20).
Рисунок 20 – Сервер приложений
Существует несколько категорий продуктов промежуточного слоя:
¬- Message orientated – яркие представители MQseries и JMS;
¬- Object Broker – яркие представители CORBA и DCOM;
¬- Component based – яркие представители.NET и EJB.
Использование сервера приложений дает больше возможностей, например, уменьшается нагрузка на клиентские компьютеры, потому что сервер приложений распределяет нагрузку и обеспечивает защиту от сбоев. Так как бизнес–логика хранится на сервере приложений, то при каких–либо изменениях в отчетности или расчетах клиентские программы никоим образом не затрагиваются.
Существует несколько серверов приложений от таких знаменитых компаний как Sun Microsystem, Borland, IBM, Oracle и каждый из них отличается набором предоставляемых сервисов (производительность в данном случае учитывать не будем). Эти сервисы облегчают программирование и развертывание приложений масштаба предприятия. Обычно сервер приложений предоставляет следующие сервисы:
¬ WEB Server – чаще всего включают в поставку самый популярный и мощный Apache;
¬ WEB Container – позволяет выполнять JSP и сервлеты. Для Apache таким сервисом является Tomcat;
¬ CORBA Agent – может предоставлять распределенную директорию для хранения CORBA объектов;
¬ Messaging Service – брокер сообщений;
¬ Transaction Service – уже из названия понятно, что это сервис транзакций;
¬ JDBC – драйвера для подключения к базам данных, ведь именно серверу приложений придется общаться с базами данных и ему нужно уметь подключаться к используемой в вашей компании базе;
¬ Java Mail – данный сервис может предоставлять сервис к SMTP;¬
¬ JMS (Java Messaging Service) – обработка синхронных и асинхронных сообщений;
¬ RMI (Remote Method Invocation) – вызов удаленных процедур[28].
Многоуровневые клиент–серверные системы достаточно легко можно перевести на Web–технологию – для этого достаточно заменить клиентскую часть универсальным или специализированным браузером, а сервер приложений дополнить Web–сервером и небольшими программами вызова процедур сервера. Для разработки этих программ можно использовать как Common Gateway Interface (CGI), так и более современную технологию Java.
В трехуровневой системе в качестве каналов связи между сервером приложений и СУБД можно использовать более скоростные линии, которые потребуют минимальных затрат, так как сервера обычно находятся в одном помещении (серверной) и не будет перегружать сеть из–за передачи большого количества информации.
Из всего вышесказанного можно сделать вывод, что двухуровневая архитектура сильно уступает многоуровневой архитектуре, поэтому в настоящее время используется только многоуровневая архитектура «Клиент – сервер», в которой различают три модификации – RDA, DBS и AS