Архитектура информационных систем. Структурированный язык запросов SQL

    Содержание: 

    Введение 3

1. Архитектура файл-сервер 4
2. Архитектура клиент-сервер 8
3. Многоуровневая архитектура 10

Заключение 15

Список использованной литературы 16 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

    ВВЕДЕНИЕ

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

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

    Целью реферата является рассмотрение структурированного языка запросов SQL, при помощи которого разрабатываются базы данных для системы клиент-сервер.

    Задачами  реферата является рассмотрение:

    архитектуры информационной системы, и в частности  клиент-сервер;

    языков  запросов SQL и QBE, и их сравнение;

    принципов разработки приложений архитектуры  клиент-сервер при помощи SQL.

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

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

    1. Архитектура файл-сервер

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

    Рисунок 1 Структура информационной системы  с файл-сервером 

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

    - трудности при обеспечении непротиворечивости  и целостности данных;

    - существенная загрузка локальной  сети передаваемыми данными;

    - в целом, невысокая скорость  обработки и представления информации;

    - высокие требования к ресурсам  компьютеров. При этом возникают  следующие ограничения.

    - невозможность организации равноправного  одновременного доступа; пользователей  к одному и тому же участку  базы данных;

    - количество одновременно работающих с системой пользователей не превышает пяти человек для ЛВС, построенной в соответствии со спецификацией 1 OBaseT (скорость обмена данными до 10Мб/с);

    При всем этом система обладает одним  очень важным преимуществом - низкой стоимостью.

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

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

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

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

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

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

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

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

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

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

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

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

    2. Архитектура клиент-сервер

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

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

    Для создания и управления персональными  базами данных и приложений, работающих с ними, используются СУБД, такие  как Access и Visual FoxPro фирмы Microsoft, Paradox фирмы Borland.

    Корпоративная база данных создается, поддерживается и функционирует под управлением  сервера баз данных, например Microsoft SQL Server. В зависимости от размеров организации и особенностей решаемых задач ИС может иметь одну из следующих конфигураций: компьютер-сервер, содержащий корпоративную и персональную базы; компьютер-сервер и персональные компьютеры с ПБД; несколько компьютеров-серверов и персональных компьютеров с ПБД.

    Использование архитектуры клиент-сервер дает возможность постепенного наращивания ИС предприятия, во-первых, по мере развития предприятия; во-вторых, по мере развития самой ИС.

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

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

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

    Рисунок 2. Структура информационной системы  с клиент-сервером

    3. Многоуровневая архитектура

    В основу работы Базы Данных (БД) в системе заложен принцип многоуровневой архитектуры, который заключается в реализации двух основных принципов:

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

    - освобождение сервера БД от несвойственных ему функций.

    На  практике эти принципы реализуются  введением в систему дополнительного звена -- сервера приложений.

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

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

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

    - повышение производительности системы за счет переноса части функциональности на аппаратно выделенные сервера приложений;

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

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

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

    В рамках определенных требований мы приходим к необходимости построения ИС, поддерживающей ЭБ, на основе пятиуровневой архитектуры. На каждом уровне реализовывается отдельный вид обработки данных:  

    Многоуровневая  архитектура 

    - хранилище данных (ХД) -- набор зарегистрированных баз данных, структура которых задана в системе регистрации данных;

    - базовые информационные структуры (БИС), объединение которых составляет содержание коллекций;

    - провайдер данных (ПД) -- приложение, обеспечивающее обработку унифицированных именованных запросов к коллекция и формирование ``внутреннего представления документа'' (ВПД);

    - обработчик ВПД -- формирует унифицированные именованные запросы к коллекции и отбор информации в ВПД;

    - формирование ``презентационного представления документа'' (ППД) в соответствии с выбранным стилем -- приложение, которое осуществляет визуализацию документа в удобном для пользователя виде, а также пользовательский интерфейс, с которого вводятся параметры запроса.

    Данная  архитектура обеспечивает взаимодействие служб:

    - публикации данных, поддержка и их аутентичности и качества;

    - поиска и представления информации;

    - анализа распределенных данных.

    - поддержку интероперабельности в глобальной программно-аппаратной инфраструктуре;

    - поддержку диспетчеризации, включая идентификацию доступных ресурсов, статистика использования и загрузки ресурсов и пр.;

    - поддержку системы безопасности и контроля доступа, в т.ч. гибкое регулирование объема прав и привилегий пользователей;

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

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

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

    ЗАКЛЮЧЕНИЕ

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

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

    При этом возникают следующие ограничения:

    - невозможность организации равноправного  одновременного доступа пользователей  к одному и тому же участку базы данных;

    - количество одновременно работающих  с системой пользователей не  превышает пяти человек для  ЛВС;

    - невысокая скорость обработки  и представления информации;

    - высокие требования к ресурсам  компьютеров.

    При всем этом система обладает одним очень важным преимуществом - низкой стоимостью.

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

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

    СПИСОК  ЛИТЕРАТУРЫ

    1. Тейлор А.Дж. SQL для «чайников» /А.Дж. Тейлор.- Москва: Вильяме, 2005.

    2. Дейт К.Дж. Введение в системы баз данных /К.Дж. Дейт - Москва: ДМК, 2000.

    3. Хомоненко А.Д. Базы данных /А.Д. Хомоненко, В.М. Цыганков - Санкт-Петербург: БХВ-Петербург, 2004.

    4. Вескес Л.Дж. Access и SQL Server. Руководство разработчика /Дж.Л. Вескес - Москва: Лори, 1997.

    5. Конноли Т. Базы данных. Проектирование, реализация и сопровождение /Т. Конноли, К. Бегг. - Москва: Вильяме, 2003.