8. Выбор субд. Факторы, влияющие на выбор. Основные субд, представленные на рынке программного обеспечения: Clipper, dBase, Oracle, paradox, Access, стандарты codasyl и sql.

Система управления базами данных (СУБД) – это важнейший компонент АИС, основанной на базе данных. СУБД необходима для создания и поддержки базы данных информационной системы в той же степени, как для разработки программы на алгоритмическом языке – транслятор. Программные составляющие СУБД включают в себя ядро и сервисные средства (утилиты).

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

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

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

Для инициализации базы данных разработчик средствами конкретной СУБД описывает логическую структуру БД, её организацию в среде хранения и представления данных пользователями (соответственно концептуальную схему БД, схему хранения и внешние схемы). Обрабатывая эти схемы, СУБД создаёт пустую БД требуемой структуры и предоставляет средства для наполнения её данными о предметной области и дальнейшей эксплуатации.

Классификация СУБД

*По степени универсальности СУБД делят на два класса: СУБД общего назначения (СУБД ОН) и специализированные СУБД (СпСУБД).

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

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

1.     за счёт знания особенностей конкретной предметной области,

2.     путём сокращения функциональной полноты системы.

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

*По модели данных различают иерархические, сетевые, реляционные и объектно-ориентированные СУБД.

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

Основные функции СУБД

1.     Хранение, извлечение и обработка данных.

2.     Наличие языка обработки данных.

3.     Наличие доступного пользовательского каталога данных.

4.     Поддержка многопользовательского режима доступа.

5.     Обеспечение логической независимости данных.

6.     Обеспечение физической независимости данных.

7.     Обеспечение логической целостности БД.

8.     Обеспечение физической целостности данных.

9.     Управление доступом.

10. Настройка СУБД.

Система управления базами данных (СУБД) является программой, которая управляет всем доступом к базе данных по следующей схеме:      1) пользователь посылает запрос на доступ, используя конкретный язык;      2) СУБД воспринимает запрос и интерпретирует его;      3) СУБД анализирует по очереди внешнюю схему, отображение "внешний-концептуальный", концептуальную схему, отображениe "концептуальный-внутренний" и определение структуры хранения;      4) СУБД выполняет необходимые операции над хранимой базой данных.

Осн.сравнительные хар-ки СУБД: 1. Производительность: - время выполнения запроса, - скорость поиска в полях, - время выполнения операции импортирования из других форматов, - скорость создания индексов и выполнение массовых операций обновления, вставки, удаления, - максимальное число параллельного обращения к данным в многопользовательском режиме, - время генерации отчетов. 2. Обеспечение целостности данных на уровне БД(показывает наличие средств, позволяющих убедиться в корректности и полноте информации). 3. Обеспечение безопасности: шифрование программ и данных, защита паролями, ограничение уровней доступа. 4. работа в многопользовательском режиме: - блокировка всех уровней: БД, файл, таблица, запись, поле, - идентификация станций, - обновление информации после модификации, - контроль за временем и повторным обращением, - обработка транзакций, - возможность работы с сетевыми системами. 5. Наличие импорта/экспорта и его реализация: - возможность обработки СУБД информации подготовленной в другой системе, - возможность передачи в другие системы. 6. Доступ данным на основе SQL (Структурный язык запроса). 7. Возможность запросов из инструментальных средств обработки. 8. Мощность: объем БД, кол-во записей, таблиц, полей, длина записи.

8. Распределенные и локальные БД. Администрирование БД. Процедуры администрирования. Секретность и безопасность данных, идентификация пользователей, управление доступом, статистическая обработка, физическая защита данных, оптимизация запросов.

Архитектура "клиент-сервер" обеспечивает простое и относительно дешевое решение проблемы коллективного доступа к БД в локальной сети. Сист БД, основанные на архитектуре "клиент-сервер", яв-ся приближением к распределенным сист БД, конечно, существенно упрощенным приближением, но зато не требующим решения основного набора проблем действительно РБД. Основная задача СУРБД состоит в обеспечении средства интеграции локальных БД, располагающихся в некоторых узлах выч сети, с тем, чтобы пользователь, работающий в любом узле сети, имел доступ ко всем этим БД как к единой БД. При этом должны обеспечиваться: простота использования системы; возможности автономного функционирования при нарушениях связности сети или при административных потребностях; высокая степень эффективности. Разновидности распределенных систем: однородные и неоднородные. В однородном случае каждая локальная база данных управляется одной и той же СУБД. В неоднородной системе локальные базы данных могут относиться даже к разным моделям данных. Сетевая интеграция неоднородных баз данных - это актуальная, но очень сложная проблема. Многие решения известны на теоретическом уровне. Преимущества и недостатки РБД. Преимущества: РБД позволяет совместить децентрализованные и централизован­ные системы, т.е. есть возможность распределения нагрузки между различными компо­нентами системы. РБД обладает лучшими адаптивными свойствами и меньшей чувст­вительностью к выходу из строя отдельных компонентов. Недостатки: В РСУБД больше функций, чем в обычной СУБД. Проблемы синхронизации при обработке поисковых и корректирующих запросов. Сложная задача проектирования БД как на логическом, так и на физическом уровнях. В РБД часто появляются дополнительные уровни модели данных Þ увеличивается время обработки. Основ-я д/распред данных: данные исп-ся на 1 участке и нигде более; передача данных дорогая; необходимость обеспеч точности, секретности, надежности в одном месте; файлы БД достаточно просты и исп-ся одним или несколькими приложениями; частота обновлений высока для единой централизо­ванной БД; чрезвычайно велико число операций поиска и манипулир-я данных. Основ-я д/централиз данных: данные исп-ся централиз приложениями; пользов-лю треб-ся свежая версия часто обновляемых данных (срочно!); данные н д/поиска все сразу; Стр-ра данных ориентированна так, чтобы обслужить мн-во приложений одновременно; данные д б хор защищены.; объем данных исп-х д/обработки и обслуживания чрезвы­чайно велики. Основ-я д/многих копий одних данных: стоимость передачи высока; время доступа необх сократить; сущ. специфика методов доступа и организации исп-я данных; высокая стоимость преобразования данных. Основные проблемы с РБД и многими копиями: взаимные помехи обновления; возможность появл противореч данных; частая блокировка доступа данных; протокольные перегрузки; сложность восстановления БД; различия представления одних данных; сложность защиты и обес­печения секретности данных.

Принципы взаимодействия между клиентскими и серверными частями

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

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

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

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

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

Преимущества протоколов удаленного вызова процедур

Протоколы удаленного вызова процедур особенно важны в системах управления базами данных, основанных на архитектуре "клиент-сервер".

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

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

Типичное разделение функций между клиентами и серверами

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

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

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

Функции администратора АБД:

1. анализ предметной области.

2. проектирование стр-ры БД.

3. задание ограничения целостности.

4. первоначальная загрузка и введение БД.

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

6. обеспеч восстановл БД.

7. Анализ обращ польз-лей к БД.

8. Анализ эффект функционир-я БнД.

9. Работа с пользователями.

10.Подготовка и поддержка сист программ ср-в, СУБД, ППП, ОС.

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

Обеспечение защиты данных

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

Безопасность данных (обеспечение физической защиты)

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

Наиболее типичными сбоями являются следующие:

1.     Пользовательские ошибки. Ошибки пользователей могут потребовать восстановления базы данных в состояние на момент возникновения ошибки. Например, пользователь может случайно удалить таблицу.

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

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

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

5.     Сбой носителя (диска). Эта ошибка может возникнуть при попытке записи или чтения файла, требуемого для работы базы данных. Типичным примером является отказ дисковой головки, который приводит к потере всех файлов на данном устройстве. Этот тип сбоя может касаться различных типов файлов, поддерживаемых СУБД. Кроме того, поскольку сервер не может продолжать работу, данные из буферов оперативной памяти не могут быть записаны в файлы данных.

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

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

Резервное копирование означает периодическое сохранение на ВЗУ файлов БД в момент, когда их состояние является непротиворечивым. Резервная копия не должна создаваться на том же диске, на котором находится сама БД, т.к. при аварии диска базу невозможно будет восстановить. Периодичность резервного копирования определяется администратором системы и зависит от многих факторов: объём БД, интенсивность запросов к БД, интенсивность обновления данных и др. В случае сбоя (или аварии диска) БД восстанавливается на основе последней копии. Все изменения, произведённые в данных после последнего копирования, утрачиваются; но при наличии журнала транзакций их можно выполнить ещё раз, обеспечив полное восстановление БД.

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

Полная резервная копия включает всю базу данных (все файлы БД, в том числе, вспомогательные, состав которых зависит от СУБД). Частичная резервная копия включает часть БД, определённую пользователем. В резервную копию входят только те блоки памяти, которые реально содержат данные (т.е. пустые блоки, выделенные под объекты БД, в резервную копию не входят).

Резервное копирование может быть полным и инкрементным. Полная копия (level 0 backup) включает все блоки данных БД или табличной области. Инкрементная копия состоит только из тех блоков, которые изменились со времени последнего резервного копирования. Создание инкрементной копии происходит быстрее, чем полной, но возможно только после проведения полного резервного копирования.

Обычно технология проведения резервного копирования такова:

*раз в неделю (день, месяц) осуществляется полное копирование;

*раз в день (час, неделю) проводится обновление копии (инкрементное копирование).

Защита от несанкционированного доступа

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

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

*классификация данных в соответствии с их использованием;

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

*организация системы контроля доступа к данным;

*тестирование вновь создаваемых средств защиты данных;

*периодическое проведение проверок правильности работы системы защиты, исследование и предотвращение сбоев в её работе.

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

Парольная идентификация заключается в присвоении каждому пользователю двух параметров: имени (login) и пароля (password). При входе в систему она запрашивает у пользователя его имя, а для подтверждения того, что это имя ввел его владелец, система запрашивает пароль. Имя выдаётся пользователю при регистрации администратором, а пароль пользователь устанавливает сам.

При задании пароля желательно соблюдать следующие требования:

*длина пароля должна быть не менее 6-и символов;

*пароль должен содержать комбинацию букв и цифр или специальных знаков, пароль не может содержать пробелы;

*пароли должны часто меняться.

Для обеспечения выполнения этих требований обычно применяются специальные программы.

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

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

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

Управление доступом к базе данных

Предоставление прав доступа (привилегий) в системах, поддерживающих язык SQL, осуществляется с помощью двух команд:

1.     GRANT – предоставление одной или нескольких привилегий пользователю (или группе пользователей).

2.     REVOKE – отмена привилегий.

Синтаксис этих команд зависит от СУБД.

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