На каком компьютере происходит работа с базой данных
Аннотация: В лекции рассматриваются различные варианты технологии работы с базой данных в многопользовательском режиме (централизованная архитектура, компьютерная сеть с файловым сервером, клиент-серверная архитектура). Дается краткий обзор современных СУБД.
Цель лекции: показать основные варианты технологии работы нескольких пользователей с одной базой данных, связанные как с основными свойствами вычислительной техники, так и с развитием программного обеспечения.
Как уже отмечалось, понятие базы данных изначально предполагало возможность решения многих задач несколькими пользователями. В связи с этим, важнейшей характеристикой современных СУБД является наличие многопользовательской технологии работы. Разная реализация таких технологий в разное время была связана как с основными свойствами вычислительной техники, так и с развитием программного обеспечения. Дадим краткую характеристику этих технологий в хронологическом порядке.
3.1. Централизованная архитектура
При использовании этой технологии база данных , СУБД и прикладная программа ( приложение ) располагаются на одном компьютере (мэйнфрейме или персональном компьютере) (рис.3.1.). Для такого способа организации не требуется поддержки сети и все сводится к автономной работе. Работа построена следующим образом:
- База данных в виде набора файлов находится на жестком диске компьютера.
- На том же компьютере установлены СУБД и приложение для работы с БД .
- Пользователь запускает приложение. Используя предоставляемый приложением пользовательский интерфейс, он инициирует обращение к БД на выборку/обновление информации.
- Все обращения к БД идут через СУБД, которая инкапсулирует внутри себя все сведения о физической структуре БД.
- СУБД инициирует обращения к данным, обеспечивая выполнение запросов пользователя (осуществляя необходимые операции над данными).
- Результат СУБД возвращает в приложение.
- Приложение, используя пользовательский интерфейс, отображает результат выполнения запросов.
Подобная архитектура использовалась в первых версиях СУБД DB2 , Oracle , Ingres [ [ 3.1 ] ].
Многопользовательская технология работы обеспечивалась либо режимом мультипрограммирования (одновременно могли работать процессор и внешние устройства – например, пока в прикладной программе одного пользователя шло считывание данных из внешней памяти, программа другого пользователя обрабатывалась процессором), либо режимом разделения времени (пользователям по очереди выделялись кванты времени на выполнение их программ). Такая технология была распространена в период "господства" больших ЭВМ (IBM-370, ЕС-1045, ЕС-1060). Основным недостатком этой модели является резкое снижение производительности при увеличении числа пользователей.
3.2. Технология с сетью и файловым сервером (архитектура "файл-сервер")
Увеличение сложности задач, появление персональных компьютеров и локальных вычислительных сетей явились предпосылками появления новой архитектуры файл-сервер . Эта архитектура баз данных с сетевым доступом предполагает назначение одного из компьютеров сети в качестве выделенного сервера, на котором будут храниться файлы базы данных [ [ 3.2 ] ]. В соответствии с запросами пользователей файлы с файл-сервера передаются на рабочие станции пользователей, где и осуществляется основная часть обработки данных. Центральный сервер выполняет в основном только роль хранилища файлов, не участвуя в обработке самих данных ( рис. 3.2.).
Работа построена следующим образом:
- База данных в виде набора файлов находится на жестком диске специально выделенного компьютера (файлового сервера).
- Существует локальная сеть, состоящая из клиентских компьютеров, на каждом из которых установлены СУБД и приложение для работы с БД.
- На каждом из клиентских компьютеров пользователи имеют возможность запустить приложение. Используя предоставляемый приложением пользовательский интерфейс, он инициирует обращение к БД на выборку/обновление информации.
- Все обращения к БД идут через СУБД, которая инкапсулирует внутри себя все сведения о физической структуре БД, расположенной на файловом сервере.
- СУБД инициирует обращения к данным, находящимся на файловом сервере, в результате которых часть файлов БД копируется на клиентский компьютер и обрабатывается, что обеспечивает выполнение запросов пользователя (осуществляются необходимые операции над данными).
- При необходимости (в случае изменения данных) данные отправляются назад на файловый сервер с целью обновления БД.
- Результат СУБД возвращает в приложение.
- Приложение, используя пользовательский интерфейс, отображает результат выполнения запросов.
В рамках архитектуры " файл-сервер " были выполнены первые версии популярных так называемых настольных СУБД , таких, как dBase и Microsoft Access.
В литературе [ [ 3.2 ] ] указываются следующие основные недостатки данной архитектуры:
К настоящему времени разработаны линейки продуктов DB2 и Informix , включающая как собственно СУБД так и средства разработки и анализа данных (DB2 Universal Database ДDB2 Personal Edition , DB2 Enterprise 9 и др., а также Informix Dynamic Server, Informix Dynamic Server Express, Informix Extended Parallel Server и др.
Универсальный сервер баз данных DB2 Universal Database - это масштабируемая, обьектно-реляционная система управления базами данных с интегрированной поддержкой мультимедиа и Web, работающая на системах от персональных компьютеров и серверов на процессорах Intel до Unix, от однопроцессорных систем до симметричных многопроцессорных систем (SMP) и систем с массовым параллелизмом (MPP), на хостах AS/400 и мейнфреймах. DB2 Universal Database объединяет в себе высокую производительность систем обработки транзакций в режиме on-line, объектно-реляционные расширения, усовершенствованные средства оптимизации с возможностями параллельной обработки и поддержкой очень больших баз данных. DB2 Universal Database также имеет новые встроенные средства для облегчения переноса на свою базу приложений, разработанных на других системах управления базами данных, таких как Oracle, Microsoft, Sybase и Informix. Помимо этого, DB2 Universal Database включает в себя дополнительные средства поддержки систем аналитической обработки в реальном времени (OLAP) и систем поддержки принятия решений, множество простых в использовании расширений (DB2 extenders). DB2 Universal Database доступна на абсолютном большинстве ключевых платформ, что дает заказчикам ту гибкость, которая им необходима.
Кроме вышеуказанных зарубежных систем отметим и отечественную разработку – СУБД НИКА, преемницу широко распространенной в Советском Союзе СУБД ИНЕС для ЕС ЭВМ.
Мы привелиВ этой лекции был приведен краткий обзор незначительной части существующих СУБД. При огромном разнообразии СУБД вполне естественны споры (которые возникли с момента появления СУБД и, по-видимому, не утихнут никогда) о том, какая СУБД лучше. Нам представляется, что однозначного ответа на этот вопрос не существует. Каждая СУБД имеет свои границы применимости, у каждой из них существуют свои достоинства и недостатки, свое соотношение цена-качество. На форумах Интернета идут постоянные дискуссии пользователей и администраторов баз данных о том, какая СУБД лучше, которые, естественно, не дают окончательного ответа. Любой читатель может иметь личные пристрастия, которые в его глазах уменьшают недостатки и увеличивают достоинства некоторой конкретной СУБД. Мы считаем, что это нормально. Общие рекомендации о том, какой из СУБД воспользоваться в каком-то конкретном случае, придумать сложно. Выбор, прежде всего, зависит от класса задач, который нужно решать с использованием СУБД, от тех критериев, которые для соответствующего класса задач являются предпочтительными ( стоимость СУБД, простота разработки информационной системы, быстродействие системы при конкретных объемах данных, устойчивость в работе, возможность восстановления, защита от несанкционированного доступа и т.д.). Рекомендация может быть только одна: внимательно изучайте обзоры, читайте пресс-релизы, знакомьтесь с отзывами пользователей, сопоставляйте их наблюдения о плюсах и минусах систем с вашими потребностями и возможностями.
Краткие
итоги. В лекции рассмотрены Рразличные архитектурные решения, используемые при реализации многопользовательских СУБД. Централизованная архитектура. Технология с сетью и файловым сервером (архитектура «файл-сервер»). Архитектура «клиент – сервер» (распределенная модель вычислений). Трехзвенная (многозвенная) архитектура) клиент – сервер. Дан Ообзор современных СУБД (настольные СУБД, серверные СУБД).
Задача 1. Какие технологии работы с базой данных поддерживают многопользовательский режим?
Вариант 1.
Какие технологии работы с базой данных поддерживают многопользовательский режим?
ð+ +технология с централизованной архитектурой базы данных
ð+ +технология с сетью и файловым сервером
ð+ +технология клиент-сервер
ð+ +технология с трехзвенной архитектурой
Вариант 2.
С чем связано развитие многопользовательских технологий работы с базами данных?
+ð+ с развитием СУБД
+ð+ Сс развитием вычислительных сетей
ð Сс развитием технологий программирования
ð Сс ростом квалификации программистов
Вариант 3.
Основные достоинства многопользовательского режима работы с базой данных
ð возможность использования прикладных программ других пользователей
ð сокращение затрат машинного времени
+ð+ возможность работы многих пользователей с базой данных
ð сокращение количества обращений к базе данных
Задача 2. Что такое архитектура файл-сервер?
Вариант 1.
Где расположена база данных в такой архитектуре?
ð на компьютере пользователя
+ð+ на специально выделенном компьютере – сервере
ð на компьютере пользователя и на специально выделенном компьютере – сервере
ð на всех компьютерах пользователей в локальной сети
Вариант 2.
Где расположены программы пользователя и программы СУБД?
+ð+ на компьютере пользователя
ð на специально выделенном компьютере – сервере
ð программа пользователя на компьютере пользователя, СУБДсубд на
специально выделенном компьютере – сервере
+ð+ СУБДсубд расположена на всех компьютерах пользователей в локальной сети
Вариант 3.
На каком компьютере происходит работа с базой данных?
ð+ +Нна компьютере одного пользователя
ð Нна специально выделенном компьютере – сервере
ð пПрикладные программы работают на компьютере пользователя, программы СУБД работают на специально выделенном компьютере – сервере
+ð+ пПрикладные программы и программы СУБД работают на компьютере пользователя.
Задача 3. Как идет обмен информацией между компьютерами в технологии файл-сервер?
Вариант 1.
Что делает компьютер пользователя?
+ð+ вВыполняет прикладную программу
+ð+ Ввыполняет программы СУБД
+ð+ рРеализует запросы пользователя к базе данных
+ð+ Ввыполняет прикладную программу и программы СУБД
Вариант 2.
Что делает файл-сервер?
ð фФормирует ответы на запросы к базе данных
+ð+ Ииспользуется как внешняя память для хранения базы данных
ð вВыполняет программы СУБД
ð вВыполняет прикладные программы и программы СУБД
Вариант 3.
Как идет обмен информацией между компьютерами в технологии файл-сервер?
ð вВ компьютер пользователя считываются все файлы базы данных
ð Вв компьютер пользователя считываются только данные, удовлетворяющие запросу пользователя
+ð+ Вв компьютер пользователя считываются только те файлы базы данных, которые необходимы для выполнения запросов
+ð+ Вв компьютер пользователя считываются файлы базы данных, указанные в прикладной программе .
Задача 4.Что такое архитектура клиент-сервер
Вариант 1.
Где расположена база данных в такой архитектуре?
ð на компьютере пользователя
+ð+ на специально выделенном компьютере – сервере
ð на компьютере пользователя и на специально выделенном компьютере – сервере
ð на всех компьютерах пользователей в локальной сети
Вариант 2.
Где расположены программы пользователя и программы СУБД в архитектуре клиент-сервер?
ð Нна компьютере пользователя
ð нНа специально выделенном компьютере – сервере
+ð+ пПрограмма пользователя на компьютере пользователя, СУБД на
специально выделенном компьютере – сервере
ð СУБД расположена на всех компьютерах пользователей в локальной сети
Вариант 3.
На каком компьютере происходит работа с базой данных в архитектуре клиент-сервер?
ð нНа компьютере одного пользователя
+ð+ нНа специально выделенном компьютере – сервере
+ð+ пПрикладные программы работают на компьютере пользователя, программы СУБД работают на специально выделенном компьютере – сервере
+ð+ Пприкладные программы и программы СУБД работают на компьютере пользователя.
Задача 5. Как идет обмен информацией между компьютерами в технологии клиент-сервер?
Вариант 1.
Что делает компьютер – клиент?
+ð Ввыполняет прикладную программу
ð Ввыполняет программы СУБД
ð рРеализует запросы пользователя к базе данных
ð+ вВыполняет прикладную программу и программы СУБД
Вариант 2.
Что делает сервер?
+ð+ фФормирует ответы на запросы к базе данных
ð иИспользуется как внешняя память для хранения базы данных
+ð+ вВыполняет программы СУБД
ð вВыполняет прикладные программы и программы СУБД
Вариант 3.
Как осуществляется обмен информацией между компьютером-клиентом и сервером?
ð Вв компьютер-клиент считываются все файлы базы данных
+ð+ вВ компьютер-клиент считываются только данные, удовлетворяющие запросу пользователя
ð Вв компьютер-клиент считываются только те файлы базы данных, которые необходимы для выполнения запросов
ð вВ компьютер-клиент считываются файлы базы данных, указанные в прикладной программе .
Задача 6. Что такое трехзвенная (многозвенная) архитектура
Вариант 1. Что отличает трехзвенную архитектуру от архитектуры клиент-сервер?
ð большее количество компьютеров пользователей
ð большее количество серверов баз данных
+ð+ наличие серверов других типов
ð другой способ взаимодействия с сервером баз данных
Вариант 2. Где выполняются программы пользователя в трехзвенной архитектуре?
ð на компьютере пользователя
ð на сервере баз данных
+ð+ на компьютере пользователя и сервере приложений
ð на сервере приложений
Вариант 3. Что делает сервер приложений?
ð выполняет прикладные программы пользователя
+ð+ формирует запросы к базе данных и обрабатывает результаты запросов
ð формирует интерфейс пользователя
ð отображает результаты обработки на компьютере пользователя
Задача 7. Сравнение архитектуры клиент-сервер с файл-серверной архитектурой.
Вариант 1.
Какие черты характерны для компьютеров-клиентов в архитектуре клиент-сервер по сравнению с файл-серверной архитектурой?
ð увеличение объема прикладной программы
+ð уменьшение объема прикладной программы
+ð+ уменьшение объема производимых вычислений
ð+ увеличение объема занимаемой памяти
+ð уменьшение объема занимаемой памяти
Вариант 2.
Как меняется объем данных, передаваемых по локальной сети в архитектуре клиент-сервер по сравнению с файл-серверной архитектурой?
ð немного уменьшается
ð увеличивается
ð остается таким же
ð+ существенно уменьшается
Вариант 3.
За счет чего улучшаются характеристики целостности и безопасности данных?
ð из-за уменьшения объема передаваемых данных
ð за счет более эффективного формирования запросов
ð за счет реализации соответствующих функций СУБД на клиентских компьютерах
ð+ +Зза счет реализации соответствующих функций СУБД на сервере баз данных
Задача 8.Как классифицируются современные СУБД?
Вариант 1.
Какие СУБД относятся к клиент-серверным?
ð ACCESS
+ð+ MS SQL-сервер
+ð+ ORACLE
ð+ +DB2
Вариант 2.
Какие СУБД относятся к файл-серверным?
+ð+ ACCESS
ð MS SQL-сервер
ð ORACLE
+ð+ FoxPro
Вариант 3.
Какие СУБД используются для организации баз данных в крупных организациях (относятся к промышленным)?
ð ACCESS
ð+ +MS SQL-сервер
ð+ +ORACLE
ð FoxPro
Литература
1. Грофф Дж., Вайнберг П. Энциклопедия SQL. 3-е изд. СПб.: Питер, 2003.
2. Шумаков П.В. Delphi 3 и создание приложений баз данных. М.: Изд-во «Нолидж», 1998.
3. Мамаев Е. Microsoft SQL Server 2000 в подлиннике. СПб.: Изд-во BHV, 2001.
Лекция 4. Различные представления о данных в базах данных. Основные этапы проектирования баз данных.
В лекции рассматриваются различные представления о данных в базах данных. Описываются модели данных (внешнее представление, концептуальная модель, структура хранения) и основные этапы проектирования базы данных. Рассматривается жизненный цикл проектирования базы данных.
Ключевые словатермины: концептуальные требования пользователя, концептуальная модель, модель данных СУБД,
логическая модель, обобщенное представление о данных, внешнее представление, трехуровневая архитектура базы данных, проектирование баз данных, основные этапы проектирования базы данных.
Цель лекции: Показать существование различных представлений о данных (различных моделей) у разных групп лиц, работающих с данными. Рассмотреть отражение этих представлений в трехуровневой архитектуре базы данных (внешний уровень, концептуальный уровень, внутренний уровень), сформулировать достоинство трехуровней архитектуры. Выделить основные этапы пректирования базы данных как процесса построения вышеуказанных моделей.
4.1. Различные представления о данных в базах данных
Создание базы данных предполагает интеграцию данных, предназначенных для решения нескольких прикладных задач разных пользователей. Соответственно, при интеграции данных должны учитываться требования к данным каждого пользователя, основанные на его представлении о данных и связях между ними. Далее эти требования должны обобщаться в единое представление, которое и будет служить основой для построения единой базы данных (рис. 4.1).
Обобщение представлений всех пользователей о данных называется концептуальной моделью (схемой) БД. Концептуальная модель представляет информационное описание предметной области с учетом логических взаимосвязей, поэтому её еще называют инфологической (информационно-логической) моделью. В модели отсутствуют какие-либо понятия, связанные с ЭВМ, памятью ЭВМ, способами размещения данных в памяти ЭВМ, и, по сути, это модель только предметной области.
Рис. 4.1. Обобщение представления пользователей о данных
Как уже отмечалось, для создания базы данных и работы с ней используется система управления базами данных. Каждая конкретная СУБД поддерживает определенный вид данных (форматов записей и отношений), называемый моделью данных СУБД.
Следующий этап разработки базы данных предполагает выбор представления концептуальной модели с помощью модели данных конкретной СУБД. Полученное таким образом представление концептуальной модели называется логической моделью БД. Или другими словами, логическая модель – это концептуальная схема, специфицированная в языке конкретной СУБД. Логическая модель представляет данные и элементы данных вне зависимости от их содержания и среды хранения. Далее разработчик системы средствами СУБД отображает полученную логическую модель БД в память ЭВМ и определяет методы доступа. Полученное представление данных в памяти ЭВМ называется внутренним представлением или структурой хранения. Прикладные программы работают с логической моделью, причем каждому пользователю представляется подмножество этой логической модели (подсхема), отражающее его представление о предметной области. Каждая прикладная программа «видит» и обрабатывает только те данные, которые необходимы именно ей.
Соответствующее «видение» данных прикладными программами (пользователями) представляет собой внешние представления. Взаимосвязь вышеуказанных моделей изображена на рис.4.2.
Рис. 4.2. Различные представления о данных в БД
На данной схеме выделены три различных уровня описания данных (внешний, концептуальный, внутренний). Эти уровни формируют так называемую трехуровневую архитектуру ANSI/SPARC, предложенную в 1975 г. Комитетом планирования стандартов и норм SPARC (Standards Planning and Requirements Committee) Национального института стандартизации США (American National Standards Institute – ANSI). Основная цель этой архитектуры состоит в отделении пользовательского представления о данных в базе данных от их физического представления. Использование таких представлений о данных позволяет обеспечить выполнение основного требования к БД – независимости программ и данных. При изменении прикладных программ может измениться соответствующее внешнее представление, но логическая модель данных не изменяется и, соответственно, не будут изменяться другие прикладные программы. При изменении внутреннего представления (структур хранения) логическая модель не изменяется, соответственно, не изменяются прикладные программы.
Использование соответствующих представлений также позволяет четко разграничить полномочия различных лиц, работающих с базой данных.
Соответствующие представления позволяют описать «видение» базы данных разными лицами, работающими с ней:
§· внешнее представление – представление специалиста предметной области (пользователя);
§· внешнее представление и логическая модель – представление прикладного программиста, разрабатывающего конкретное приложение для пользователя;
§· логическая модель и внутреннее представление – представление системного программиста, администрирующего базу данных.
4.2. Основные этапы проектирования базы данных
Проектирование данных (базы данных) представляет собой процесс последовательного отображения исследуемых явлений реального мира в виде данных в памяти ЭВМ (рис. 4.3.).
А что здесь такого, спросите вы? В том-то и дело, что работа с данными в web-приложениях требует иного подхода, чем описанный во всех статьях и учебниках метод работы с использованием типизированных наборов данных. Объясняется это в первую очередь требованиями к производительности системы, что играет далеко не последнюю роль в качестве проектируемого программного продукта. И если при написании настольных приложений некоторыми аспектами производительности можно было пренебречь, то в web-приложениях такое пренебрежение чревато серьезными проблемами.
В статье мы подробно рассмотрим пример приложения, останавливаясь на ключевых моментах, объясняя преимущества выбранного метода перед другими существующими.
В качестве системы баз данных мы выберем небезызвестный сервер баз данных MS SQL. О его достоинствах и о его вкладе в общую производительность разрабатываемого приложения здесь речь не пойдет, считая de facto его достоинства и недостатки перед другими системами.
В качестве тестовой базы данных можно воспользоваться стандартной базой Northwind, но для мы создадим свою базу данных. Назовем ее DemoBase.
А теперь внимание - первое условие для построения нормального приложения. Для манипуляции данными в нашей базе мы воспользуемся хранимыми процедурами. Не вдаваясь в детали, скажем так, что их главное их преимущество заключается в том, что хранятся они на сервере в уже откомпилированном виде, в то время как простой переданный набор команд Transact-SQL проходит через такую стадию . Кроме того, они как бы в себя структуру базы данных, что обеспечивает большую гибкость проектирования этой самой базы.
Наши процедуры будут выполнять четыре элементарных действия с данными в таблице Users (Select, Update, Delete и Insert). Причем Update и Insert мы объединим одной процедурой.
Процедура выборки данных:
Процедура добавления новой записи и редактирования существующей:
Процедура удаления записи:
И процедура, подсчета количества записей в таблице. На ее примере мы увидим, как из процедуры получать скалярные величины в качестве результата их работы:
В первую очередь позаботимся о подключении к нашей базе данных. Строку подключения мы будем хранить в конфигурационном файле Web.config. Для этого добавим специальный раздел:
Кроме того, для доступа к серверу БД нам нужен будет экземпляр класса SqlConnection (почему не OleDbConnection, см. цикл статей ). Для обеспечения унификации процесса создания соединения, добавим к нашему проекту класс, со статическим атрибутом нужного нам типа:
Теперь мы можем, наконец, приступить к разработке визуальной части нашего приложения.
Для начала перейдем к коду формы, и внесем некоторые изменения стандартный шаблон:
Для начала поместим на форму экземпляр SqlCommand, и назовем его SelectCommand. Затем перейдем к коду формы, и внесем в стандартный код некоторые изменения:
Все же, что связанно с отображением данных будет происходить в CreatePage().
В первую очередь, нам нужно выбрать данные из базы и отобразить их на форме. Для этого мы создадим экземпляр SqlCommand, и назовем его SelectCommand. Проинициализируем все его основные свойства в CustomInit():
Теперь поместим на форму экземпляр DataGrid:
Теперь перейдем к методу CreatePage(). В нем-то мы и совершим тот магический жест, после которого на нашей форме будут красоваться данные из базы:
Для добавления новых записей, мы поместим на форму два TеxtBox-а, назвав их NameTextBox и CommentsTextBox соответственно, и кнопку, по нажатию на которую и будем добавлять данные. Для этого мы воспользуемся другоим экземпляром SqlCommand, который будет настроен на соответствующую процедуру. Этой же командой мы будем редактировать данные:
По такому же принципу происходит удаление и редактирование данных. Не вдаваясь в подробности реализации, дабы не повториться, приведу лишь код обработчиков UpdateCommand и DeleteCommand:
А теперь воспользуемся нашей процедурой подсчета количества записей в таблице и посмотрим, как из процедуры получать какие-то скалярные величины. Для этого добавим на форму еще один экземпляр SqlCommand, назвав его CountCommand и проинициализируем его параметры следующим образом:
Мы проинициализировали свойство Direction, указав, что параметр этот возвращаемый. А теперь внесем некоторые изменения в метод CreatePage(), добавив нижеприведенный код до закрытия соединения, чтобы отобразить результат работы этой команды:
Таким образом мы разработали простейшее приложение "правильно" работающее с данными. После всего вышенаписанного, давайте подытожим нашу работу:
1. Для обработки данных на сервере БД необходимо пользоваться хранимыми процедурами.
2. Для обработки данных на уровне приложения нужно пользоваться прямым выполеннием команд, которые, в нашем случае, возвращают либо простой набор данных, либо скалярные данные, либо ничего не возвращают.
3. Ну и классическое правило применительно к соединению с БД.
Некоторая структурная неоптимальность приложения является исключительно следствием желания сделать его более наглядным.
Базы данных на ПК развивались по направлению от настольных (desktop), или локальных приложений, когда реально с БД могло работать одно приложение, до систем коллективного доступа к БД.
Локальное приложение устанавливалось на единичном ПК; там же располагалась и база данных (БД), с которой работало данное приложение. Однако необходимость коллективной работы с одной и той же БД повлекло за собой перенос БД на сервер. Приложение, работающее с БД, располагалось также на сервере.
Менее характерным был другой способ, заключавшийся в хранении приложения, обращавшегося к БД, на конкретном компьютере пользователей ("клиентов"). Были выпущены новые версии локальных СУБД, которые позволяли создавать приложения, одновременно работающие с одной БД на файловом сервере. Основной проблемой была явная или неявная обработка транзакций и неизбежно встающая при коллективном доступе проблема обеспечения смысловой и ссылочной целостности БД при одновременном изменении одних и тех же данных.
Местоположение БД определяет так называемую архитектуру базы данных. Имеются четыре разновидности архитектур баз данных:
-локальные базы данных;
Использование той или иной архитектуры накладывает сильный отпечаток на общую идеологию работы приложения и на программный код приложения.
При работе с локальными базами данных сами базы данных расположены на том же компьютере, что и приложения, осуществляющие доступ к ним. Работа с базой данных происходит в однопользовательском режиме. Приложение ответственно за поддержание целостности базы и за выполнение запросов к базе данных.
При работе в архитектуре "файл-сервер" база данных и приложение расположены на файловом сервере сети. Возможна многопользовательская работа с одной и той же базе данных, когда каждый пользователь со своего компьютера запускает приложение, расположенное на сетевом сервере. Тогда на компьютере пользователя запускается копия приложения. По каждому запросу к базе данных из приложения данные из таблиц базы данных перегоняются на компьютер пользователя, независимо от того, сколько реально нужно данных для выполнения запроса. После этого выполняется запрос.
Каждый пользователь имеет на своем компьютере локальную копию данных, время от времени обновляемых из реальной базы данных, расположенной на сетевом сервере. При этом изменения, которые каждый пользователь вносит в базу данных, могут быть до определенного момента неизвестны другим пользователям, что делает актуальной задачу систематического обновления данных на компьютере пользователя из реальной базы данных. Другой актуальной задачей является блокирование записей, которые изменяются одним из пользователей; это необходимо для того, чтобы в это время другой пользователь не внес изменений в те же данные.
В архитектуре "файл-сервер" вся тяжесть выполнения запросов к базе данных и управления целостностью базы данных ложится на приложение пользователя. База данных на сервере является пассивным источником данных.
Кардинальных различий с точки зрения архитектуры между однопользовательской архитектурой и архитектурой "файл-сервер" нет. И в том, и в ином случае в качестве СУБД применяются так называемые "персональные" (или "настольные", "локальные") СУБД, такие как paradox, dbase и пр. Сама база данных в этом случае представляет собой набор таблиц, индексных файлов, файлов полей комментариев (memo-полей) и пр., хранящихся в одном каталоге на диске в виде отдельных файлов.
В ходе эксплуатации были выявлены общие недостатки файл-серверного подхода при обеспечении многопользовательского доступа к базе данных.
Вся тяжесть вычислительной нагрузки при доступе к базе данных ложится на приложение клиента, что является следствием принципа обработки информации в системах "файл-сервер": при выдаче запроса на выборку информации из таблицы вся таблица базы данных копируется на клиентское место, и выборка осуществляется на клиентском месте. Локальные СУБД используют так называемый "навигационный подход", ориентированный на работу с отдельными записями.
Не оптимально расходуются ресурсы клиентского компьютера и сети; например, если в результате запроса мы должны получить 2 записи из таблицы объемом 10000 записей, все 10000 записей будут скопированы с файл-сервера на клиентский компьютер; в результате возрастает сетевой трафик и увеличиваются требования к аппаратным мощностям пользовательского компьютера.
В базе данных на файл-сервере гораздо проще вносить изменения в отдельные таблицы, минуя приложения, непосредственно из инструментальных средств (например, из утилиты database desktop фирмы borland для файлов paradox или dbase); подобная возможность облегчается тем обстоятельством, что, фактически, у локальных СУБД база данных – понятие более логическое, чем физическое, поскольку под базой данных понимается набор отдельных таблиц, сосуществующих в едином каталоге на диске. Все это позволяет говорить о низком уровне безопасности – как с точки зрения хищения и нанесения вреда, так и с точки зрения внесения ошибочных изменений.
Недостаточно развитый аппарат транзакций для локальных СУБД служит потенциальным источником ошибок как с точки зрения одновременного внесения изменений в одну и ту же запись, так и с точки зрения отката результатов серий объединенных по смыслу в единое целое операций над базой, когда некоторые из них завершились неуспешно, а некоторые - нет; это может нарушать ссылочную и смысловую целостность базы данных.
Недостатки настольных СУБД обычно проявляются не сразу, а лишь в процессе длительной эксплуатации, когда объем хранимых данных и число пользователей становятся достаточно велики – это приводит к снижению производительности приложений, использующих такие СУБД.
Поскольку настольные СУБД не содержат специальных приложений и сервисов, управляющих данными, а используются для этой цели файловые сервисы операционной системы, вся реальная обработка данных в таких СУБД осуществляется в клиентском приложении, и любые библиотеки доступа к данным в этом случае также находятся в адресном пространстве клиентского приложения. Поэтому при выполнении запросов данные, на основании которых выполняется такой запрос (это может быть одна или несколько таблиц целиком либо, если повезет, один или несколько индексов и выбранные с их помощью части таблиц), должны быть доставлены в то же самое адресное пространство клиентского приложения. Это и приводит к перегрузке сети при увеличении числа пользователей и объема данных, а также грозит иными неприятными последствиями, например разрушением индексов и таблиц. Недаром до сих пор популярны утилиты для "ремонта" испорченных файлов настольных СУБД.
Недостатки архитектуры "файл-сервер" решаются при переводе приложений в архитектуру "клиент-сервер", которая знаменует собой следующий этап в развитии СУБД. Характерной особенностью архитектуры "клиент-сервер" является перенос вычислительной нагрузки на сервер базы данных (sql-сервер) и максимальная разгрузка приложения клиента от вычислительной работы, а также существенное укрепление безопасности данных – как от злонамеренных, так и просто ошибочных изменений.
БД в этом случае помещается на сетевом сервере, как и в архитектуре "файл-сервер", однако прямого доступа к базе данных (БД) из приложений не происходит. Функция прямого обращения к БД осуществляет специальная управляющая программа – сервер БД (sql-сервер), поставляемый разработчиком СУБД.
Архитектура "клиент-сервер" разделяет функции приложения пользователя (называемого клиентом) и сервера.
Приложение-клиент формирует запрос к серверу, на котором расположена БД, на структурном языке запросов sql, являющимся промышленным стандартом в мире реляционных БД. Удаленный сервер принимает запрос и переадресует его sql-серверу БД. sql-сервер – это специальная программа, управляющая удаленной базой данных. sql-сервер обеспечивают интерпретацию запроса, его выполнение в базе данных, формирование результата выполнения запроса и выдачу его приложению-клиенту. При этом ресурсы клиентского компьютера не участвуют в физическом выполнении запроса; клиентский компьютер лишь отсылает запрос к серверной БД и получает результат, после чего интерпретирует его необходимым образом и представляет пользователю.
Так как клиентскому приложению посылается результат выполнения запроса, по сети "путешествуют" только те данные, которые необходимы клиенту. В итоге снижается нагрузка на сеть. Поскольку выполнение запроса происходит там же, где хранятся данные (на сервере), нет необходимости в пересылке больших пакетов данных. Кроме того, sql-сервер, если это возможно, оптимизирует полученный запрос таким образом, чтобы он был выполнен в минимальное время с наименьшими накладными расходами. Всё это повышает быстродействие системы и снижает время ожидания результата запроса.
При выполнении запросов сервером существенно повышается степень безопасности данных, поскольку правила целостности данных определяются в базе данных на сервере и являются едиными для всех приложений, использующих эту БД. Таким образом, исключается возможность определения противоречивых правил поддержания целостности. Мощный аппарат транзакций, поддерживаемый sql-серверами, позволяет исключить одновременное изменение одних и тех же данных различными пользователями и предоставляет возможность откатов к первоначальным значениям при внесении в БД изменений, закончившихся аварийно.
Функциями приложения-клиента являются:
-Посылка к серверу запросов;
-Интерпретация результатов запросов, полученных от сервера, и представление их пользователю в требуемой форме;
-Реализация интерфейса пользователя.
sql-сервер должен быть загружен на момент принятия запроса клиента. Функциями сервера БД являются:
-Прием запросов от приложений-клиентов, интерпретация запросов, выполнение запросов в БД, отправка результата выполнения запроса приложению-клиенту;
-Управление целостностью БД, обеспечение системы безопасности, блокировка неверных действий приложений-клиентов;
-Хранение бизнес-правил, часто используемых запросов в уже интерпретированном виде;
-Обеспечение одновременной безопасной от отказоустойчивой многопользовательской работы с одними и теми же данными.
В архитектуре "клиент-сервер" используются так называемые "удаленные" (или "промышленные") СУБД. Промышленными они называются из-за того, что именно СУБД этого класса могут обеспечить работу информационных систем масштаба среднего и крупного предприятия, организации, банка. Локальные СУБД предназначены для однопользовательской работы или для обеспечения работы информационных систем, рассчитанных на небольшие группы пользователей.
К разряду промышленных СУБД принадлежат oracle, informix, sybase, ms sql server, db2, interbase и ряд других.
Как правило, sql-сервер управляется отдельным сотрудником или группой сотрудников (администраторы sql-сервера). Они управляют физическими характеристиками баз данных, производят оптимизацию, настройку и переопределение различных компонентов БД, создают новые БД, изменяют существующие и т.д., а также выдают привилегии различным пользователям.
Кроме этого, существует отдельная категория сотрудников, называемых администраторами баз данных. Как правило, это администраторы сервера, разработчики БД или пользователи, имеющие привилегии на создание, изменение, настройку оптимальных параметров отдельных серверных БД. Администраторы БД также отвечают за предоставление прав на разноуровневый доступ к сопровождаемым ими БД для других пользователей.
Механизмы доступа
При выборе СУБД необходимо иметь представление, с помощью каких средств разработки будет создаваться информационная система на основе данной СУБД, а также о том, каким образом разработанные приложения будут манипулировать данными. От того, правильно ли выбран механизм доступа к данным, зависит очень многое, в частности производительность приложений, возможность применения тех или иных функциональных особенностей данной СУБД, простота разработки пользовательского интерфейса и ряд других факторов.
Существует несколько способов доступа к данным из средств разработки и клиентских приложений.
Подавляющее большинство СУБД содержит в своем составе библиотеки, предоставляющие специальный прикладной программный интерфейс (application programming interface, api) для доступа к данным этой СУБД. Обычно такой интерфейс представляет собой набор функций, вызываемых из клиентского приложения. В случае настольных СУБД эти функции обеспечивают чтение/запись файлов базы данных (БД), а в случае серверных СУБД инициируют передачу запросов серверу баз данных и получение от сервера результатов выполнения запросов или кодов ошибок, интерпретируемых клиентским приложением. Библиотеки, содержащие api для доступа к данным серверной СУБД, обычно входят в состав ее клиентского программного обеспечения, устанавливаемого на компьютерах, где функционируют клиентские приложения.
В последнее время windows-версии клиентского программного обеспечения наиболее популярных серверных СУБД, в частности microsoft sql server, oracle, informix, содержат также СОМ-серверы, предоставляющие объекты для доступа к данным и метаданным.
Использование клиентского api (или клиентских СОМ-объектов) является наиболее очевидным способом манипуляции данными в приложении. Однако в этом случае созданное приложение сможет использовать данные только СУБД этого производителя, и замена ее на другую повлечет за собой переписывание значительной части кода клиентского приложения – клиентские api и объектные модели не подчиняются никаким стандартам и различны для различных СУБД.
Другой способ манипуляции данными в приложении базируется на применении универсальных механизмов доступа к данным. Универсальный механизм доступа к данным обычно реализован в виде библиотек и дополнительных модулей, называемых драйверами или провайдерами. Библиотеки содержат некий стандартный набор функций или классов, нередко подчиняющийся той или иной спецификации. Дополнительные модели, специфичные для той или иной СУБД, реализуют непосредственное обращение к функциям клиентского api конкретных СУБД.
Отметим, что достоинством универсальных механизмов является возможность применения одного и того же абстрактного api, а во многих случаях – СОМ-серверов, компонентов, классов для доступа к различным типам СУБД. Поэтому приложения, использующие универсальные механизмы доступа к данным, легко модифицировать, если необходима смена СУБД.
Наиболее популярными среди универсальных механизмов доступа к данным можно назвать следующие:
Универсальные механизмы odbc, ole db и ado фирмы microsoft представляют собой по существу промышленные стандарты. Что касается механизма доступа к данным bde фирмы borland, то он так и не стал промышленным стандартом, однако до недавнего времени применялся довольно широко, поскольку до выхода delphi 5 был практически единственным универмальным механизмом доступа к данным, поддерживаемым средствами разработки borland на уровне компонентов и классов
Что такое sql?
sql часто называют языком эсперанто для СУБД. Действительно, в мире нет другого языка для работы с базами данных (БД), который бы настолько широко использовался в программах. Первый стандарт sql появился в 1986 г. и к настоящему времени завоевал всеобщее признание. Его можно использовать даже при работе с не реляционными СУБД. В отличие от других программных средств, таких, как языки Си и Кобол, являющихся прерогативой программистов-профессионалов, sql применяется специалистами из самых разных областей. Программисты, администраторы СУБД, бизнес-аналитики - все они с успехом обрабатывают данные с помощью sql. Знание этого языка полезно всем, кому приходится иметь дело с БД.
sql - это специализированный непроцедурный язык, позволяющий описывать данные, осуществлять выборку и обработку информации из реляционных СУБД. Специализированность означает, что sql предназначен лишь для работы с БД; нельзя создать полноценную прикладную систему только средствами этого языка - для этого потребуется использовать другие языки, в которые можно встраивать sql-команды. Поэтому sql еще называют вспомогательным языковым средством для обработки данных. Вспомогательный язык используется только в комплексе с другими языками.
В прикладном языке общего назначения обычно имеются средства для создания процедур, а в sql их нет. С его помощью нельзя указать, каким образом должна выполняться некоторая задача, а можно лишь определить, в чем именно она заключается. Другими словами, при работе с sql нас интересуют результаты, а не процедуры для их получения. Иными словами, sql является непроцедурным языком. Термин "непроцедурный" означает, что на этом языкек можно сформулировать, что именно нужно сделать с данными, но нельзя проинструктировать, как это следует сделать. В языке sql отсутствуют алгоритмические конструкции, такие как метки, операторы цикла, условные переходы и т.п.
Наиболее существенным свойством sql является возможность доступа к реляционным БД. Многие даже считают, что выражения "БД, обрабатываемая средствами sql" и "реляционная БД" - синонимы. В стандарте sql-92 даже нет термина отношение (relation).
Предположим, что имеется база данных, управляемая с помощью какой-либо СУБД. Для извлечения из нее данных используется запрос, сформулированный на языке sql. СУБД обрабатывает этот запрос, извлекает запрашмваемые данные и возвращает их.
sql позволяет не только извлекать данные, но и определять структуру данных, добавлять и удалять данные, ограничивать или предоставлять доступ к данным, поддерживать ссылочную целостность. sql сам по себе не является ни СУБД, ни отдельным продуктом. Это – язык, применяемый для взаимодействия с СУБД и являющийся в определенном смысле ее неотъемлемой частью.
История развития СУБД насчитывает более 30 лет. В 1968 году была введена в эксплуатацию первая промышленная СУБД система IMS фирмы IBM . В 1975 году появился первый стандарт ассоциации по языкам систем обработки данных — Conference of Data System Languages (CODASYL), который определил ряд фундаментальных понятий в теории систем баз данных, которые и до сих пор являются основополагающими для сетевой модели данных .
В дальнейшее развитие теории баз данных большой вклад был сделан американским математиком Э. Ф. Коддом, который является создателем реляционной модели данных. В 1981 году Э. Ф. Кодд получил за создание реляционной модели и реляционной алгебры престижную премию Тьюринга Американской ассоциации по вычислительной технике.
Менее двух десятков лет прошло с этого момента, но стремительное развитие вычислительной техники, изменение ее принципиальной роли в жизни общества, обрушившийся бум персональных ЭВМ и, наконец, появление мощных рабочих станций и сетей ЭВМ повлияло также и на развитие технологии баз данных. Можно выделить четыре этапа в развитии данного направления в обработке данных. Однако необходимо заметить, что все же нет жестких временных ограничений в этих этапах: они плавно переходят один в другой и даже сосуществуют параллельно, но тем не менее выделение этих этапов позволит более четко охарактеризовать отдельные стадии развития технологии баз данных, подчеркнуть особенности, специфичные для конкретного этапа.
Первый этап развития СУБД связан с организацией баз данных на больших машинах типа IBM 360/370, ЕС-ЭВМ и мини-ЭВМ типа PDP11 (фирмы Digital Equipment Corporation — DEC ), разных моделях HP (фирмы Hewlett Packard).
Базы данных хранились во внешней памяти центральной ЭВМ, пользователями этих баз данных были задачи, запускаемые в основном в пакетном режиме. Интерактивный режим доступа обеспечивался с помощью консольных терминалов, которые не обладали собственными вычислительными ресурсами (процессором, внешней памятью) и служили только устройствами ввода-вывода для центральной ЭВМ. Программы доступа к БД писались на различных языках и запускались как обычные числовые программы. Мощные операционные системы обеспечивали возможность условно параллельного выполнения всего множества задач. Эти системы можно было отнести к системам распределенного доступа, потому что база данных была централизованной, хранилась на устройствах внешней памяти одной центральной ЭВМ, а доступ к ней поддерживался от многих пользователей-задач.
Особенности этого этапа развития выражаются в следующем:
- Все СУБД базируются на мощных мультипрограммных операционных системах ( MVS , SVM, RTE, OSRV, RSX , UNIX), поэтому в основном поддерживается работа с централизованной базой данных в режиме распределенного доступа.
- Функции управления распределением ресурсов в основном осуществляются операционной системой (ОС).
- Поддерживаются языки низкого уровня манипулирования данными, ориентированные на навигационные методы доступа к данным.
- Значительная роль отводится администрированию данных.
- Проводятся серьезные работы по обоснованию и формализации реляционной модели данных, и была создана первая система (System R), реализующая идеологию реляционной модели данных.
- Проводятся теоретические работы по оптимизации запросов и управлению распределенным доступом к централизованной БД, было введено понятие транзакции.
- Результаты научных исследований открыто обсуждаются в печати, идет мощный поток общедоступных публикаций, касающихся всех аспектов теории и практики баз данных, и результаты теоретических исследований активно внедряются в коммерческие СУБД.
Появляются первые языки высокого уровня для работы с реляционной моделью данных. Однако отсутствуют стандарты для этих первых языков.
Эпоха персональных компьютеров
Персональные компьютеры стремительно ворвались в нашу жизнь и буквально перевернули наше представление о месте и роли вычислительной техники в жизни общества. Теперь компьютеры стали ближе и доступнее каждому пользователю. Исчез благоговейный страх рядовых пользователей перед непонятными и сложными языками программирования. Появилось множество программ, предназначенных для работы неподготовленных пользователей. Эти программы были просты в использовании и интуитивно понятны: это прежде всего различные редакторы текстов, электронные таблицы и другие. Простыми и понятными стали операции копирования файлов и перенос информации с одного компьютера на другой, распечатка текстов, таблиц и других документов. Системные программисты были отодвинуты на второй план. Каждый пользователь мог себя почувствовать полным хозяином этого мощного и удобного устройства, позволяющего автоматизировать многие аспекты деятельности. И, конечно, это сказалось и на работе с базами данных. Появились программы, которые назывались системами управления базами данных и позволяли хранить значительные объемы информации, они имели удобный интерфейс для заполнения данных, встроенные средства для генерации различных отчетов. Эти программы позволяли автоматизировать многие учетные функции, которые раньше велись вручную. Постоянное снижение цен на персональные компьютеры сделало их доступными не только для организаций и фирм, но и для отдельных пользователей. Компьютеры стали инструментом для ведения документации и собственных учетных функций. Это все сыграло как положительную, так и отрицательную роль в области развития баз данных. Кажущаяся простота и доступность персональных компьютеров и их программного обеспечения породила множество дилетантов. Эти разработчики, считая себя знатоками, стали проектировать недолговечные базы данных , которые не учитывали многих особенностей объектов реального мира. Много было создано систем-однодневок, которые не отвечали законам развития и взаимосвязи реальных объектов. Однако доступность персональных компьютеров заставила пользователей из многих областей знаний, которые ранее не применяли вычислительную технику в своей деятельности, обратиться к ним. И спрос на развитые удобные программы обработки данных заставлял поставщиков программного обеспечения поставлять все новые системы, которые принято называть настольными (desktop) СУБД . Значительная конкуренция среди поставщиков заставляла совершенствовать эти системы, предлагая новые возможности, улучшая интерфейс и быстродействие систем, снижая их стоимость . Наличие на рынке большого числа СУБД , выполняющих сходные функции, потребовало разработки методов экспорта-импорта данных для этих систем и открытия форматов хранения данных.
Но и в этот период появлялись любители, которые вопреки здравому смыслу разрабатывали собственные СУБД , используя стандартные языки программирования. Это был тупиковый вариант, потому что дальнейшее развитие показало, что перенести данные из нестандартных форматов в новые СУБД было гораздо труднее, а в некоторых случаях требовало таких трудозатрат, что легче было бы все разработать заново, но данные все равно надо было переносить на новую более перспективную СУБД . И это тоже было результатом недооценки тех функций, которые должна была выполнять СУБД .
Особенности этого этапа следующие:
- Все СУБД были рассчитаны на создание БД в основном с монопольным доступом. И это понятно. Компьютер персональный, он не был подсоединен к сети, и база данных на нем создавалась для работы одного пользователя. В редких случаях предполагалась последовательная работа нескольких пользователей, например, сначала оператор, который вводил бухгалтерские документы, а потом главбух, который определял проводки, соответствующие первичным документам.
- Большинство СУБД имели развитый и удобный пользовательский интерфейс. В большинстве существовал интерактивный режим работы с БД как в рамках описания БД, так и в рамках проектирования запросов. Кроме того, большинство СУБД предлагали развитый и удобный инструментарий для разработки готовых приложений без программирования. Инструментальная среда состояла из готовых элементов приложения в виде шаблонов экранных форм, отчетов, этикеток (Labels), графических конструкторов запросов, которые достаточно просто могли быть собраны в единый комплекс.
- Во всех настольных СУБД поддерживался только внешний уровень представления реляционной модели, то есть только внешний табличный вид структур данных.
- При наличии высокоуровневых языков манипулирования данными типа реляционной алгебры и SQL в настольных СУБД поддерживались низкоуровневые языки манипулирования данными на уровне отдельных строк таблиц.
- В настольных СУБД отсутствовали средства поддержки ссылочной и структурной целостности базы данных. Эти функции должны были выполнять приложения, однако скудость средств разработки приложений иногда не позволяла это сделать, и в этом случае эти функции должны были выполняться пользователем, требуя от него дополнительного контроля при вводе и изменении информации, хранящейся в БД.
- Наличие монопольного режима работы фактически привело к вырождению функций администрирования БД и в связи с этим — к отсутствию инструментальных средств администрирования БД.
- И, наконец, последняя и в настоящий момент весьма положительная особенность — это сравнительно скромные требования к аппаратному обеспечению со стороны настольных СУБД. Вполне работоспособные приложения, разработанные, например, на Clipper, работали на PC 286.
- В принципе, их даже трудно назвать полноценными СУБД. Яркие представители этого семейства — очень широко использовавшиеся до недавнего времени СУБД Dbase (DbaseIII+, DbaseIV), FoxPro, Clipper, Paradox.
Распределенные базы данных
Хорошо известно, что история развивается по спирали, поэтому после процесса "персонализации" начался обратный процесс — интеграция . Множится количество локальных сетей, все больше информации передается между компьютерами, остро встает задача согласованности данных, хранящихся и обрабатывающихся в разных местах, но логически друг с другом связанных, возникают задачи, связанные с параллельной обработкой транзакций — последовательностей операций над БД , переводящих ее из одного непротиворечивого состояния в другое непротиворечивое состояние. Успешное решение этих задач приводит к появлению распределенных баз данных,сохраняющих все преимущества настольных СУБД и в то же время позволяющих организовать параллельную обработку информации и поддержку целостности БД .
Особенности данного этапа:
- Практически все современные СУБД обеспечивают поддержку полной реляционной модели, а именно:
- О структурной целостности — допустимыми являются только данные, представленные в виде отношений реляционной модели;
- О языковой целостности, то есть языков манипулирования данными высокого уровня (в основном SQL);
- О ссылочной целостности, контроля за соблюдением ссылочной целостности в течение всего времени функционирования системы, и гарантий невозможности со стороны СУБД нарушить эти ограничения.
Перспективы развития систем управления базами данных
Этот этап характеризуется появлением новой технологии доступа к данным — интранет.Основное отличие этого подхода от технологии клиент-сервер состоит в том, что отпадает необходимость использования специализированного клиентского программного обеспечения. Для работы с удаленной базой данных используется стандартный браузер Интернета, например Microsoft Internet Explorer или Netscape Navigator, и для конечного пользователя процесс обращения к данным происходит аналогично скольжению по Всемирной Паутине (см. рис. 1.1). При этом встроенный в загружаемые пользователем HTML-страницы код, написанный обычно на языке Java , Java -script, Perl и других, отслеживает все действия пользователя и транслирует их в низкоуровневые SQL-запросы к базе данных, выполняя, таким образом, ту работу, которой в технологии клиент-сервер занимается клиентская программа . Удобство данного подхода привело к тому, что он стал использоваться не только для удаленного доступа к базам данных, но и для пользователей локальной сети предприятия. Простые задачи обработки данных, не связанные со сложными алгоритмами, требующими согласованного изменения данных во многих взаимосвязанных объектах, достаточно просто и эффективно могут быть построены по данной архитектуре. В этом случае для подключения нового пользователя к возможности использовать данную задачу не требуется установка дополнительного клиентского программного обеспечения. Однако алгоритмически сложные задачи рекомендуется реализовывать в архитектуре " клиент-сервер " с разработкой специального клиентского программного обеспечения.
У каждого из вышеперечисленных подходов к работе с данными есть свои достоинства и свои недостатки, которые и определяют область применения того или иного метода, и в настоящее время все подходы широко используются.
Читайте также: