Область применения СУБД

Будем рассматривать базу данных как некий набор связанных данных, а систему управления базами данных, или СУБД (Database Management System — DBMS), как программное обеспечение, которое управляет доступом к этой базе данных.

С примерами областей применения СУБД вы познакомились на первой лекции и лабораторной работе: торговля, учет товаров на складе, банковские операции, учет книг в библиотеке и т.п.

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

2.2. Ручные картотеки – файловые системы – современные СУБД.

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

Файловые системы – это набор программ, которые выполняют для пользователей некоторые операции, например, создание отчетов. Каждая программа определяет свои собственные данные и управляет ими.

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

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

§ Разделение и изоляция данных.

§ Дублирование данных.

§ Зависимость от данных.

§ Несовместимость файлов.

§ Фиксированные запросы/быстрое увеличение количества приложений.

Разделение и изоляция данных приводит к существенным затруднениям, когда необходимо организовать обработку информации в двух и более файлах. Дублирование данных. Из-за децентрализованной работы с данными, проводимой в каждом отделе независимо от других отделов, в файловой системе фактически поощряется бесконтрольное дублирование данных, и это, в принципе, неизбежно. Дублирование данных сопровождается неэкономным расходованием ресурсов, поскольку на ввод избыточных данных требуется затрачивать дополнительные время и деньги. Также дублирование данных может привести к нарушению их целостности. Может оказаться, что в двух разных отделах организации можно получить на один и тот же вопрос противоречивые ответы. Во многих случаях дублирование данных можно избежать совместным использованием файлов. Зависимость от данных приводит к большим затратам при изменении физической структуры записей файлов, которая, естественно, отражена в приложениях работающих с данными файлами. Например, после некоторого срока промышленной эксплуатации приложения выяснилось, что по вновь принятому законодательству номер банковского счета будет увеличен с 10 до 16 знаков. Чтобы выйти из создавшейся ситуации необходимо написать программу, которая отработает всего один раз. Она должна открыть исходный файл, создать временный файл с новой структурой записи, считать запись из исходного файла, преобразовать данные в новый формат и записать их во временный файл (эти действия следует выполнить для всех записей исходного файла), удалить исходный файл, присвоить временному файлу имя исходного. Несовместимость форматов файлов затрудняет обработку информации еще в большем объеме, чем разделение и изоляция данных. Она может быть следствием необходимости совместного использования данных двух локальных задач. Например, для этого понадобиться создавать программное обеспечение, которое бы конвертировало данные в один общий формат. После чего возможна их совместная обработка. Фиксированные запросы/быстрое увеличение количества приложений. файловые системы во многом зависят от программиста, потому что все требуемые запросы и отчеты должны быть созданы именно им. В результате события обычно развивались по одному из следующих двух сценариев. Во многих организациях типы создаваемых запросов и отчетов имели фиксированную форму, и не было никаких инструментов создания незапланированных или произвольных запросов, как к самим данным, так и к сведениям о том, какие типы данных доступны. В других организациях наблюдалось быстрое увеличение количества файлов и приложений. В конечном счете, наступал момент, когда сотрудники отдела ОД были просто не в состоянии справиться со всей этой работой с помощью имеющихся ресурсов.

Все перечисленные выше ограничения файловых систем являются следствием двух факторов.

1. Определение данных содержится внутри приложений, а не хранится отдельно и независимо от них.

2. Помимо приложений не предусмотрено никаких других инструментов доступа к данным и их обработки.

Для повышения эффективности работы стали использовать новый подход, а именно базу данных (database) и систему управления базами данных, или СУБД (Database Management System ­ DBMS).

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

Чтобы глубже вникнуть в суть этого понятия, рассмотрим его определение более внимательно. База данных — это единое, большое хранилище данных, которое однократно определяется, а затем используется одновременно многими пользователями из разных подразделений. Вместо разрозненных файлов с избыточными данными, здесь все данные собраны вместе с минимальной долей избыточности. База данных уже не принадлежит какому-либо единственному отделу, а является общим корпоративным ресурсом. Причем база данных хранит не только рабочие данные этой организации, но и их описания. По этой причине базу данных еще называют набором интегрированных записей с самоописанием. В совокупности, описание данных называется системным каталогом (system catalog), или словарем данных (data-dictionary), а сами элементы описания принято называть метаданными (meta-data), т.е. "данными о данных". Именно наличие самоописания данных в базе данных обеспечивает в ней независимость между программами и данными (program-data independents).

И, наконец, следует объяснить последний термин из определения базы данных, а именно понятие "логически связанный". При анализе информационных потребностей организации следует выделить сущности, атрибуты и связи. Сущностью (entity) называется отдельный тип объекта организации (человек, место или вещь, понятие или событие), который нужно представить в базе данных. Атрибутом (attribute) называется свойство, которое описывает некоторую характеристику описываемого объекта; связь (relationship) — это то, что объединяет несколько сущностей.

Подобная база данных представляет сущности, атрибуты и логические связи между объектами. Иначе говоря, база данных содержит логически связанные данные.

ПРЕИМУЩЕСТВА СУБД.

· Контроль за избыточностью данных.

· Непротиворечивость данных.

· Больше полезной информации при том же объеме хранимых данных.

· Совместное использование данных.

· Поддержка целостности данных.

· Повышенная безопасность.

· Применение стандартов.

· Повышение эффективности с ростом масштабов системы.

· Возможность нахождения компромисса при противоречивых требованиях.

· Повышение доступности данных и их готовности к работе.

· Улучшение показателей производительности.

· Упрощение сопровождения системы за счет независимости от данных.

· Улучшенное управление параллельностью.

· Развитые службы резервного копирования и восстановления.

НЕДОСТАТКИ СУБД.

· Сложность.

· Размер.

· Стоимость СУБД.

· Дополнительные затраты на аппаратное обеспечение.

· Затраты на преобразование.

· Производительность.

· Более серьезные последствия при выходе системы из строя.

2.3. Сравнение локальных СУБД с СУБД архитектуры клиент-сервер.

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

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

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

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

· локальные СУБД используют так называемый "навигационный подход", ориентированный на работу с отдельными записями;

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

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

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

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

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

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

· снижается сетевой трафик за счет посылки сервером клиенту только тех данных, которые он запрашивал; например, если необходимо сделать из таблицы объемом 10 000 записей выборку, результатом которой будут всего 2 записи, сервер выполнит запрос и перешлет клиенту набор данных из 2 записей;

· упрощается наращивание вычислительных мощностей в условиях развития программного обеспечения и возрастания объемов обрабатываемых данных: проще и дешевле усилить мощности на сетевом сервере или полностью заменить сервер на более мощный, нежели наращивать мощности или полностью заменять 100-500 клиентских компьютеров;

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

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

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

Дата добавления: 2014-01-05