Файл серверная архитектура многопользовательских систем баз данных предполагает что субд находится
Современные информационные системы характеризуются огромными объемами хранимой и обрабатываемой информации, сложностью ее организации, а также необходимостью удовлетворять разнообразные требования пользователей.
Существуют различные способы организации данных и методы доступа к ним. Традиционные архитектурные решения информационных систем основаны на использовании выделенных файл-серверов или серверов баз данных (БД). Существуют также варианты архитектур корпоративных информационных систем, базирующихся на технологии Интернет. В настоящее время достаточно популярной является также разновидность архитектуры информационной системы, основывающаяся на концепции «хранилища данных» (DataWarehouse) — интегрированной информационной среды, включающей разнородные информационные ресурсы.
И наконец, для построения глобальных распределенных информационных приложений используется архитектура интеграции информационно-вычислительных компонентов на основе объектно-ориентированного подхода.
Архитектура файл-сервер
В архитектуре файл-сервер базы данных хранятся на сервере, клиент обращается к серверу с файловыми командами, а механизм управления всеми информационными ресурсами находится на компьютере клиента.
Файл-серверные базы данных могут быть доступны многим клиентам через сеть. Сама база данных хранится на сетевом файл-сервере в единственном экземпляре. Для каждого клиента во время работы создается локальная копия данных, с которой он манипулирует. При этом возникают проблемы, связанные с возможным одновременным доступом нескольких пользователей к одной и той же информации. Эти проблемы решаются разработчиками приложений баз данных (каждый раз при обращении к данным проверяется их доступность).
Архитектура файл-сервер обладает значительными недостатками. Одним из них является непроизводительная загрузка сети. При каждом запросе клиента данные в его локальной копии полностью обновляются из базы данных на сервере. Даже если запрос относится всего к одной записи, обновляются все записи базы данных. Если записей в базе данных много, то и при небольшом числе клиентов сеть будет загружена очень основательно, что серьезно скажется на скорости выполнения запросов. В результате циркуляции в сети больших объемов избыточной информации резко возрастает нагрузка на сеть, что приводит к соответствующему снижению ее быстродействия и производительности информационной системы в целом. Значительный сетевой трафик особенно сказывается при организации удаленного доступа к базам данных на файл-сервере через низкоскоростные каналы связи.
Другой недостаток связан с тем, что забота о целостности данных при такой организации работы возлагается на программы клиентов. Одним из традиционных средств, на основе которых создаются файл-серверные системы, являются локальные СУБД. Такие системы, как правило, не отвечают требованиям обеспечения целостности данных, в частности, они не поддерживают обработки транзакций (завершенных операций с документами). Поэтому при их использовании задача обеспечения целостности данных возлагается на клиентские приложения, что приводит к их усложнению. Если они недостаточно тщательно продуманы, в базу данных легко занести ошибки, которые могут отразиться на всех пользователях.
Кроме того, в файл-серверной архитектуре изменения, сделанные в базе данных одним пользователем, не видны другим пользователям. Пока один пользователь редактирует какую-либо запись, она заблокирована для других клиентов. Возникает необходимость синхронизации работы отдельных пользователей, связанная с блокировкой записей.
И еще один недостаток — управление базой данных осуществляется с разных компьютеров, поэтому в значительной степени затруднена организация контроля доступа, соблюдения конфиденциальности, что также усложняет поддержку целостности базы данных.
Тем не менее файл-серверная архитектура привлекает своей простотой и доступностью. Поэтому файл-серверные информационные системы до сих пор представляют интерес для малых рабочих групп и более того нередко используются в качестве информационных систем в масштабах предприятия.
По принципам обработки данных БД классифицируются на централизованные и распределенные.
Централизованная БД подразумевает, что работа с БД возможна только локально. Если компьютер работает в сети, то доступ к информации может осуществляться удаленно с других компьютеров сети. Централизованные БД наиболее распространены в настоящее время. При этом возможны несколько вариантов обработки данных.
Файл-серверная архитектура предполагает наличие в сети сервера, на котором хранятся файлы централизованной БД. В соответствии с запросами пользователей файлы с файл-сервера передаются на рабочие станции пользователей, где и осуществляется основная часть обработки данных. Центральный сервер выполняет в основном только роль хранилища файлов, не участвуя в обработке самих данных. После завершения работы пользователи копируют файлы с обработанными данными обратно на сервер, откуда их могут взять и обработать другие пользователи. Недостатки такой организации данных очевидны. При одновременном обращении множества пользователей к одним и тем же данным производительность работы резко падает, т.к. необходимо дождаться пока пользователь, работающий с данными завершит работу. В противном случае возможно затирание исправлений сделанных одним пользователем, изменениями других пользователей.
Рис. 2. Централизованная архитектура
Рис. 3. Архитектура «файл-сервер»
Архитектура субд: архитектура «клиент-сервер», трехзвенная архитектура
В основе концепции клиент-сервер лежит идея о том, что помимо хранения файлов БД, центральный сервер должен выполнять основную часть обработки данных. Пользователи обращаются к серверу с помощью специального языка структурированных запросов (SQL, Structed Query Language), на которм описывается список задач, выполняемых сервером. Запросы принимаются сервером и порождают процессы обработки данных. В ответ пользователь получает уже отработанный набор данных. Технология клиент-сервер позволяет избежать передачи по сети огромных объемов информации, переложив всю обработку на центральный сервер. Такой подход также позволяет избежать конфликтов при редактировании одних и тех же данных множеством пользователей.
Рис. 3. Архитектура «клиент – сервер»
Трехуровневая архитектура («Тонкий клиент» - сервер приложений - сервер базы данных)функционирует в Интранет- и Интернет-сетях..
Клиентская часть ("тонкий клиент"), взаимодействующая с пользователем, представляет собой HTML-страницу в Web-браузере либо Windows-приложение, взаимодействующее с Web-сервисами. Вся программная логика вынесена на сервер приложений, который обеспечивает формирование запросов к базе данных, передаваемых на выполнение серверу баз данных. Сервер приложений может быть Web-сервером или специализированной программой (см. рис. 8).
Рис. 8. Схема работы с БД в трехуровневой архитектуре
Уровни представления баз данных
Создание БД предполагает интеграцию данных, предназначенных для решения нескольких прикладных задач различных пользователей.
При интеграции данных учитываются требования к данным каждого поля, основанные на его представлении о данных и связанных между ними. Далее эти данные должны обобщаться в единое представление, которое и служить основой для построения единой БД.
Обобщенное представление всех полей о данных называется концептуальной моделью БД.
Концептуальная модель представляет информационное описание предметной области с учетом логических взаимосвязей, поэтому ее еще иногда называют инфологической моделью. В ней отсутствуют какие-либо понятия, связанные с ЭВМ, памятью ЭВМ, способами размещения данных в памяти ЭВМ. По сути это модель только предметной области.
Каждая СУБД поддерживает определенный вид данных, называемый моделью данных СУБД. Следующий этап разработки БД – выбор представления концептуальной модели с помощью модели данных конкретной СУБД. Полученное таким образом представление называется логической моделью. Другими словами, логическая модель – концептуальная модель, специфицированная на языке конкретной СУБД.
Третий этап разработки БД – получение физической модели. Для этого разработчик средствами СУБД отображает логическую модель БД в память ЭВМ и определяет методы доступа. Также эта модель называется внутренней или структурой хранения.
Прикладная программа работает с логической моделью, причем каждому пользователю предоставляется подмножество этой логической модели (подсхема), отражающая его представление о предметной области. Каждая прикладная программа видит и обрабатывает те данные, которые необходимы именно ей.
Соответствующее видение данных прикладными программами (пользователями) называется внешним представлением.
Различные представления о данных в БД.
Рис. 6. Различные представления о данных в БД
На данной схеме выделены три различных уровня описания данных: внешний, концептуальный и внутренний. Эти уровни формируют так называемую трехуровневую архитектуру ANSI/SPARK. Она предложена в 1975 году комитетом планирования Standart INOM SPARK национального института стандартизации США ANSI. Основная цель – отделение пользовательского представления о данных в БД от их физического представления. Такой подход позволяет обеспечить выполнение основного требования к БД – независимость программы и данных. Такое представление также позволяет разграничить полномочия лиц, работающих с БД:
Представление специалиста предметной области – внешнее представление.
Разработчик, прикладной программист – логическое представление и внешнее представление.
Администратор БД, системный программист – логическая модель и физическая модель.
Цель лекции: показать основные варианты технологии работы нескольких пользователей с одной базой данных, связанные как с основными свойствами вычислительной техники, так и с развитием программного обеспечения.
Как уже отмечалось, понятие базы данных изначально предполагало возможность решения многих задач несколькими пользователями. В связи с этим, важнейшей характеристикой современных СУБД является наличие многопользовательской технологии работы. Разная реализация таких технологий в разное время была связана как с основными свойствами вычислительной техники, так и с развитием программного обеспечения. Дадим краткую характеристику этих технологий в хронологическом порядке.
3.1. Централизованная архитектура
При использовании этой технологии база данных , СУБД и прикладная программа ( приложение ) располагаются на одном компьютере (мэйнфрейме или персональном компьютере) (рис.3.1.). Для такого способа организации не требуется поддержки сети и все сводится к автономной работе. Работа построена следующим образом:
- База данных в виде набора файлов находится на жестком диске компьютера.
- На том же компьютере установлены СУБД и приложение для работы с БД .
- Пользователь запускает приложение. Используя предоставляемый приложением пользовательский интерфейс, он инициирует обращение к БД на выборку/обновление информации.
- Все обращения к БД идут через СУБД, которая инкапсулирует внутри себя все сведения о физической структуре БД.
- СУБД инициирует обращения к данным, обеспечивая выполнение запросов пользователя (осуществляя необходимые операции над данными).
- Результат СУБД возвращает в приложение.
- Приложение, используя пользовательский интерфейс, отображает результат выполнения запросов.
Подобная архитектура использовалась в первых версиях СУБД DB2 , Oracle , Ingres [ [ 3.1 ] ].
Многопользовательская технология работы обеспечивалась либо режимом мультипрограммирования (одновременно могли работать процессор и внешние устройства – например, пока в прикладной программе одного пользователя шло считывание данных из внешней памяти, программа другого пользователя обрабатывалась процессором), либо режимом разделения времени (пользователям по очереди выделялись кванты времени на выполнение их программ). Такая технология была распространена в период "господства" больших ЭВМ (IBM-370, ЕС-1045, ЕС-1060). Основным недостатком этой модели является резкое снижение производительности при увеличении числа пользователей.
3.2. Технология с сетью и файловым сервером (архитектура "файл-сервер")
Увеличение сложности задач, появление персональных компьютеров и локальных вычислительных сетей явились предпосылками появления новой архитектуры файл-сервер . Эта архитектура баз данных с сетевым доступом предполагает назначение одного из компьютеров сети в качестве выделенного сервера, на котором будут храниться файлы базы данных [ [ 3.2 ] ]. В соответствии с запросами пользователей файлы с файл-сервера передаются на рабочие станции пользователей, где и осуществляется основная часть обработки данных. Центральный сервер выполняет в основном только роль хранилища файлов, не участвуя в обработке самих данных ( рис. 3.2.).
Работа построена следующим образом:
- База данных в виде набора файлов находится на жестком диске специально выделенного компьютера (файлового сервера).
- Существует локальная сеть, состоящая из клиентских компьютеров, на каждом из которых установлены СУБД и приложение для работы с БД.
- На каждом из клиентских компьютеров пользователи имеют возможность запустить приложение. Используя предоставляемый приложением пользовательский интерфейс, он инициирует обращение к БД на выборку/обновление информации.
- Все обращения к БД идут через СУБД, которая инкапсулирует внутри себя все сведения о физической структуре БД, расположенной на файловом сервере.
- СУБД инициирует обращения к данным, находящимся на файловом сервере, в результате которых часть файлов БД копируется на клиентский компьютер и обрабатывается, что обеспечивает выполнение запросов пользователя (осуществляются необходимые операции над данными).
- При необходимости (в случае изменения данных) данные отправляются назад на файловый сервер с целью обновления БД.
- Результат СУБД возвращает в приложение.
- Приложение, используя пользовательский интерфейс, отображает результат выполнения запросов.
В рамках архитектуры " файл-сервер " были выполнены первые версии популярных так называемых настольных СУБД , таких, как dBase и Microsoft Access.
В литературе [ [ 3.2 ] ] указываются следующие основные недостатки данной архитектуры:
Архитектура файл-сервер
Самой простой архитектурой для реализации является архитектура "файл-сервер" (рисунок 1), но она же обладает и самым большим количеством недостатков, ограничивающих спектр решаемых ею задач. Простейшим случаем является случай, когда данные располагаются физически на том же компьютере, что и само приложение.
Рисунок 1 Структура информационной системы с файл-сервером
К существенным неудобствам, возникающим при работе с системой, построенной по такой архитектуре, можно отнести следующее:
- трудности при обеспечении непротиворечивости и целостности данных;
- существенная загрузка локальной сети передаваемыми данными;
- в целом, невысокая скорость обработки и представления информации;
- высокие требования к ресурсам компьютеров. При этом возникают следующие ограничения.
- невозможность организации равноправного одновременного доступа; пользователей к одному и тому же участку базы данных;
- количество одновременно работающих с системой пользователей не превышает пяти человек для ЛВС, построенной в соответствии со спецификацией 10BaseT (скорость обмена данными до 10Мб/с);
При всем этом система обладает одним очень важным преимуществом - низкой стоимостью.
Архитектура "файл-сервер" предусматривает концентрацию обработки на рабочих станциях. Основным преимуществом этого варианта является простота и относительная дешевизна. Подобное решение приемлемо, пока число пользователей, одновременно работающих с базой данных, не превышает 5-10 человек. При увеличении количества пользователей система может "захлебнуться" из-за перегруженности ЛВС большими потоками необработанной информации.
Сервер, как правило, — самый мощный и самый надежный компьютер. Он обязательно подключается через источник бесперебойного питания, в нем предусматриваются системы двойного или даже тройного дублирования. В особо ответственных случаях можно подключить вместе несколько серверов так, что при выходе из строя одного из них в работу автоматически включится "дублер". Таким образом, при концентрации обработки данных на сервере надежность системы в целом ограничивается только материальными средствами, которые заказчики готовы вложить в техническое оснащение.
Решение по автоматизации учета и управления в корпоративных структурах предполагает распределенную обработку данных, организацию параллельных вычислений, глубокое разграничение уровней доступа, возможность выбора различных операционных систем и серверных платформ. Если бизнес не велик, подобное решение оптимально.
В ходе эксплуатации были выявлены общие недостатки файл-серверного подхода при обеспечении многопользовательского доступа к базе данных.
Вся тяжесть вычислительной нагрузки при доступе к базе данных ложится на приложение клиента, что является следствием принципа обработки информации в системах "файл-сервер": при выдаче запроса на выборку информации из таблицы вся таблица базы данных копируется на клиентское место, и выборка осуществляется на клиентском месте. Локальные СУБД используют так называемый "навигационный подход", ориентированный на работу с отдельными записями.
Не оптимально расходуются ресурсы клиентского компьютера и сети; например, если в результате запроса мы должны получить 2 записи из таблицы объемом 10000 записей, все 10000 записей будут скопированы с файл-сервера на клиентский компьютер; в результате возрастает сетевой трафик и увеличиваются требования к аппаратным мощностям пользовательского компьютера.
В базе данных на файл-сервере гораздо проще вносить изменения в отдельные таблицы, минуя приложения. Эта возможность облегчается тем обстоятельством, что у локальных СУБД база данных — понятие более логическое, чем физическое, поскольку под базой данных понимается набор отдельных таблиц, сосуществующих в едином каталоге на диске. Все это позволяет говорить о низком уровне безопасности - как с точки зрения хищения и нанесения вреда, так и с точки зрения внесения ошибочных изменений.
Недостаточно развитый аппарат транзакций для локальных СУБД служит потенциальным источником ошибок как с точки зрения одновременного внесения изменений в одну и ту же запись, так и с точки зрения отката результатов серий объединенных по смыслу в единое целое операций над базой, когда некоторые из них завершились неуспешно, а некоторые - нет; это может нарушать ссылочную и смысловую целостность базы данных.
Недостатки настольных СУБД обычно проявляются не сразу, а лишь в процессе длительной эксплуатации, когда объем хранимых данных и число пользователей становятся достаточно велики - это приводит к снижению производительности приложений, использующих такие СУБД.
Поскольку настольные СУБД не содержат специальных приложений и сервисов, управляющих данными, а используются для этой цели файловые сервисы операционной системы, вся реальная обработка данных в таких СУБД осуществляется в клиентском приложении, и любые библиотеки доступа к данным в этом случае также находятся в адресном пространстве клиентского приложения. Поэтому при выполнении запросов данные, на основании которых выполняется такой запрос, должны быть доставлены в то же самое адресное пространство клиентского приложения. Это и приводит к перегрузке сети при увеличении числа пользователей и объема данных, а также грозит иными неприятными последствиями, например разрушением индексов и таблиц. Недаром до сих пор популярны утилиты для "ремонта" испорченных файлов настольных СУБД.
Недостатки архитектуры "файл-сервер" решаются при переводе приложений в архитектуру "клиент-сервер", которая знаменует собой следующий этап в развитии СУБД. Характерной особенностью архитектуры "клиент-сервер" является перенос вычислительной нагрузки на сервер базы данных (SQL-сервер) и максимальная разгрузка приложения клиента от вычислительной работы, а также существенное укрепление безопасности данных - как от злонамеренных, так и просто ошибочных изменений.
БД в этом случае помещается на сетевом сервере, как и в архитектуре "файл-сервер", однако прямого доступа к базе данных (БД) из приложений не происходит. Функция прямого обращения к БД осуществляет специальная управляющая программа - сервер БД (SQL-сервер), поставляемый разработчиком СУБД.
Читайте также: