Самой простой архитектурой для реализации является архитектура «файл-сервер» (рисунок 1), но она же обладает и самым большим количеством недостатков, ограничивающих спектр решаемых ею задач. Простейшим случаем является случай, когда данные располагаются физически на том же компьютере, что и само приложение.
Рисунок 1 Структура информационной системы с файл-сервером
К существенным неудобствам, возникающим при работе с системой, построенной по такой архитектуре, можно отнести следующее:
— трудности при обеспечении непротиворечивости и целостности данных;
— существенная загрузка локальной сети передаваемыми данными;
— в целом, невысокая скорость обработки и представления информации;
— высокие требования к ресурсам компьютеров. При этом возникают следующие ограничения.
— невозможность организации равноправного одновременного доступа; пользователей к одному и тому же участку базы данных;
— количество одновременно работающих с системой пользователей не превышает пяти человек для ЛВС, построенной в соответствии со спецификацией 10BaseT (скорость обмена данными до 10Мб/с);
Типовые архитектуры СУБД
При всем этом система обладает одним очень важным преимуществом — низкой стоимостью.
Архитектура «файл-сервер» предусматривает концентрацию обработки на рабочих станциях. Основным преимуществом этого варианта является простота и относительная дешевизна. Подобное решение приемлемо, пока число пользователей, одновременно работающих с базой данных, не превышает 5-10 человек. При увеличении количества пользователей система может «захлебнуться» из-за перегруженности ЛВС большими потоками необработанной информации.
Сервер, как правило, — самый мощный и самый надежный компьютер. Он обязательно подключается через источник бесперебойного питания, в нем предусматриваются системы двойного или даже тройного дублирования. В особо ответственных случаях можно подключить вместе несколько серверов так, что при выходе из строя одного из них в работу автоматически включится «дублер». Таким образом, при концентрации обработки данных на сервере надежность системы в целом ограничивается только материальными средствами, которые заказчики готовы вложить в техническое оснащение.
Решение по автоматизации учета и управления в корпоративных структурах предполагает распределенную обработку данных, организацию параллельных вычислений, глубокое разграничение уровней доступа, возможность выбора различных операционных систем и серверных платформ. Если бизнес не велик, подобное решение оптимально.
В ходе эксплуатации были выявлены общие недостатки файл-серверного подхода при обеспечении многопользовательского доступа к базе данных.
Вся тяжесть вычислительной нагрузки при доступе к базе данных ложится на приложение клиента, что является следствием принципа обработки информации в системах «файл-сервер»: при выдаче запроса на выборку информации из таблицы вся таблица базы данных копируется на клиентское место, и выборка осуществляется на клиентском месте. Локальные СУБД используют так называемый «навигационный подход», ориентированный на работу с отдельными записями.
О взаимодействии с базой данных
Не оптимально расходуются ресурсы клиентского компьютера и сети; например, если в результате запроса мы должны получить 2 записи из таблицы объемом 10000 записей, все 10000 записей будут скопированы с файл-сервера на клиентский компьютер; в результате возрастает сетевой трафик и увеличиваются требования к аппаратным мощностям пользовательского компьютера.
В базе данных на файл-сервере гораздо проще вносить изменения в отдельные таблицы, минуя приложения. Эта возможность облегчается тем обстоятельством, что у локальных СУБД база данных — понятие более логическое, чем физическое, поскольку под базой данных понимается набор отдельных таблиц, сосуществующих в едином каталоге на диске. Все это позволяет говорить о низком уровне безопасности — как с точки зрения хищения и нанесения вреда, так и с точки зрения внесения ошибочных изменений.
Недостаточно развитый аппарат транзакций для локальных СУБД служит потенциальным источником ошибок как с точки зрения одновременного внесения изменений в одну и ту же запись, так и с точки зрения отката результатов серий объединенных по смыслу в единое целое операций над базой, когда некоторые из них завершились неуспешно, а некоторые — нет; это может нарушать ссылочную и смысловую целостность базы данных.
Недостатки настольных СУБД обычно проявляются не сразу, а лишь в процессе длительной эксплуатации, когда объем хранимых данных и число пользователей становятся достаточно велики — это приводит к снижению производительности приложений, использующих такие СУБД.
Поскольку настольные СУБД не содержат специальных приложений и сервисов, управляющих данными, а используются для этой цели файловые сервисы операционной системы, вся реальная обработка данных в таких СУБД осуществляется в клиентском приложении, и любые библиотеки доступа к данным в этом случае также находятся в адресном пространстве клиентского приложения. Поэтому при выполнении запросов данные, на основании которых выполняется такой запрос, должны быть доставлены в то же самое адресное пространство клиентского приложения. Это и приводит к перегрузке сети при увеличении числа пользователей и объема данных, а также грозит иными неприятными последствиями, например разрушением индексов и таблиц. Недаром до сих пор популярны утилиты для «ремонта» испорченных файлов настольных СУБД.
Недостатки архитектуры «файл-сервер» решаются при переводе приложений в архитектуру «клиент-сервер», которая знаменует собой следующий этап в развитии СУБД. Характерной особенностью архитектуры «клиент-сервер» является перенос вычислительной нагрузки на сервер базы данных (SQL-сервер) и максимальная разгрузка приложения клиента от вычислительной работы, а также существенное укрепление безопасности данных — как от злонамеренных, так и просто ошибочных изменений.
БД в этом случае помещается на сетевом сервере, как и в архитектуре «файл-сервер», однако прямого доступа к базе данных (БД) из приложений не происходит. Функция прямого обращения к БД осуществляет специальная управляющая программа — сервер БД (SQL-сервер), поставляемый разработчиком СУБД.
Знаете ли Вы, что диаграмма компонентов, Component diagram — это метод объектно-ориентированного проектирования, описывающий особенности физического представления системы. Диаграмма компонентов позволяет определить архитектуру разрабатываемой системы, устанавливая зависимости между компонентами.
Источник: www.bourabai.ru
При работе в архитектуре «файл-сервер» база данных и приложения расположены на файловом сервере
Как быстро выучить стихотворение наизусть? Запоминание стихов является стандартным заданием во многих школах.
Как научится читать по диагонали? Скорость чтения зависит от скорости восприятия каждого отдельного слова в тексте.
Как быстро и эффективно исправить почерк? Люди часто предполагают, что каллиграфия и почерк являются синонимами, но это не так.
Как научится говорить грамотно и правильно? Общение на хорошем, уверенном и естественном русском языке является достижимой целью.
- Обратная связь
- Правила сайта
Источник: www.soloby.ru
Архитектура многопользовательских СУБД
Существует три типовых архитектурных решения при реализации многопользовательских СУБД:
Телеобработка (рис.8) предполагает наличие одного компьютера с единственным процессором, который соединен с несколькими терминалами.
Вся обработка данных выполняется в рамках единственного компьютера. Присоединенные к нему пользовательские терминалы являются простыми «не интеллектуальными» устройствами, не способными функционировать самостоятельно.
Центральный компьютер выполняет действия прикладных программ и СУБД, а также значительную работу по обслуживанию терминалов (например, форматирование данных, выводимых на экраны терминалов, управление обменом данными со всеми терминалами). В результате на центральный процессор ложится чрезвычайно большая нагрузка, с которой могут справляться большие мейнфреймы.
Существенный прогресс в разработке высокопроизводительных персональных компьютеров и составленных из них сетей обусловил тенденцию к децентрализации и замене дорогих мейнфреймов более эффективными сетями персональных компьютеров. Эта тенденция привела к появлению следующих двух типов архитектуры СУБД – технологии файлового сервера и технологии клиент/сервер.
Файловый сервер (рис.9) используется в локальной вычислительной сети (ЛВС) и служит для распределенной обработки данных. Файловый сервер содержит файлы, необходимые для работы приложений и самой СУБД. Однако пользовательские приложения и сама СУБД размещены и функционируют на отдельных рабочих станциях и обращаются к файловому серверу только по
Файловый сервер функционирует просто как совместно используемый жесткий диск. СУБД на каждой рабочей станции посылает запросы файловому серверу по всем необходимым ей данным, которые хранятся на диске файл – сервера. Поскольку файл-сервер не обрабатывает запросы пользователей, то СУБД рабочей станции должна запросить у файлового сервера все файлы, соответствующие таблицам БД, содержащим необходимые данные. А затем СУБД извлечет из этих файлов нужные ей записи из соответствующих таблиц БД.
Такой подход характеризуется значительным сетевым трафиком, что может привести к снижению производительности всей системы в целом.
Поэтому архитектура с использованием файлового сервера обладает следующими основными недостатками:
большим объемом сетевого трафика;
на каждой рабочей станции должна работать полная копия СУБД;
управление параллельностью, восстановлением и целостностью усложняется, поскольку доступ к одним и тем же файлам могут осуществлять сразу несколько экземпляров СУБД.
Технология клиент/сервер (рис.10) была разработана с целью устранения недостатков, имеющихся в первых двух подходах. Клиент/сервер означает такой способ взаимодействия программных компонентов, при котором они образуют единую систему. Существует некий клиентский процесс, требующий определенных ресурсов, а также серверный процесс, который эти ресурсы предоставляет. При этом совсем необязательно, чтобы оба процесса находились на одном и том же компьютере. На практике принято размещать сервер на одном узле локальной сети, а клиенты – на других узлах.
Пользовательское приложение баз данных представляет собой клиентский процесс, выполняющийся на рабочей станции. Этот клиент принимает от пользователя запрос, проверяет его и генерирует запрос к базе данных на языке SQL. Затем он передает этот запрос серверу и ожидает поступления ответа.
Сервер принимает и обрабатывает запросы к базе данных, а затем передает полученные результаты обратно клиенту. Такая обработка включает проверку полномочий клиента, обеспечение требований целостности, поддержку системного каталога, а также выполнение запроса и при необходимости обновление данных. Помимо этого, поддерживается управление параллельностью и восстановлением.
Клиент, получив ответ от сервера, отображает полученные данные пользователю.
Этот тип архитектуры обладает приведенными ниже преимуществами:
обеспечивает более эффективный доступ к существующим базам данных;
повышается общая производительность системы (клиенты и серверы находятся на разных компьютерах, на сервере выполняется только работа с БД).
стоимость аппаратного обеспечения снижается (достаточно мощный компьютер нужен только серверу);
сокращаются коммуникационные расходы (существенно сокращается объем пересылаемых по сети данных);
повышается уровень непротиворечивости данных (все ограничения определяются и проверяются только в одном месте – на сервере, каждому приложению не надо выполнять собственную проверку).
Разработано дальнейшее расширение двухуровневой архитектуры клиент/сервер, при котором функциональная часть прежнего толстого (интеллектуального) клиента разделяется на две части. В трехуровневой архитектуре клиент/сервер тонкий (неинтеллектуальный) клиент на рабочей станции управляет только пользовательским интерфейсом, тогда как средний уровень обработки данных управляет всей остальной логикой приложения. Третьим уровнем здесь является сервер базы данных. Такая трехуровневая архитектура оказалась более подходящей для некоторых сред – например, для сетей Internet и Intranet, где в качестве клиента может использоваться обычный Web-браузер.
Языки баз данных
Внутренний язык СУБД для работы с данными состоит из двух частей: языка определения данных (DDL) и языка управления данными (DML). Язык DDL используется для определения схемы базы данных, а язык DML – для чтения и обновления данных, хранимых в базе.
Эти языки называются подъязыками данных, поскольку в них отсутствуют конструкции для выполнения всех вычислительных операций, обычно используемых в языках программирования высокого уровня. Во многих СУБД предусмотрена возможность внедрения операторов подъязыка данных в программы, написанные на таких языках программирования высокого уровня, как Pascal или C. В этом случае язык высокого уровня принято называть базовым языком (host language). Перед компиляцией файла программы на базовом языке эти операторы подъязыка предварительно удаляются и заменяются на вызовы соответствующих функций СУБД. Затем этот предварительно обработанный файл компилируется обычным образом в объектный модуль, который затем компонуется с библиотекой, содержащей вызываемые в программе функции СУБД.
Язык определения данных – DDL, является описательным языком, который позволяет АБД или пользователю описать и поименовать сущности, необходимые для работы некоторого приложения, а также связи, имеющиеся между различными сущностями. Схема базы данных состоит из набора определений, выраженных на специальных языке определения данных – DDL.
Язык DDL используется как для определения новой схемы, так и для модификации уже существующей. Этот язык нельзя использовать для управления данными. Результатом компиляции DDL-операторов является набор таблиц, хранимых в особых файлах, в которых хранятся данные, описывающие объекты базы данных – метаданные.
Такой особый файл называется системным каталогом (иногда каталогом данных). Метаданные включают определения записей элементов данных, а также другие объекты, необходимые пользователям или для работы СУБД. Перед доступом к реальным данным, СУБД обычно обращается к системному каталогу.
Язык управления данными – DML, это язык, содержащий набор операторов для поддержки основных операций манипулирования данными, содержащимися в базе.
К операциям управления данными относятся: вставка в базу данных новых сведений; модификация сведений, хранимых в базе данных; извлечение сведений, содержащихся в базе данных; удаление сведений из базы данных.
Одна из основных функций СУБД заключается в поддержке языка манипулирования данными (ЯМД), с помощью которого пользователь может создавать выражения для выполнения перечисленных выше операций с данными.
Языки DML отличаются базовыми конструкциями извлечения данных. Следует различать два типа языков DML: процедурный и непроцедурный. Основное отличие между ними заключается в том, что процедурные языки указывают то, как можно получить результат оператора языка DML, тогда как непроцедурные языки описывают то, какой результат будет получен. Как правило, в процедурных языках записи БД рассматриваются по отдельности, тогда как непроцедурные языки оперируют целыми наборами данных.
Процедурные языки DML – это языки, которые позволяют сообщить системе о том, какие данные необходимы, и точно указать, как их можно извлечь. С помощью процедурного языка программист указывает на то, какие данные ему необходимы, и как их можно получить.
Программист должен определить все операции доступа к данным (осуществляемые посредством вызова соответствующих процедур), которые должны быть выполнены для получения требуемой информации. Обычно такой процедурный язык позволяет извлечь запись, обработать ее, и, в зависимости от полученных результатов, извлечь другую запись, которая должна быть подвергнута аналогичной обработке, и т.д. Подобный процесс извлечения данных продолжается до тех пор, пока не будут извлечены все запрашиваемые данные. Языки DML сетевых и иерархических СУБД обычно являются процедурными.
Непроцедурные языки DML – это языки, которые позволяют указать лишь то, какие данные требуются, но не то, как их следует извлекать. Непроцедурные языки позволяют определить весь набор требуемых данных с помощью одного оператора извлечения или обновления. С помощью этих языков пользователь указывает, какие данные ему нужны без определения способа их получения.
СУБД транслирует выражение на языке DML в процедуру (или набор процедур), которая обеспечивает манипулирование затребованным набором записей. Данный подход освобождает пользователя от необходимости знать детали внутренней реализации структур данных и особенности алгоритмов, используемых для извлечения и возможного преобразования данных.
В результате работа пользователя получает определенную степень независимости от данных. Непроцедурные языки часто также называют декларативными языками. Реляционные СУБД обычно включают поддержку непроцедурных языков DML – чаще всего это бывает язык структурированных запросов SQL или язык запросов по образцу QBE (Query-by-Example). Непроцедурные языки обычно проще понимать и использовать, чем процедурные языки DML, поскольку пользователем выполняется меньшая часть работы, а СУБД – большая.
Источник: infopedia.su