Основные данные о работе

Содержание

Введение………………………………………………………………………………5

1. Характеристики СУБД………………………………………………………........6

1.1 Проблемы создания БД……………………………………………………….....8

1.2 Понятие систем управления базами данных и реляционной базы данных…9

2. Сервер базы данных……………………………………………………………..15

2.1 Технология и модели «клиент-сервер»……………………………………….15

2.2 Распределенные базы данных…………………………………………………20

2.3 Обзор СУБД…………………………………………………………………….24

Заключение………………………………………………………………………….29

Глоссарий…………………………………………………………………………...32

Список использованных источников……………………………………………..34

Приложении А……………………………………………………………………...35

Приложение Б………………………………………………………………………35

Введение

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

добавление новой информации в существующие файлы БД;

добавление новых пустых файлов в БД;

изменение (модификация) информации в существующих

файлах БД:

поиск информации в БД:

удаление информации hi существующих файлов БД:

удаление файлов из БД

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

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

            В архитектуре «файл – сервер» БД хранится на сервере, а СУБД устанавливаются на каждой ЭВМ. Производительность зависит от компьютера пользователя, при этом значительно загружается сеть для передачи данных.

В современных СУБД используется архитектура «клиент – сервер», когда БД хранится на сервере, а СУБД имеет клиентскую и серверную части.

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

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

Эти модели различаются в основном способами представления взаимосвязей между объектами. Старейшие системы основаны на иерархической модели данных. К ним относится, например, разработанная для больших ЭВМ СУБД «Ока». Сетевой является СУБД СЕТОР. Реляционными СУБД являются DB2, Oracle, Paradox, Access, FoxPro, MySQL и др.

Цель исследования заключается в изучении систем управления базами данных.      Логически в современной реляционной СУБД можно выделить наиболее внутреннюю часть – ядро СУБД (часто его называют Data Base Engine), компилятор языка БД (обычно SQL), подсистему поддержки времени выполнения, набор утилит. В некоторых системах эти части выделяются явно, в других – нет, но логически такое разделение можно провести во всех СУБД.

        Задачи исследования формируются, исходя из его цели, и заключаются в следующем: 1. Рассмотреть понятие систем управления базами данных и реляционной базы данных. 2. Определение критериев выбора СУБД. 3. Рассмотреть сервер базы данных, технологии и модели «клиент-сервер». 4. Изучить основные принципы работы некоторых классов СУБД.

Основная часть

1 Характеристики СУБД

1.1 Проблемы создания БД

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

Современные БД характеризуются следующими особенностями:

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

наличие подсистем, имеющих свои задачи и цели функционирования (например, связанные со сбором данных и решением регламентных задач);

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

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

функционирование на нескольких аппаратных платформах;

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

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

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

Проблемы создания БД связаны с неверно сформулированными требованиями к БД;

недостаточным тестированием данных и плохой их интеграцией;

ошибками проектирования БД (программные средства готовы, а содержания БД нет);

ошибками в планировании работ над проектом и некачественным внедрением БД (нет средств поддержки актуальности данных);

плохим управлением БД;

неверным выбором коммерческого программного обеспечения для реализации БД (оно слишком сложное или не позволяет решать некоторые задачи);

плохой связью с источниками данных для БД.

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

Классы задач нужно разделять, т.к. от того, какие задачи признаются приоритетными, зависит последовательность разработки и внедрения. И все они, действительно, важны для деятельности заказчика. Но любой системный аналитик знает старый афоризм: "То, что говорит пользователь о своих потребностях – это не совсем то, что он думает, а то, что он думает – это совсем не то, что ему нужно на самом деле"[1]. К ним можно отнести снижение операционных издержек за счет автоматизации рутинных операций, повышение производительности труда и внедрения автоматизированных систем контроля выполнения операций. Эти задачи решаются путем создания автоматизированных рабочих мест (АРМ), обеспечивающих максимально возможный сервис их пользователям. Естественно, невозможно обеспечить накопление информации, не разработав удобные АРМ для тех работников, которые должны вводить эту информацию в БД, приложения для доступа и визуализации информации также можно рассматривать как АРМы, и, конечно, их работа невозможна без БД.

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

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

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

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

В идеале БД должна замыкать на себя всю деятельность сотрудников компании. Мерой полноты БД может служить соотношение времени, которое сотрудники проводят в среде СУБД.

1.2 Понятие систем управления базами данных и реляционной базы данных

Важнейшая задача компьютерных систем – хранение и обработка данных. Для ее решения были предприняты усилия, которые привели к появлению в конце 60-х – начале 70-х годов специализированного программного обеспечения – систем управления базами данных (database management systems).

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

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

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

Одна из главных тенденций развития серверов БД – усиление их активной роли в модели взаимодействия «клиент-сервер». Эта идея была вызвана к жизни реальными практическими задачами, возникающими в самых различных областях информационной деятельности человека. Традиционное же решение этих задач в системах с пассивным сервером было громоздким и неэффективным и не удовлетворяло современным требованиям. Поэтому сегодня все аргументы – в пользу активного сервера БД.

Было бы ошибкой считать, что в базе данных отражаются только физические объекты. Она способна вобрать в себя сведения об абстракциях, процессах, явлениях – то есть обо всем, с чем сталкивается человек в своей деятельности. Так, например, в базе данных можно хранить информацию о заказах на поставку деталей на склад (хотя он – не физический объект, а процесс). Атрибутами сущности «заказ» будут название поставляемой детали, количество деталей, название поставщика, срок поставки и т.д.

Каждый признак конкретного объекта есть значение атрибута. Так, деталь «двигатель» имеет значение атрибута «вес», равное «50», что отражает тот факт, что данный двигатель весит 50 килограммов.

Часто, говоря о базе данных, имеют в виду просто некоторое автоматизированное хранилище данных. Такое представление не вполне корректно. Действительно, в узком смысле слова, база данных – это некоторый набор данных, необходимых для работы (актуальные данные). Однако данные – это абстракция; никто никогда не видел «просто данные»; они не возникают и не существуют сами по себе. Данные суть отражение объектов реального мира. Пусть, например, требуется хранить сведения о деталях, поступивших на склад. Как объект реального мира — деталь — будет отображена в базе данных. Для того чтобы ответить на этот вопрос, необходимо знать, какие признаки или стороны детали будут актуальны, необходимы для работы. Среди них могут быть название детали, ее вес, размеры, цвет, дата изготовления, материал, из которого она сделана и т.д. В традиционной терминологии объекты реального мира, сведения о которых хранятся в базе данных, называются сущностями – entities (общепринятый термин), а их актуальные признаки – атрибутами (attributes)[3].

Объекты реального мира связаны друг с другом множеством сложных зависимостей, которые необходимо учитывать в информационной деятельности. Например, детали на склад поставляются их производителями. Следовательно, в число атрибутов детали необходимо включить атрибут «название фирмы-производителя». Однако этого недостаточно, так как могут понадобиться дополнительные сведения о производителе конкретной детали – его адрес, номер телефона и т.д. Значит, база данных должна содержать не только информацию о деталях и заказах на поставку, но и сведения об их производителях. Более того, база данных должна отражать связи между деталями и производителями (каждая деталь выпускается конкретным производителем) и между заказами и деталями (каждый заказ оформляется на конкретную деталь). Отметим, что в базе данных нужно хранить только актуальные, значимые связи.

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

Реляционная модель данных. Итак, получили представление о том, что хранится в базе данных. Теперь необходимо рассмотреть, как сущности, атрибуты и связи отображаются на структуры данных. Это определяется моделью данных.Таким образом, в широком смысле слова база данных — это совокупность описаний объектов реального мира и связей между ними, актуальных для конкретной прикладной области.

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

Она была разработана Коддом еще в 1969-70 годах на основе математической теории отношений и опирается на систему понятий, важнейшими из которых являются таблица, отношение, строка, столбец, первичный ключ, внешний ключ.

Реляционной считается такая база данных, в которой все данные представлены для пользователя в виде прямоугольных таблиц значений данных, и все операции над базой данных сводятся к манипуляциям с таблицами. Таблица состоит из строк и столбцов и имеет имя, уникальное внутри базы данных. Таблица отражает тип объекта реального мира (сущность), а каждая ее строка – конкретный объект. Так, таблица Деталь содержит сведения о всех деталях, хранящихся на складе, а ее строки являются наборами значений атрибутов конкретных деталей. Каждый столбец таблицы – это совокупность значений конкретного атрибута объекта. Так, столбец «материал» представляет собой множество значений «Сталь», «Олово», «Цинк», «Никель» и т.д. В столбце «количество» содержатся целые неотрицательные числа. Значения в столбце Вес – вещественные числа, равные весу детали в килограммах.

Эти значения не появляются из воздуха. Они выбираются из множества всех возможных значений атрибута объекта, которое называется доменом (domain). Так, значения в столбце материал выбираются из множества имен всех возможных материалов – пластмасс, древесины, металлов и т.д. Следовательно, в столбце «материал» принципиально невозможно появление значения, которого нет в соответствующем домене, например, «вода» или «песок».

Каждый столбец имеет имя, которое обычно записывается в верхней части таблицы (см. рисунок 1. Приложение А). Оно должно быть уникальным в таблице, однако различные таблицы могут иметь столбцы с одинаковыми именами. Любая таблица должна иметь, по крайней мере, один столбец; столбцы расположены в таблице в соответствии с порядком следования их имен при ее создании. В отличие от столбцов, строки не имеют имен; порядок их следования в таблице не определен, а количество логически не ограничено.

Так как строки в таблице не упорядочены, невозможно выбрать строку по ее позиции – среди них не существует «первой», «второй», «последней». Любая таблица имеет один или несколько столбцов, значения в которых однозначно идентифицируют каждую ее строку. Такой столбец (или комбинация столбцов) называется первичным ключом (primary key). В таблице Деталь первичный ключ – это столбец Номер детали. В нашем примере каждая деталь на складе имеет единственный номер, по которому из таблицы Деталь извлекается необходимая информация. Следовательно, в этой таблице первичный ключ – это столбец Номер детали. В этом столбце значения не могут дублироваться– в таблице Деталь не должно быть строк, имеющих одно и то же значение в столбце Номер детали. Если таблица удовлетворяет этому требованию, она называется отношением (relation).

Взаимосвязь таблиц является важнейшим элементом реляционной модели данных. Она поддерживается внешними ключами (foreign key)[4]. Рассмотрим пример, в котором база данных хранит информацию о рядовых служащих (таблица Служащий) и руководителях (таблица Руководитель) в некоторой организации (см. рисунок 2.Приложение А)). Первичный ключ таблицы Руководитель – столбец Номер (например, табельный номер). Столбец Фамилия не может выполнять роль первичного ключа, так как в одной организации могут работать два руководителя с одинаковыми фамилиями. Любой служащий подчинен единственному руководителю, что должно быть отражено в базе данных. Таблица Служащий содержит столбец Номер руководителя, и значения в этом столбце выбираются из столбца Номер таблицы Руководитель (см. рисунок 3. Приложение А). Столбец Номер Руководителя является внешним ключом в таблице Служащий.

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

Таблицы невозможно хранить и обрабатывать, если в базе данных отсутствуют «данные о данных», например, описатели таблиц, столбцов и т.д. Их называют обычно метаданными. Метаданные также представлены в табличной форме и хранятся в словаре данных (data dictionary).Помимо таблиц, в базе данных могут храниться и другие объекты, такие как экранные формы, отчеты (reports), представления (views) и даже прикладные программы, работающие с базой данных.

Для того, чтобы гарантировать корректность и взаимную непротиворечивость данных, на базу данных накладываются некоторые ограничения, которые называют ограничениями целостности (data integrity constraints).

Существует несколько типов ограничений целостности. Требуется, например, чтобы значения в столбце таблицы выбирались только из соответствующего домена. На практике учитывают и более сложные ограничения целостности, например, целостность по ссылкам (referential integrity). Ее суть заключается в том, что внешний ключ не может быть указателем на несуществующую строку в таблице. Ограничения целостности реализуются с помощью специальных средств – сервера базы данных.

Язык SQL. Сами по себе данные в компьютерной форме не представляют интерес для пользователя, если отсутствуют средства доступа к ним. Доступ к данным осуществляется в виде запросов к базе данных, которые формулируются на стандартном языке запросов. Сегодня для большинства СУБД таким языком является SQL. Появление и развития этого языка как средства описания доступа к базе данных связано с созданием теории реляционных баз данных. Прообраз языка SQL возник в 1970 году в рамках научно-исследовательского проекта System/R, работа над которым велась в лаборатории Санта-Тереза фирмы IBM. Ныне SQL – это стандарт интерфейса с реляционными СУБД. Популярность его настолько велика, что разработчики нереляционных СУБД (например, Adabas), снабжают свои системы SQL-интерейсом.

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

2. Сервер базы данных

2.1 Технология и модели «клиент-сервер»

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

«Клиент-сервер» – это модель взаимодействия компьютеров в сети. Как правило, компьютеры не являются равноправными. Каждый из них имеет свое, отличное от других, назначение, играет определенную роль. Некоторые компьютеры в сети владеют и распоряжаются информационно-вычислительными ресурсами, такими как процессоры, файловая система, почтовая служба, служба печати, база данных. Другие имеют возможность обращаться к этим службам, пользуясь услугами первых. Компьютер, управляющий тем или иным ресурсом, принято называть сервером этого ресурса, а компьютер, желающий им воспользоваться – клиентом. Конкретный сервер определяется видом ресурса, которым он владеет. Так, если ресурсом являются базы данных, то речь идет о сервере баз данных, назначение которого – обслуживать запросы клиентов, связанные с обработкой данных; если ресурс – это файловая система, то говорят о файловом сервере или файл-сервере и т.д.

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

Первоначально СУБД имели централизованную архитектуру (см. рисунок 4. Приложение А). В ней сама СУБД и прикладные программы, которые работали с базами данных, функционировали на центральном компьютере (большая ЭВМ или мини-компьютер). Там же располагались базы данных. К центральному компьютеру были подключены терминалы, выступавшие в качестве рабочих мест пользователей. Все процессы, связанные с обработкой данных, выполнялись на центральном компьютере, что предъявляло жесткие требования к его производительности. Особенности СУБД первого поколения напрямую связаны с архитектурой больших ЭВМ и мини-компьютеров и адекватно отражают все их преимущества и недостатки. Для более четкого представления об особенностях архитектуры «клиент-сервер» необходимо рассмотреть несколько моделей технологии «клиент-сервер».

Основной принцип технологии «клиент-сервер» заключается в разделении функций стандартного интерактивного приложения на четыре группы, имеющие различную природу. Первая группа – это функции ввода и отображения данных. Вторая группа объединяет чисто прикладные функции, характерные для данной предметной области (например, для банковской системы – открытие счета, перевод денег с одного счета на другой и т.д.). К третьей группе относятся фундаментальные функции хранения и управления информационными ресурсами (базами данных, файловыми системами и т.д.). Наконец, функции четвертой группы – служебные, играющие роль связок между функциями первых трех групп.

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

Если предполагается, что проектируемая информационная система (ИС) будет построена по технологии «клиент-сервер», то это означает, что прикладные программы, реализованные в ее рамках, будут иметь распределенный характер.

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

Выделяются четыре подхода, реализованные в следующих моделях: модель файлового сервера (File Server – FS); модель доступа к удаленным данным (Remote Data Access – RDA); модель севера базы данных (DataBase Server – DBS); модель сервера приложений (Application Server – AS).

FS-модель является базовой для локальных сетей персональных компьютеров. Суть модели проста и всем известна. Один из компьютеров в сети считается файловым сервером и предоставляет услуги по обработке файлов другим компьютерам. Файловый сервер работает под управлением сетевой операционной системы (например, Novell NetWare) и играет роль компонента доступа к информационным ресурсам (то есть к файлам). На других компьютерах в сети функционирует приложение, в кодах которого совмещены компонент представления и прикладной компонент[7] (см.рисунок 5. Приложение А). Протокол обмена представляет собой набор низкоуровневых вызовов, обеспечивающих приложению доступ к файловой системе на файл-сервере.

К технологическим недостаткам модели относят высокий сетевой трафик (передача множества файлов, необходимых приложению), узкий спектр операций манипулирования данными («данные – это файлы»), отсутствие адекватных средств безопасности доступа к данным (защита только на уровне файловой системы) и т.д. Собственно, перечисленное не есть недостатки, но – следствие внутренне присущих FS-модели ограничений, определяемых ее характером. Недоразумения возникают в том случае, когда FS-модель используют не по назначению – например, пытаются интерпретировать как модель сервера базы данных. Место FS-модели в иерархии моделей «клиент-сервер» – это место модели файлового сервера и ничего более.

Более технологичная RDA-модель существенно отличается от FS-модели характером компонента доступа к информационным ресурсам. Это, как правило, SQL-сервер. В RDA-модели коды компонента представления и прикладного компонента совмещены и выполняются на компьютере-клиенте. Последний поддерживает как функции ввода и отображения данных, так и чисто прикладные функции. Доступ к информационным ресурсам обеспечивается либо операторами специального языка (языка SQL, например, если речь идет о базах данных) или вызовами функций специальной библиотеки (если имеется соответствующий интерфейс прикладного программирования – API).

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

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

Прежде всего, перенос компонента представления и прикладного компонента на компьютеры-клиенты существенно разгружает сервер БД, минимизируя общее число процессов операционной системы. Сервер БД освобождается от несвойственных ему функций; процессор или процессоры сервера целиком загружаются операциями обработки данных, запросов и транзакций. Это становится возможным благодаря отказу от терминалов и оснащению рабочих мест компьютерами, которые обладают собственными локальными вычислительными ресурсами, полностью используемыми программами переднего плана. С другой стороны, резко уменьшается загрузка сети, так как по ней передаются от клиента к серверу не запросы на ввод-вывод (как в системах с файловым сервером), а запросы на языке SQL, а их объем существенно меньше[8].

Основное достоинство RDA-модели заключается в унификации интерфейса «клиент-сервер» в виде языка SQL, поэтому было бы целесообразно использовать его не только в качестве средства доступа к данным, но и как стандарта общения клиента и сервера.

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

Наряду с RDA-моделью все большую популярность приобретает перспективная DBS-модель (см. Рисунок 6. Приложение А). Последняя реализована в некоторых реляционных СУБД (Informix, Ingres, Sybase, Oracle). Ее основу составляет механизм хранимых процедур – средство программирования SQL-сервера. Процедуры хранятся в словаре базы данных, разделяются между несколькими клиентами и выполняются на том же компьютере, где функционирует SQL-сервер. Язык, на котором разрабатываются хранимые процедуры, представляет собой процедурное расширение языка запросов SQL и уникален для каждой конкретной СУБД.

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

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

В AS-модели (см. Рисунок 7. Приложение А) процесс, выполняющийся на компьютере-клиенте, отвечает, обычно за интерфейс с пользователем (то есть реализует функции первой группы). Обращаясь за выполнением услуг к прикладному компоненту, этот процесс играет роль клиента приложения (Application Client – AC). Прикладной компонент реализован как группа процессов, выполняющих прикладные функции и называется сервером приложения (Application Server – AS).

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

RDA- и DBS-модели опираются на двухзвенную схему разделения функций. В RDA-модели прикладные функции приданы программе-клиенту, в DBS-модели ответственность за их выполнение берет на себя ядро СУБД. В первом случае прикладной компонент сливается с компонентом представления, во втором – интегрируется в компонент доступа к информационным ресурсам. В AS-модели реализована трехзвенная схема разделения функций, где прикладной компонент выделен как важнейший изолированный элемент приложения, для его определения используются универсальные механизмы многозадачной операционной системы, и стандартизованы интерфейсы с двумя другими компонентами. AS-модель является фундаментом для мониторов обработки транзакций (Transaction Processing Monitors – TPM), или, проще, мониторов транзакций, которые выделяются как особый вид программного обеспечения.

за управление реляционный клиент сервер

2.2 Распределенные базы данных

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

Решение проблемы сетевого взаимодействия клиента и сервера с помощью коммуникационного сервера является необходимым (но не достаточным) условием поддержки распределенных баз данных. Неразрешенными пока остаются следующие задачи: управление именами в распределенной среде; оптимизация распределенных запросов; управление распределенными транзакциями.

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

Глобальный словарь данных – это механизм отслеживания расположения объектов в распределенной БД. Данные могут храниться на локальном узле, на удаленном узле, или на обоих узлах – их расположение должно оставаться прозрачным как для конечного пользователя, так и для программ. Не нужно явным образом указывать место расположения данных – программа должна быть полностью независима от того, на каких узлах размещаются данные, с которыми она оперирует.

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

Для СУБД это качество означает следующее: способность приложений, созданных средствами разработки данной СУБД, оперировать над базами данных в «чужом» формате так, как будто это собственные базы данных; свойство СУБД, позволяющее ей служить в качестве поставщика данных для любых приложений, созданных средствами разработки третьих фирм, поддерживающих некоторый стандарт обращения к базам данных.

Первое достигается использованием шлюзов, второе – использованием интерфейса ODBC.

До сих пор мы рассматривали однородные базы данных, то есть БД в формате конкретной СУБД. В то же время СУБД может осуществлять доступ к БД в другом формате. Это делается с помощью шлюза. Например, СУБД Ingres получает доступ к базе данных в формате СУБД Rdb через специальный шлюз. Если СУБД Альфа осуществляет доступ к базе данных в формате Бета (или просто к базе данных Бета), то говорят, что Альфа имеет шлюз в Бета[10].

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

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

Отметим, что технология распределенных БД защищает инвестиции в программное обеспечение. Она может рассматриваться как «мост», перекинутый от mainframe-систем и нереляционных СУБД к современными профессиональным СУБД на платформе RISC-компьютеров. Она позволяет разрабатывать для них прикладные программы, обеспечивая им доступ к огромным массивам информации на больших ЭВМ, и тем самым гарантирует мягкий и безболезненный переход к новой платформе.

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

Тиражирование данных – это асинхронный перенос изменений объектов исходной базы данных (source database) в БД, принадлежащие различным узлам распределенной системы. Функции тиражирования данных выполняет специальный модуль СУБД – сервер тиражирования данных, называемый репликатором (replicator). Его задача – поддержка идентичности данных в принимающих базах данных (target database) данным в исходной БД. В качестве базиса для тиражирования выступает транзакция к БД. В то же время возможен перенос изменений группами транзакций, периодически или в некоторый момент времени, что дает возможность исследовать состояние принимающей БД на определенный момент времени[11].

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

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

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

Жизненность концепции тиражирования подтверждается опытом ее использования в области, предъявляющей повышенные требования к надежности – в сфере банковских информационных систем.

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

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

2.3 Обзор СУБД

Е.Ф.Кодд (E.F.Codd) в 1970 году сформулировал концепцию реляционной модели (relational model)баз данных. Ранее, до появления на рынке СУРБД DB2, доминирующее положение занимали иерархические (IMS) и сетевые (IDMS) модели. До появления этих моделей базы данных строились на базе файлов с последовательным доступом, «плоских» файлов (flat files). Для разработки программ доступа к таким базам данных использовались языки третьего поколения. До сих пор ещё встречаются построенные по этому принципу специализированные системы, которые функционируют на больших ЭВМ и мини-компьютерах. Группой Database Task Group (DTBG) был разработан стандарт CODASYL на такого рода базы данных), звание стандарта представляет собой аббревиатуру от Conference on Data System Languages-Конференция по языкам обработки данных.) Стандарт охватывал сетевые базы данных, сформулированные на основе языка COBOL, а IDMS представляла собой реализацию этого стандарта одной из фирм. Однако, начиная с 70-х годов, доминирующее положение на рынке занимает класс систем управления реляционными базами данных, типичными представителями которого являются программные продукты фирм Oracle, Sybase, Informix и Ingres.[12]

В настоящее время на передний план выходят объектно-ориентированные (ОО) СУБД, для которых имеется достаточно много секторов рынка приложений - интегрированные системы автоматизированного проектирования и управления технологическими процессами (САПР/АСУТП, в английской транскрипции- CAD/CAM), системы планирования производства и инжиниринга, мультимедийные системы и т.д. ООСУБД отличаются способностью работы с данными самых различных типов, наличием мощных средств обработки и совершенно новым механизмом выполнения транзакций. В борьбе за потребителя фирмы- изготовители реляционных СУБД разработали универсальные серверы, обладающие множеством объектно-ориентированных и мультимедийных функций, включая работу с различными типами данных – текстовыми, звуковыми, статическими и динамическими изображениями. Примером может служить Universal Server фирмы Oracle. . Кроме того, серверное ядро базы данных можно нарастить путём подключения средств работы с типами данных, определенными пользователями(user-defined), и расширяемыми (extensible) типами. Эти возможности включены и в Oracle8. Реляционные СУБД с такими функциями можно рассматривать как гибридные. Далее идут многомерные базы данных (Multi Dimensional Databases – MDD), которые также находят свою нишу на рынке. Базы данных подобного класса предлагают усложненный механизм индексации для приложений с множеством переменных, которые нуждаются в сложном многомерном доступе к данным, что практически невозможно реализовать в традиционных СУБД. Фирмы – производители СУБД, стремясь хоть немного приблизиться к требованиям MDD, предлагают потребителям программное обеспечение с более развитыми возможностями индексного доступа при помощи специальных технологий, в частности – с использованием битовых индексов (bitmapped indexes). Примером такого рода продукции может служить Express фирмы Oracle[13]. Пользователей СУБД можно разбить на три категории:

администратор сервера баз данных. Он ведает установкой, конфигурированием сервера, регистрацией пользователей, групп, ролей и т.п. Администратор сервера имеет имя ingres. Прямо или косвенно он обладает всеми привилегиями, которые имеют или могут иметь другие пользователи.

Характеристики некоторых СУБД даны в табл.1. приложения В.

Направление развития реляционных СУБД в последние годы заметно меняется. Если в предыдущее десятилетие они развивались, чтобы обеспечить быстрый доступ к алфавитно – цифровым данным, то теперь часто нужно хранить еще графические и звуковые данные. Существенно изменилась аппаратная среда – она стала сетевой. С развитием Web – технологий появилась необходимость поддерживать HTML – страницы, 3-, 4- и n-мерные данные. И все это можно создавать на основе БД.

Можно провести аналогию между пользователем ingres и администраторами баз данных с одной стороны, и суперпользователем операционной системы (root в случае ОС UNIX) и служебными пользователями (в ОС UNIX это могут быть bin, lp, uucp и т.д.) с другой стороны. Введение служебных пользователей позволяет администрировать функциональные подсистемы, не получая привилегий суперпользователя. Точно так же информацию, хранящуюся на сервере баз данных, можно разделить на отсеки, так что компрометация администратора одного отсека не означает обязательной компрометации другого.

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

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

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

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

                    Нетрудно понять, почему это так. Области. Является дополнительным средством деления информации на отсеки. На практике компонент "область" может действительно иметь географический смысл, обозначая, например, страну, к которой относятся данные.

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

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

      Заключение

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

Существующие СУБД поддерживают следующие технологии (и их комбинации) разработки приложений:

ручное кодирование программ (Clipper, FoxPro, Paradox);

создание текстов приложений с помощью генераторов (FoxApp в FoxPro, Personal Programmer в Paradox);

автоматическая генерация готового приложения методами визуального программирования (Delphi, Access, Paradox tor Windows). При ручном кодировании программисты вручную набирают текст программ приложений, после чего выполняют их отладку. Использование генераторов упрощает разработку приложений, поскольку при этом можно получать программный код без ручного набора. Генераторы приложений облегчают разработку основных элементов приложений (меню, экранных форм, запросов и т. д.), но зачастую не могут полностью исключить ручное кодирование. Использование средств визуального программирования позволяет в кратчайшие сроки создавать более надежные, привлекательные и эффективные приложения по сравнению с приложениями, полученными первыми двумя способами. Разработанное приложение обычно состоит из одного или нескольких файлов операционной системы.

Независимые приложения позволяют получать, например, СУБД FoxPro и система визуального программирования Delphi. Отметим, что с помощью средств Delphi обычно независимые приложения не разрабатывают, так как это достаточно трудоемкий процесс, а привлекают процессор баз данных BDE (Borland DataBase Engine), играющий роль ядра СУБД.

Во многих случаях приложение не может исполняться без среды СУБД. Режим интерпретации реализован во многих современных СУБД, например, Access, Visual FoxPro и Paradox, а также в СУБД недавнего прошлого, к примеру, FoxBase и FoxPro.

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

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

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

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

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

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

   Глоссарий

Список использованных источников

Приложения

28