Должны быть организованны в базы данных с целью адекватного отображения изменяющегося реального мира и удовлетворения информационных потребностей пользователей
| Вид материала | Документы |
- Тавом объектов отражаемой предметной области, задач, данных и совокупностью информационных, 72.92kb.
- Минск, Республика Беларусь, 75.18kb.
- Курсовая работа по базам данных (6-й семестр) Возможна постановка задачи в области, 107.15kb.
- Варианты предметных областей для курсовой работы по дисциплине «Базы данных и информационные, 245.82kb.
- Социальные проблемы, чтобы быть включенными в политические решения, должны быть достаточно, 1302.99kb.
- Методические указания к курсовому проектированию по курсу "Базы данных" Составитель:, 602.97kb.
- Понятия о базах данных и системах управления ими. Классификация баз данных. Основные, 222.31kb.
- Темы курсовых проектов по курсу «Базы данных» Целью курсового проектирования, 40.32kb.
- Учебное пособие основы проектирования реляционных баз данных оглавление глава Что такое, 1134.27kb.
- Учебное пособие основы проектирования реляционных баз данных в. В. Кириллов оглавление, 888.41kb.
ОАО «Насление отечества»
Информационно-аналитический портал «Современная Россия»
Под общей редакцией Алексея Подберезкина
База данных «Современная Россия»
Руководитель проекта: Александр Немченко
Авторский коллектив: Анна Больботенко
Сергей Голубев
Екатерина Немченко
Игорь Подберезкин
Александр Царьков
Константин Чернов
г. Москва
2002
АННОТАЦИЯ.
Основные идеи современной информационной технологии базируются на концепции, согласно которой данные должны быть организованны в базы данных с целью адекватного отображения изменяющегося реального мира и удовлетворения информационных потребностей пользователей. Эти базы данных создаются и функционируют под управлением специальных программных комплексов, называемых системами управления базами данных (СУБД).
Данная работа посвящена разработке базы данных «Современная Россия». База данных выполнена на основе PHP 4.1.2. и MySQL 3-23-49-max, и имеет современный интерфейс с возможностями гипертекста, что позволяет легко пользоваться им людям с минимальными навыками работы на персональных ЭВМ.
Увеличение объема и структурной сложности, хранимых данных, расширение круга пользователей информационных систем привели к широкому распространению наиболее удобных и сравнительно простых для понимания реляционных (табличных) СУБД. Для обеспечения одновременного доступа к данным множества пользователей, нередко расположенных достаточно далеко друг от друга и от места хранения баз данных, созданы сетевые мультипользовательские версии СУБД. В них тем или иным путем решаются специфические проблемы параллельных процессов, целостности (правильности) и безопасности данных, а также санкционирования доступа.
Для работы требуются минимальные аппаратные средства. И следует отметить, что роль разработок на данную тему сейчас весьма актуальна, так как непрерывный рост быстродействия, размеров и стоимости компьютеров привели к резкому расширению возможных рынков их сбыта, круга пользователей, разнообразия типов и цен. Естественно, что расширился спрос на разнообразное программное обеспечение.
ПОСТАНОВКА ЗАДАЧИ И ТРЕБОВАНИЯ К БАЗЕ ДАННЫХ.
Разработать и создать программный продукт, который можно отнести к базам данных, интеллектуальным информационно-поисковым системам.
Система должна:
- Удовлетворять всем требованиям пользователей к содержимому базы данных. Перед проектированием базы необходимо провести обширные исследования требований пользователей к функционированию базы данных.
- Гарантировать непротиворечивость и целостность данных. При проектировании таблиц нужно определить их атрибуты и некоторые правила, ограничивающие возможность ввода пользователем неверных значений. Для верификации данных перед непосредственной записью их в таблицу база данных должна осуществлять вызов правил модели данных и тем самым гарантировать сохранение целостности информации.
- Обеспечивать естественное, легкое для восприятия структурирование информации. Качественное построение базы позволяет делать запросы к базе более "прозрачными" и легкими для понимания; следовательно, снижается вероятность внесения некорректных данных и улучшается качество сопровождения базы.
- Удовлетворять требованиям пользователей к производительности базы данных. При больших объемах информации вопросы сохранения производительности начинают играть главную роль, сразу "высвечивая" все недочеты этапа проектирования.
ВВЕДЕНИЕ.
Во всей истории вычислительной техники можно проследить две основных области ее использования. Первая область - применение вычислительной техники для выполнения численных расчетов, которые слишком долго или вообще невозможно производить вручную.
Вторая область - это использование средств вычислительной техники в автоматических или автоматизированных информационных системах. В самом широком смысле информационная система представляет собой программно-аппаратный комплекс, функции которого состоят в надежном хранении информации в памяти компьютера, выполнении специфических для данного приложения преобразований информации и/или вычислений, предоставлении пользователям удобного и легко осваиваемого интерфейса. Обычно такие системы имеют дело с большими объемами информации, и эта информация имеет достаточно сложную структуру. Классическими примерами информационных систем являются банковские системы, системы резервирования авиационных или железнодорожных билетов, мест в гостиницах и т. д.
Вторая область использования вычислительной техники возникла несколько позже первой. Это связано с тем, что на заре вычислительной техники возможности компьютеров по хранению информации были очень ограниченными. Говорить о надежном и долговременном хранении информации можно только при наличии запоминающих устройств, сохраняющих информацию после выключения электрического питания. Оперативная (основная) память компьютеров этим свойством обычно не обладает. В первых компьютерах использовались два вида устройств внешней памяти - магнитные ленты и барабаны. Емкость магнитных лент была достаточно велика, но по своей физической природе они обеспечивали последовательный доступ к данным. Магнитные же барабаны (они больше всего похожи на современные магнитные диски с фиксированными головками) давали возможность произвольного доступа к данными, но были ограниченного размера.
Жизненный цикл любого программного продукта, в том числе и системы управления базой данных, состоит (по крупному) из стадий проектирования, реализации и эксплуатации.
Естественно, наиболее значительным фактором в жизненном цикле приложения, работающего с базой данных, является стадия проектирования. От того, насколько тщательно продумана структура базы, насколько четко определены связи между ее элементами, зависит производительность системы и ее информационная насыщенность, а значит - и время ее жизни.
Следующие пункты представляют основные шаги проектирования базы данных:
- Определить информационные потребности базы данных.
- Проанализировать объекты реального мира, которые необходимо смоделировать в базе данных. Сформировать из этих объектов сущности и характеристики этих сущностей (например, для сущности "деталь" характеристиками могут быть "название", "цвет", "вес" и т.п.) и сформировать их список.
- Поставить в соответствие сущностям и характеристикам - таблицы и столбцы (поля) в нотации, выбранной Вами СУБД (Paradox, dBase, FoxPro, Access, Clipper, InterBase, Sybase, Informix, Oracle и т.д.).
- Определить атрибуты, которые уникальным образом идентифицируют каждый объект.
- Выработать правила, которые будут устанавливать, и поддерживать целостность данных.
- Установить связи между объектами (таблицами и столбцами), провести нормализацию таблиц.
- Спланировать вопросы надежности данных и, при необходимости, сохранения секретности информации.
Для поддержания ссылочной целостности данных во многих СУБД имеется механизм так называемых внешних ключей. Смысл этого механизма состоит в том, что некоему атрибуту (или группе атрибутов) одного отношения назначается ссылка на первичный ключ другого отношения; тем самым закрепляются связи подчиненности между этими отношениями. При этом отношение, на первичный ключ которого ссылается внешний ключ другого отношения, называется master-отношением, или главным отношением; а отношение, от которого исходит ссылка, называется detail-отношением, или подчиненным отношением. После назначения такой ссылки СУБД имеет возможность автоматически отслеживать вопросы "не нарушения" связей между отношениями, а именно:
- если попытаться вставить в подчиненную таблицу запись, для внешнего ключа которой не существует соответствия в главной таблице (например, там нет еще записи с таким первичным ключом), СУБД сгенерирует ошибку;
- если попытаться удалить из главной таблицы запись, на первичный ключ которой имеется хотя бы одна ссылка из подчиненной таблицы, СУБД также сгенерирует ошибку.
- если попытаться изменить первичный ключ записи главной таблицы, на которую имеется хотя бы одна ссылка из подчиненной таблицы, СУБД также сгенерирует ошибку.
Таким образом, СУБД решают множество проблем, которые затруднительно или вообще невозможно решить при использовании файловых систем. При этом существуют приложения, для которых вполне достаточно файлов, приложения, для которых необходимо решать, какой уровень работы с данными во внешней памяти для них требуется, и приложения, для которых, безусловно, нужны базы данных.
Современные системы управления файлами и управления базами данных представляют собой весьма совершенные инструменты, каждый из которых может быть очень успешно применен в соответствующей области деятельности. Но всегда необходимо помнить, что каждый инструмент приносит максимальную пользу именно в той области, для которой он создан.
РАЗДЕЛ 1. ОБЩИЕ ВОПРОСЫ ОРГАНИЗАЦИИ
- Анализ современного состояния компьютеризации.
В последние десятилетия только что ушедшего века у человека появился новый партнер по взаимодействию. Появился он вначале в скромной роли: как инструмент и посредник. Но посредник настолько своеобразный, что в традиционные структуры взаимодействия «человек-человек» и «человек-реальность» он постепенно вклинился на правах полноценного третьего. И это стало постепенно менять сразу всех участников триады: и людей, и самого партнера-посредника, и реальность.
Машины, собственно, были посредниками между человеком и реальностью с очень давних пор. Но ситуация стала приобретать много новых черт, как только этой машиной оказался компьютер. Особенно, когда он стал посредником между человеком и человеком.
В принципе, компьютер отнюдь не задумывался как средство общения. Задачи у него первоначально, в проекте, были совсем другие. Компьютер вначале должен был, грубо говоря, считать, как видно из его названия. Роль средства коммуникации он себе «присвоил», - а затем сделал главной, а там и культурообразующей.
Произошло при этом нечто чрезвычайно существенное: он - сложнейшая машина - стал предметом повседневного воздействия непрофессионалов. Которые хотели от него - и по сей день хотят - в первую очередь общения (друг с другом и с миром) и игр. Именно в этом процессе и в этих целях компьютер создал нечто совершенно особенное: информационную среду, а с нею и Виртуальную Реальность. А сам, в свою очередь, превратился, чуть ли не в субъект культурного процесса - и уж во всяком случае, в партнера по общению, - который вносит в общение свои особенности, свой ритм, свои интонации… Словом, он стал казаться человеку чем-то весьма самостоятельным.
Компьютеру удалось нечто грандиозное: он не просто изменил среду обитания человека, но создал новую - не отменяя старой, а просто «поверх», параллельно. Будучи проекцией интеллекта, он - проекция и того, частью чего интеллект, строго говоря, является: способности, а главное, потребности человека создавать альтернативные - параллельные, другие - миры. Грубо говоря: человеку нужно Другое, и он всегда его себе создавал. А с возникновением цифровых информационных технологий для этого появились великолепные технические средства. Конечно, у них были предшественники - в том числе и сугубо технические: фотография, кинематограф, радио, звукозапись… Но компьютерная техника стала делать это неизмеримо полнее.
До самого конца 70-х слово «виртуальность» не ассоциировалось ни с электронными, ни с информационными технологиями: оно скромно оставалось синонимом «возможного», пока в речевом обиходе сотрудников Массачусетского технологического института (того самого, где все начинал Норберт Винер) не начал мелькать эффектный оборот: «виртуальная реальность». Так стали называть трехмерные макромодели «большой» реальности, которые создавались с помощью компьютера и давали эффект полного присутствия в этих псевдореальностях человека.
Причем полностью идея виртуальной реальности воплощается именно тогда, когда между ней и человеком не остается никакого зазора: он живет в ней, как в настоящей. В пределе, в идеале, в замысле, она во всех смыслах замещает собой «первую» реальность. С виртуальными (…по происхождению) объектами даже уже сейчас (а дальше-то что будет?!.) - благодаря современным техническим разработкам - возможен «непосредственный физический» контакт: их можно не только видеть (разумеется, в трехмерном изображении - это обеспечивает специальная оптика) и слышать, но и, например, передвигать и вообще осязать (для этого существует специальная «перчатка данных», имитирующая все чувственные сигналы, которые могли бы поступить при ощупывании предмета). И отсюда уже только шаг (да и то не очень большой) от имитации уже существующей реальности до симулирования никогда не существовавшей.
1.2. Организация доступа к удаленным Базам Данных средствами Интернет.
Одной из актуальных задач в области сетевых информационных технологий является организация доступа к удаленным базам данных средствами Интернет. Общий механизм основан на том что, создаются CGI-скрипты, которые обеспечивают как интерфейс с клиентом, так и с базой данных.
Для того чтобы организовать доступ к удаленным базам данных с помощью CGI-скриптов, необходимо чтобы CGI-скрипт выполнял следующие функции:
1) Обработку строки-запроса, при условии, что метод передачи данных GCI-скрипту POST и тип MIME передаваемых данных application/x-www-form-encoded;
2) работу с файлами баз данных
К сожалению, общая тенденция создания прикладных CGI-скриптов сводится к тому, что для решения каждой задачи пишется уникальный CGI-скрипт.
Однако специфика рассматриваемой предметной области заключается в том, что формируемые запросы имеют сложную и нерегулярную структуру. Поэтому была решена задача по созданию средств автоматизации подобного рода приложений, а именно был разработан язык описания экранных форм, на основе которых строится страница запроса, универсальный CGI-скрипт, включающий в себя процедуру анализа запроса формата x-www-form-encoded, процедуру генерации SQL-запроса и SQL-интерпретатор.
Описание того, как устроена форма, содержится в текстовом файле. В этом файле описываются поля ввода (их имена и тип) и шаблон, который содержит список условий и логических выражений, необходимых для создания SQL-запроса. На основе этого описания специальная утилита генерирует HTML-страницу с формой.
На сервере в каталоге выполнения сценариев находится универсальный CGI-скрипт, который получает данные из формы, анализирует их, составляет SQL-запрос и передает управление SQL-интерпретатору. SQL-интерпретатор обрабатывает SQL-запрос, осуществляет выборку и формирует выходной поток, содержащий результаты выборки.
1.2.1. Основные функции СУБД
Более точно, к числу функций СУБД принято относить следующие:
1.2.1.1. Непосредственное управление данными во внешней памяти
Эта функция включает обеспечение необходимых структур внешней памяти как для хранения данных, непосредственно входящих в БД, так и для служебных целей, например, для убыстрения доступа к данным в некоторых случаях (обычно для этого используются индексы). В некоторых реализациях СУБД активно используются возможности существующих файловых систем, в других работа производится вплоть до уровня устройств внешней памяти. Но подчеркнем, что в развитых СУБД пользователи в любом случае не обязаны знать, использует ли СУБД файловую систему, и если использует, то, как организованы файлы. В частности, СУБД поддерживает собственную систему именования объектов БД.
1.2.1.2. Управление буферами оперативной памяти
СУБД обычно работают с БД значительного размера; по крайней мере, этот размер обычно существенно больше доступного объема оперативной памяти. Понятно, что если при обращении к любому элементу данных будет производиться обмен с внешней памятью, то вся система будет работать со скоростью устройства внешней памяти. Практически единственным способом реального увеличения этой скорости является буферизация данных в оперативной памяти. При этом, даже если операционная система производит общесистемную буферизацию (как в случае ОС UNIX), этого недостаточно для целей СУБД, которая располагает гораздо большей информацией о полезности буферизации той или иной части БД. Поэтому в развитых СУБД поддерживается собственный набор буферов оперативной памяти с собственной дисциплиной замены буферов.
Стоит заметить, что существует отдельное направление СУБД, которое ориентировано на постоянное присутствие в оперативной памяти всей БД. Это направление основывается на предположении, что в будущем объем оперативной памяти компьютеров будет настолько велик, что позволит не беспокоиться о буферизации. Пока эти работы находятся в стадии исследований.
1.2.1.3. Управление транзакциями
Транзакция - это последовательность операций над БД, рассматриваемых СУБД как единое целое. Либо транзакция успешно выполняется, и СУБД фиксирует (COMMIT) изменения БД, произведенные этой транзакцией, во внешней памяти, либо ни одно из этих изменений никак не отражается на состоянии БД. Понятие транзакции необходимо для поддержания логической целостности БД. Поддержание механизма транзакций является обязательным условием даже однопользовательских СУБД (если, конечно, такая система заслуживает названия СУБД). Но понятие транзакции гораздо более важно в многопользовательских СУБД.
То свойство, что каждая транзакция начинается при целостном состоянии БД и оставляет это состояние целостным после своего завершения, делает очень удобным использование понятия транзакции как единицы активности пользователя по отношению к БД. При соответствующем управлении параллельно выполняющимися транзакциями со стороны СУБД каждый из пользователей может в принципе ощущать себя единственным пользователем СУБД (на самом деле, это несколько идеализированное представление, поскольку в некоторых случаях пользователи многопользовательских СУБД могут ощутить присутствие своих коллег).
С управлением транзакциями в многопользовательской СУБД связаны важные понятия сериализации транзакций и сериального плана выполнения смеси транзакций. Под сериализацией параллельно выполняющихся транзакций понимается такой порядок планирования их работы, при котором суммарный эффект смеси транзакций эквивалентен эффекту их некоторого последовательного выполнения. Сериальный план выполнения смеси транзакций - это такой план, который приводит к сериализации транзакций. Понятно, что если удается добиться действительно сериального выполнения смеси транзакций, то для каждого пользователя, по инициативе которого образована транзакция, присутствие других транзакций будет незаметно (если не считать некоторого замедления работы по сравнению с однопользовательским режимом).
Существует несколько базовых алгоритмов сериализации транзакций. В централизованных СУБД наиболее распространены алгоритмы, основанные на синхронизационных захватах объектов БД. При использовании любого алгоритма сериализации возможны ситуации конфликтов между двумя или более транзакциями по доступу к объектам БД. В этом случае для поддержания сериализации необходимо выполнить откат (ликвидировать все изменения, произведенные в БД) одной или более транзакций. Это один из случаев, когда пользователь многопользовательской СУБД может реально (и достаточно неприятно) ощутить присутствие в системе транзакций других пользователей.
1.2.1.4. Журнализация
Одним из основных требований к СУБД является надежность хранения данных во внешней памяти. Под надежностью хранения понимается то, что СУБД должна быть в состоянии восстановить последнее согласованное состояние БД после любого аппаратного или программного сбоя. Обычно рассматриваются два возможных вида аппаратных сбоев: так называемые мягкие сбои, которые можно трактовать как внезапную остановку работы компьютера (например, аварийное выключение питания), и жесткие сбои, характеризуемые потерей информации на носителях внешней памяти. Примерами программных сбоев могут быть: аварийное завершение работы СУБД (по причине ошибки в программе или в результате некоторого аппаратного сбоя) или аварийное завершение пользовательской программы, в результате чего некоторая транзакция остается незавершенной. Первую ситуацию можно рассматривать как особый вид мягкого аппаратного сбоя; при возникновении последней требуется ликвидировать последствия только одной транзакции.
Понятно, что в любом случае для восстановления БД нужно располагать некоторой дополнительной информацией. Другими словами, поддержание надежности хранения данных в БД требует избыточности хранения данных, причем та часть данных, которая используется для восстановления, должна храниться особо надежно. Наиболее распространенным методом поддержания такой избыточной информации является ведение журнала изменений БД.
Журнал - это особая часть БД, недоступная пользователям СУБД и поддерживаемая с особой тщательностью (иногда поддерживаются две копии журнала, располагаемые на разных физических дисках), в которую поступают записи обо всех изменениях основной части БД. В разных СУБД изменения БД журнализуются на разных уровнях: иногда запись в журнале соответствует некоторой логической операции изменения БД (например, операции удаления строки из таблицы реляционной БД), иногда - минимальной внутренней операции модификации страницы внешней памяти; в некоторых системах одновременно используются оба подхода.
Во всех случаях придерживаются стратегии "упреждающей" записи в журнал (так называемого протокола Write Ahead Log - WAL). Грубо говоря, эта стратегия заключается в том, что запись об изменении любого объекта БД должна попасть во внешнюю память журнала раньше, чем измененный объект попадет во внешнюю память основной части БД. Известно, что если в СУБД корректно соблюдается протокол WAL, то с помощью журнала можно решить все проблемы восстановления БД после любого сбоя.
Самая простая ситуация восстановления - индивидуальный откат транзакции. Строго говоря, для этого не требуется общесистемный журнал изменений БД. Достаточно для каждой транзакции поддерживать локальный журнал операций модификации БД, выполненных в этой транзакции, и производить откат транзакции, путем выполнения обратных операций, следуя от конца локального журнала. В некоторых СУБД так и делают, но в большинстве систем локальные журналы не поддерживают, а индивидуальный откат транзакции выполняют по общесистемному журналу, для чего все записи от одной транзакции связывают обратным списком (от конца к началу).
При мягком сбое во внешней памяти основной части БД могут находиться объекты, модифицированные транзакциями, не закончившимися к моменту сбоя, и могут отсутствовать объекты, модифицированные транзакциями, которые к моменту сбоя успешно завершились (по причине использования буферов оперативной памяти, содержимое которых при мягком сбое пропадает). При соблюдении протокола WAL во внешней памяти журнала должны гарантированно находиться записи, относящиеся к операциям модификации обоих видов объектов. Целью процесса восстановления после мягкого сбоя является состояние внешней памяти основной части БД, которое возникло бы при фиксации во внешней памяти изменений всех завершившихся транзакций и которое не содержало бы никаких следов незаконченных транзакций. Для того, чтобы этого добиться, сначала производят откат незавершенных транзакций (undo), а потом повторно воспроизводят (redo) те операции завершенных транзакций, результаты которых не отображены во внешней памяти. Этот процесс содержит много тонкостей, связанных с общей организацией управления буферами и журналом. Более подробно мы рассмотрим это в соответствующей лекции.
Для восстановления БД после жесткого сбоя используют журнал и архивную копию БД. Грубо говоря, архивная копия - это полная копия БД к моменту начала заполнения журнала (имеется много вариантов более гибкой трактовки смысла архивной копии). Конечно, для нормального восстановления БД после жесткого сбоя необходимо, чтобы журнал не пропал. Как уже отмечалось, к сохранности журнала во внешней памяти в СУБД предъявляются особо повышенные требования. Тогда восстановление БД состоит в том, что исходя из архивной копии, по журналу воспроизводится работа всех транзакций, которые закончились к моменту сбоя. В принципе, можно даже воспроизвести работу незавершенных транзакций и продолжить их работу после завершения восстановления. Однако в реальных системах это обычно не делается, поскольку процесс восстановления после жесткого сбоя является достаточно длительным.
1.2.1.5. Поддержка языков БД
Для работы с базами данных используются специальные языки, в целом называемые языками баз данных. В ранних СУБД поддерживалось несколько специализированных по своим функциям языков. Чаще всего выделялись два языка - язык определения схемы БД (SDL - Schema Definition Language) и язык манипулирования данными (DML - Data Manipulation Language). SDL служил главным образом для определения логической структуры БД, т.е. той структуры БД, какой она представляется пользователям. DML содержал набор операторов манипулирования данными, т.е. операторов, позволяющих заносить данные в БД, удалять, модифицировать или выбирать существующие данные.
В современных СУБД обычно поддерживается единый интегрированный язык, содержащий все необходимые средства для работы с БД, начиная от ее создания, и обеспечивающий базовый пользовательский интерфейс с базами данных. Стандартным языком наиболее распространенных в настоящее время реляционных СУБД является язык SQL (Structured Query Language).
Прежде всего, язык SQL сочетает средства SDL и DML, т.е. позволяет определять схему реляционной БД и манипулировать данными. При этом именование объектов БД (для реляционной БД - именование таблиц и их столбцов) поддерживается на языковом уровне в том смысле, что компилятор языка SQL производит преобразование имен объектов в их внутренние идентификаторы на основании специально поддерживаемых служебных таблиц-каталогов. Внутренняя часть СУБД (ядро) вообще не работает с именами таблиц и их столбцов.
Язык SQL содержит специальные средства определения ограничений целостности БД. Опять же, ограничения целостности хранятся в специальных таблицах-каталогах, и обеспечение контроля целостности БД производится на языковом уровне, т.е. при компиляции операторов модификации БД компилятор SQL на основании имеющихся в БД ограничений целостности генерирует соответствующий программный код.
Специальные операторы языка SQL позволяют определять так называемые представления БД, фактически являющиеся хранимыми в БД запросами (результатом любого запроса к реляционной БД является таблица) с именованными столбцами. Для пользователя представление является такой же таблицей, как любая базовая таблица, хранимая в БД, но с помощью представлений можно ограничить или наоборот расширить видимость БД для конкретного пользователя. Поддержание представлений производится также на языковом уровне.
Наконец, авторизация доступа к объектам БД производится также на основе специального набора операторов SQL. Идея состоит в том, что для выполнения операторов SQL разного вида пользователь должен обладать различными полномочиями. Пользователь, создавший таблицу БД, обладает полным набором полномочий для работы с этой таблицей. В число этих полномочий входит полномочие на передачу всех или части полномочий другим пользователям, включая полномочие на передачу полномочий. Полномочия пользователей описываются в специальных таблицах-каталогах, контроль полномочий поддерживается на языковом уровне.
1.3. Обзор существующих программных средств, пригодных для разработки баз данных.
Применительно к системам баз данных архитектура "клиент-сервер" интересна и актуальна главным образом потому, что обеспечивает простое и относительно дешевое решение проблемы коллективного доступа к базам данных в локальной сети. В некотором роде системы баз данных, основанные на архитектуре "клиент-сервер", являются приближением к распределенным системам баз данных, конечно, существенно упрощенным приближением, но зато не требующим решения основного набора проблем действительно распределенных баз данных.
Доступ к базе данных от прикладной программы или пользователя производится путем обращения к клиентской части системы. В качестве основного интерфейса между клиентской и серверной частями выступает язык баз данных SQL.
Это язык по сути дела представляет собой текущий стандарт интерфейса СУБД в открытых системах. Собирательное название SQL-сервер относится ко всем серверам баз данных, основанных на SQL. Соблюдая предосторожности при программировании, некоторые из которых были рассмотрены на предыдущих лекциях, можно создавать прикладные информационные системы, мобильные в классе SQL-серверов.
Серверы баз данных, интерфейс которых основан исключительно на языке SQL, обладают своими преимуществами и своими недостатками. Очевидное преимущество - стандартность интерфейса. В пределе, хотя пока это не совсем так, клиентские части любой SQL-ориентированной СУБД могли бы работать с любым SQL-сервером вне зависимости от того, кто его произвел.
Недостаток тоже довольно очевиден. При таком высоком уровне интерфейса между клиентской и серверной частями системы на стороне клиента работает слишком мало программ СУБД. Это нормально, если на стороне клиента используется маломощная рабочая станция. Но если клиентский компьютер обладает достаточной мощностью, то часто возникает желание возложить на него больше функций управления базами данных, разгрузив сервер, который является узким местом всей системы.
Одним из перспективных направлений СУБД является гибкое конфигурирование системы, при котором распределение функций между клиентской и пользовательской частями СУБД определяется при установке системы.
В типичном на сегодняшний день случае на стороне клиента СУБД работает только такое программное обеспечение, которое не имеет непосредственного доступа к базам данных, а обращается для этого к серверу с использованием языка SQL.
В некоторых случаях хотелось бы включить в состав клиентской части системы некоторые функции для работы с "локальным кэшем" базы данных, т.е. с той ее частью, которая интенсивно используется клиентской прикладной программой. В современной технологии это можно сделать только путем формального создания на стороне клиента локальной копии сервера базы данных и рассмотрения всей системы как набора взаимодействующих серверов.
С другой стороны, иногда хотелось бы перенести большую часть прикладной системы на сторону сервера, если разница в мощности клиентских рабочих станций и сервера чересчур велика. В общем-то при использовании RPC это сделать нетрудно. Но требуется, чтобы базовое программное обеспечение сервера действительно позволяло это. В частности, при использовании ОС UNIX проблемы практически не возникают.
Рссмотрим примеры существующих программных средств, которые пригодны для создания Баз Данных: