Организация Web-доступа к базам данных с использованием SQL-запросов

интерфейс управления сервером делает возможным удаленное управление

сервером из сети через навигатор. Enterprise Server 2.0 также поддерживает

возврат предыдущей версии конфигурации как процесс с одним шагом.

Служба безопасности. Enterprise Server 2.0 обеспечивает полную

поддержку для протокола защиты SSL3.0 (включая установление подлинности

сервера и пользователя через Х.509-сертификаты), двухстороннее шифрование и

целостность данных. Enterprise Server 2.0 позволяет администратору

устанавливать привилегии управления доступом для пользователей и

документов., Используя Х.509-сертификаты, можно проверить имена и пароли

пользователя, домены, его хосты, IP-адреса и принадлежность к определенным

группам.

LiveWire-возможности. Enterprise Server 2.0 включает продукт LiveWire,

который описан ниже.

Orion и будущие реализации

Реализация Enterprise Server следующих поколений, объединенных ныне под

кодовым именем Orion, расширит возможности Enterprise Server как основной

компоненты SuiteSpot, позволяя корпорациям развернуть более продвинутое

содержание Intranet и прикладных программ, функционирующих в сети и

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

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

Программируемые Web-страницы. Netscape обеспечит средства для

программирования Web-страниц, разбивая их на части, составляющие

статическое и динамическое содержание. В дополнение к полнотекстовому

поиску, управлению версиями и быстродействующей публикации HTTP Web-ресурсы

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

• Обработка форматов. Enterprise Server автоматически будет

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

форматам, типа HTML. Поддерживаемые форматы будут включать Adobe PDF,

Microsoft RTF, Word и др. Netscape будет также поддерживать индексацию и

каталогизацию других форматов и документов.

• Управление метаданными и поиск. Пользователям будет предоставлена

возможность работы с метаданными типа заголовка, ключевых слов, имени

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

выполнять гибкие запросы в соответствии с теми параметрами, которые заданы

в метаданных.

• Заказные представления(виды). Пользователи смогут генерировать

заказные представления(виды) содержимого отдельных областей и каталогов

Web. Например, они смогут отображать все документы размером больше 10 Кбайт

или, например, все документы, содержащие «Южная Америка» в их заголовках.

Услуги каталога. Будет поддерживаться Lightweight Directory Access

Protocol (LDAP), который будет использоваться для сохранения информации о

пользователе, параметрах управления доступом и информации о конфигурации

сервера.

• Услуги агента. Встроенная машина обслуживания агентов даст

возможность пользователям и администраторам создавать агентов, которые

могут быть выполнены на станции. Эти агенты способны взаимодействовать с

Web. Простой агент мог бы наблюдать за некоторым документом, который будет

изменен, и затем отправлять по почте пользователям этого документа копию

новой версии. Более сложный агент мог бы анализировать содержание Web

каждые полчаса и посылать пользователю электронную почту, содержащую связи

с документами в базе, авторизированными любым из пяти других пользователей,

которые содержат ключевые слова «Альфа-проект». Агенты могут быть вызваны,

например, когда новые документы начинают читаться или когда их кто-нибудь

изменяет.

Репликация. Репликация, или способность автоматически или явно

копировать содержание одного сервера на другой, и в конечном счете

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

заложена в новые версии. Согласование первоначально произойдет на уровне

файла, в последующих версиях Netscape добавит поддержку для уровня поля

replication. Это сделает возможным использование одного сервера как

организационного сервера, а другого – как производственного сервера или

позволит копировать содержание центрального сервера по филиалам в разрезе

тех сведений, которые там нужны.

Сервис разработки приложений. В новых реализациях будут расширены

возможности открытой сетевой среды Netscape ONE, обеспечивая изощренный

интерфейс пользователя API и библиотеки классов для Java и JavaScript.

Пользовательским приложениям, например, не составит труда провести

полнотекстовый поиск или выполнить запросы к метаданным, зарегистрировать

новую версию документа, и его автора. Также дату создания документа,

преобразовать формат документа, создать заказное представление (вид) всех

документов в интеллигентной программируемой среде Web (Smart programmable

content store) и копировать документ из одного сервера в другой. Netscape

будет поддерживать интеграцию Java, JavaScript и встроенные в сервер

средства LiveConnect. Более мощными реляционными возможностями доступа к

базе данных и более эффективным выполнением виртуальной Java-машины будут

расширены услуги разработки приложений, обеспечиваемых в Enterprise Server

2.0,.

Сервис управления. В дополнение к использованию встроенной машины

каталога LDAP Enterprise Server 2.0 будет управляем через общие системы

управления, включая CA/Unicenter, HP OpenView, IBM/Tivoli TME и Sun

Solstice.

Служба безопасности. Netscape добавит более сложный список управления

доступом (ACL) по модели, интегрированной с услугами каталога LDAP и

интеллигентной программируемой средой Web. Все аспекты управления ресурсами

Web и операций будут подчинены многоуровневому управлению доступом, включая

поиски документа, полно текстовые поиски, metadata-запросы, управление

версиями, преобразование форматов, заказные представления (виды) и агенты.

Рисунок 2.10. Схема работы пользовательских приложений на WEB.

Microsoft Internet Information Server.

Выход новой Windows NT 4.0 – огромный шаг в строну интеграции этой

операционной системы и сетей Microsoft в Internet. Отныне стало возможно

построение всех традиционных сервисов Internet: серверов Web, новостей,

почтовых серверов, брандмауэров – на серверах под управлением Windows NT.

Начиная с версии 4.0 в состав Windows NT входит мощьный Web Internet

Information Server (IIS), который реализует также серверы FTP и Gopher.

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

каталогов позволяет физически располагать страницы Web на разных

компьютерах (что бывает полезно из соображении безопасности), при этом

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

Входящий в состав продукта Internet Information Manager позволяет

настраивать все серверы web в организации, создавать области с

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

или группам пользователей. IIS позволяет писать Internet-приложения,

используя CGI (Common Gateway Interface). Встроенная поддержка SSL (Secure

Sockets Layer) позволяет шифровать трафик между сервером web и клиентом.

Для разработчиков существует открытый Internet Server API (ISAPI),

позволяющий создавать приложения, работающие по протоколу HTTP под

управлением ISS. ISAPI является реализацией серверной части технологии

Active X. Написанные с использованием ISAPI программы работают гораздо

быстрее, чем программы, написанные при помощи CGI. Применяя Internet

DataBase Connector, на сервере Web можно размещать таблицы различных СУБД,

поддерживающие стандарт ODBC (рис. 2.11).

Еще одна составная часть Windows NT 4.0 – Search Server, позволяющий

автоматически создавать индексы и производить поиск по ключевым словам на

файл-серверах, серверах Web, любых компьютерах внутри компании или где-либо

в Internet. Автоматическое обновление информации сервером поиска позволяет

сохранять актуальными индексы сводя скорость поиска к минимуму.

Все сервисы IIS имеют собственные счетчики в Perfomance Monitor,

позволяющие в реальном времени отслеживать нагрузку на них объем

передаваемых данных и т.п. Эти же статистические данные можно получить при

помощи протокола SNMP.

Рисунок 2.11. Взаимодействие через интерфейс ISAPI

Рисунок 2.12. Ресурсы, доступные из браузеров.

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

Многие организации используют электронные базы данных для поддержки

своих рабочих процессов. Часто это системы на одного – двух пользователей,

выполненные с использованием dbf – ориентированных средств разработки:

Clipper, Dbase, FoxPro, Paradox, Access. Обычно используется ряд таких баз,

независимых друг от друга. Если информация, хранимая в таких БД,

представляет интерес не только для непосредственных пользователей, то для

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

созданные базой данных.

С появлением локальных сетей, подключением таких сетей к Интернет,

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

рабочего места организации получить доступ к информационному ресурсу сети.

Однако, при попытке использовать существующие БД возникают проблемы

связанные с требованием к однородности рабочих мест (для запуска «родных»

интерфейсов), сильнейшим трафиком в сети (доступ идет напрямую к файлам

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

(например, командированных сотрудников). Решением проблемы могло бы стать

использование унифицированного интерфейса WWW для доступа к ресурсам

организации.

Технология World Wide Web получила столь широкое распространение из-за

простоты своего пользовательского интерфейса. Принцип «жми на то, что

интересно», лежащий в основе гипертекста, интуитивно понятен. В технологиях

WWW все ключевые понятия просматриваемого документа: слова, картинки –

имеют возможность «раскрыться» новым документом, развивающим это понятие.

Такой способ представления информации называется «гипертекстом», а

документы, представленные в таком виде – «гипертекстовыми документами». Для

описания этих документов используется специальный язык – язык описания

гипертекстовых документов или HTML (HyperText Markup Language).

Из этих предпосылок возникает задача преобразования накопленных данных

в гипертекстовые документы WWW, задача поддержки актуальности

преобразованной структуры. Другими словами, задача предоставления WWW –

доступа к существующим базам данных.

Основные понятия

Использование технологий WWW для обеспечения доступа к каким-либо

информационным ресурсам подразумевает существование следующих компонентов:

10. IP-сети с поддержкой базового набора услуг по передаче данных с единой

политикой нумерации и маршрутизации, работающим сервисом имен DNS.

11. Выделенного информационного сервера – WWW-сервера, обеспечивающего

предоставление гипертекстовых документов через IP – сеть в ответ на

запросы WWW – клиентов.

Рисунок 2.13

Передаваемые гипертекстовые документы оформляются в стандарте HTML –

языке описания гипертекстовых документов. Эти документы могут либо

храниться в статическом виде (совокупность файлов на диске), либо

динамически компоноваться в зависимости от параметров запроса специальным

программным обеспечением. Для динамической компоновки HTML-документов, WWW-

сервер использует специальным образом оформленные программы- CGI-программы

(Common Gate Interface)

Сценарии

В состав специфики конкретной БД входят как технологические основы,

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

целостности, так и организационные решения, связанные с поддержкой

актуальности баз данных и обеспечением доступа к ней.

При обеспечении WWW-доступа к существующим БД, возможен ряд путей –

комплексов технологических и организационных решений. Практика

использования WWW-технологии для доступа к существующим БД предоставляет

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

перекрывающих, взаимодействующих и т.д. Выбор конкретных решений при

обеспечении доступа зависит от специфики конкретной СУБД и от ряда других

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

освоить определенную ветвь технологических решений, существование других

БД, WWW-доступ к которым должен осуществляться с минимальными

дополнительными затратами и т.д.

WWW – доступ к существующим базам данных может осуществляться по одному из

трех основных сценариев. Ниже дается их краткое описание и основные

характеристики.

Однократное или периодическое преобразование содержимого БД в статические

документы

В этом варианте содержимое БД просматривает специальная программа,

создающая множество файлов – связных HTML-документов (см.рис.2.14 ).

Полученные файлы могут быть перенесены на один или несколько WWW-

серверов. Доступ к ним будет осуществляться как к статическим

гипертекстовым документам сервера.

Рисунок 2.14

Этот вариант характеризуется минимальными начальными расходами. Он

эффективен на небольших массивах данных простой структуры и редким

обновлением, а также при пониженных требованиях к актуальности данных,

предоставляемых через WWW. Кроме этого, очевидно полное отсутствие

механизма поиска, хотя возможно развитое индексирование.

В качестве преобразователя может выступать программный комплекс,

автоматически или полуавтоматически генерирующий статические документы.

Программа-преобразователь может являться самостоятельно разработанной

программой либо быть интегрированным средством класса генераторов отчетов.

Динамическое создание гипертекстовых документов на основе содержимого БД

В этом варианте доступ к БД осуществляется специальной CGI-

программой, запускаемой WWW-сервером в ответ на запрос WWW – клиента. Эта

программа, обрабатывая запрос, просматривает содержимое БД и создает

выходной HTML-документ, возвращаемый клиенту (см.рис.2.15).

Рисунок 2.15

Это решение эффективно для больших баз данных со сложной структурой и

при необходимости поддержки операций поиска. Показаниями также являются

частое обновление и невозможность синхронизации преобразования БД в

статические документы с обновлением содержимого. В этом варианте возможно

осуществлять изменение БД из WWW-интерфейсов.

К недостаткам этого метода можно отнести большое время обработки

запросов, необходимость постоянного доступа к основной базе данных,

дополнительную загрузку средств поддержки БД, связанную с обработкой

запросов от WWW – сервера.

Для реализации такой технологии необходимо использовать взаимодействие

WWW-сервера с запускаемыми программами CGI – Common Gateway Interface.

Выбор программных средств достаточно широк – языки программирования,

интегрированные средства типа генераторов отчетов. Для СУБД со внутренними

языками программирования существуют варианты использования этого языка для

генерации документов.

Создание информационного хранилища на основе высокопроизводительной СУБД с

языком запросов SQL. Периодическая загрузка данных в хранилище из основных

СУБД

В этом варианте предлагается использование технологии, получившей

название «информационного хранилища» (ИХ). Для обработки разнообразных

запросов, в том числе и от WWW-сервера, используется промежуточная БД

высокой производительности (см. рис.2.16). Информационное наполнение

промежуточной БД осуществляется специализированным программным обеспечением

на основе содержимого основных баз данных (см. рис.2.17).

Этап 1 – перегрузка данных

Рисунок 2.16

Этап 2 – обработка запросов

Рисунок 2.17

Данный вариант свободен ото всех недостатков предыдущей схемы. Более

того, после установления синхронизации данных информационного хранилища с

основными БД возможен перенос пользовательских интерфейсов на

информационное хранилище, что существенно повысит надежность и

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

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

WWW-доступа к содержимому нескольких баз данных накладные расходы

существенно уменьшаются.

Основой повышения производительности обработки WWW-запросов и резкого

увеличения скорости разработки WWW-интерфейсов является использование

внутренних языков СУБД информационного хранилища для создания

гипертекстовых документов.

Для загрузки содержимого основной БД в информационное хранилище могут

использоваться все перечисленные решения (языки программирования,

интегрированные средства), а также специализированные средства перегрузки,

поставляемые с SQL-сервером и продукты поддержки информационных хранилищ.

12. База данных Информационно-методического центра «Сведения об

образовательных учреждениях»

Назначение и предметная область

База данных предназначена для хранения данных об учебных заведениях

города Екатеринбурга и доступна по адресу: http://base.eimc.ru.

|2 |№ школы: |

| |109 |

| | |

| |Полное наименование: |

| |Муниципальное образовательное учреждение средняя |

| |общеобразовательная школа №109 с углубленным изучением |

| |предметов гуманитарно-педагогического цикла Ленинского |

| |р-на г. Екатеринбурга |

| | |

| |Адрес: |

| |620146, г. Екатеринбург, ул. Волгоградская, 37б |

| | |

| |Телефоны: |

| |28-17-52; 28-76-19; 28-08-05; 28-17-78 (музык школа) |

| | |

| |Тип компьютерной техники: |

| |Pentium 166 – 13 штук, локальная сеть есть |

| | |

| |Список профильных классов: |

| |Математические, гуманитарные, |

| |гуманитарно-педагогические |

| | |

| |Список кружков факультативов: |

| |«Рукодельница»; 2. «Эстетика быта»; 3. «Мягкая |

| |игрушка»; 4. «Театральный»; 5. «Кукольный театр»; 6. |

| |«ИЗО»; 7. «Баскетбол»; 8. «Аэробика»; 9. «Музей»; 10. |

| |«История ремесла»; 11. «Юный агроном» |

| | |

| |Дополнительная информация: |

| |17 лет школа сотрудничает с УРГПУ; 6 лет – с |

| |педколледжами; - При школе работает районный центр |

| |образовательных технологий; - В музее школы работает |

| |постоянно действующая выставка кружковцев школы; - |

| |Традицией школы стало проведение ежегодно: |

| |интеллектуально марафона, праздника «Золотые россыпи», |

| |- в честь победителей конкурсов и т.д. |

| | |

| |Интернет сайт: |

| |None |

| | |

| |Электронный адрес: |

| |None |

Рисунок 3.1

Анализ запросов показывает, что для наиболее оптимального поиска

требуемого ресурса и отображения нужного следует выделить следующие

критерии:

1. № школы

2. Полное наименование

3. Адрес

4. Телефоны

5. Тип компьютерной техники

6. Список профильных классов

7. Список кружков факультативов

8. Дополнительная информация

9. Интернет сайт

10. Электронный адрес

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

3.1

Web-интерфейс позволяет любому желающему добавить информацию о каком либо

учебном заведении, при этом оставив данные о себе. После проверки

достоверности информации сотрудниками Информационно методического центра

данные помещаются в базу данных. Такая система требует создания

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

информационных ресурсов (внесших их). Эта база должна содержать в себе

такие атрибуты, как:

1. Ф.И.О. владельца

2. E-mail владельца

3. Телефон

4. Адрес

5. Дата внесения ресурса в базу данных

Для поддержания связи с владельцем, в обязательные для заполнения поля

включены “Ф.И.О.”., “E-mail” или “Телефон”. При не заполнении их в

регистрации будет отказано. Содержимое поля “Дата внесения ресурса в базу

данных” автоматически генерируется системой.

Проектирование базы данных.

Для организации базы данных «Сведения об учебных заведениях города

Екатеринбурга» нам нужно создать две таблицы: «Учреждения» и «Владельцы

ресурсов».

СОЗДАТЬ ТАБЛИЦУ Учреждения

ПЕРВИЧНЫЙ КЛЮЧ ( ID )

ПОЛЯ ( ID Целое,

Номер школы Целое,

Полное_наименование Текст,

Адрес Текст,

Телефон Текст,

Тип_компбютерной_техники Текст,

Список_профильных_классов Текст,

Список_кружков_факультативов Текст,

Дополнительная_информация Текст );

СОЗДАТЬ ТАБЛИЦУ Владельцы_ресурсов

ПЕРВИЧНЫЙ КЛЮЧ ( ID )

ПОЛЯ ( ID Целое,

Ф.И.О. Текст,

E-mail

Текст,

Телефон Текст,

Адрес,

Дата внесения ресурса в базу данных Дата );

Устройство поисковой системы.

Поиск в системе происходит по средствам web-интерфейса. Поисковая

форма содержит два поля: “Критерия вывода” и “Фильтр”. Поле “Фильтр” в свою

очередь имеет следующие настройки: Вывод всех ресурсов, которые содержат

значение поля “Фильтр”, Вывод всех ресурсов, которые не содержат значение

поля “Фильтр” и настройка учета или не учета регистра.

Алгоритм поиска выглядит следующим образом:

1. Определяются настройки фильтра.

2. Определяется значение “Критерии вывода”.

3. Каждый ресурс базы имеет свой ID (первичный ключ). Программа

обрабатывает столбец, имя которого имеет значение “Критерии вывода”

(начиная с ресурса имеющего наименьший ID).

4. Не учет регистра преобразует при обработке значение атрибута и

значение “Фильтра” в строчные буквы.

5. Если пользователь отметил параметр Вывод всех ресурсов, которые

содержат значение поля “Фильтр”, то результатом выполнения программы

станет список ресурсов, которые содержат значение “Фильтра”.

6. Если была выбрана опция Вывод всех ресурсов, которые не содержат

значение поля “Фильтр”, то результатом выполнения программы будет

обратное п.4 – все, что не содержит значение “Фильтра”.

Администрирование системы.

Одной из главной задач в построении системы – часть ее

администрирования. Известно немало случаев, когда пользовательская часть

имеет удобный интерфейс, она привлекает больше и больше пользователей и в

конечном итоге администрирование этой системы становится практически

невозможно. Исходя из этого, нами было уделено не мало внимания на

администраторский интерфейс. При построении такого интерфейса главными

задачами были:

4. Удобный интерфейс. Web-интерфейс – это наиболее распространенный и

привычный для всех. Использование графических элементов делает

работу администратора быстрой и удобной.

5. Быстрота работы. В нашем случае быстрота работы зависит не от

конфигурации компьютера, а от качества связи с сервером, на котором

установлена система.

Система регистрации ресурсов.

Устройство системы не предполагает немедленное внесение информации в

основную базу данных после ее регистрации. По сути, таблица «Ресурсы»

делится на две подтаблицы: основная и временная. После регистрации ресурс

попадает во временную таблицу. Цензор просматривает временную таблицу

каждые 24 часа. Ресурс может быть перемещен в основную таблицу, удален или

оставлен во временной таблице для дальнейшего рассмотрения.

Рисунок 3.2. Работа поисковой системы.

3. Вопросы безопасности и санкционирования доступа к базам данных.

Многие считают, что самое главное – это защитить свои (собственные или

корпоративные) данные от людей (или запущенных ими программ), не обладающих

полномочиями для доступа к этим данным. Конечно, это важно, иногда очень

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

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

еще нужный файл, выкинули из файла нужную часть текста, неправильно

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

Рассмотрим такой пример. Пусть в базе данных хранятся записи,

содержащие характеристики разных марок автомобилей. Каждая запись состоит

из трех полей, хранящих название автомобиля, его вес и мощность мотора.

Предположим, что некто имеет право изменять содержимое базы данных. С одной

стороны, нельзя запретить ему менять значение мощности мотора, поскольку

при первоначальном вводе соответствующей записи могла быть допущена ошибка

или у автомобиля данной марки мощность мотора действительно изменилась. С

другой стороны, если изменить значение мощности ошибочно, то в дальнейшем

никаким образом не удастся узнать правильную мощность мотора. Еще

неизвестно, что лучше – допустить несанкционированное чтение своих данных

другими пользователями или полностью утратить их по причине собственной

ошибки.

Свойство хранимых данных, которое заключается в том, что они правильны

в соответствии с критериями, установленными владельцем и/или

администратором данных, называется целостностью данных. По моему мнению,

бессмысленно говорить о безопасности данных в системе, которая не

обеспечивает какие-либо средства поддержки целостности.

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

Например, владелец файла, содержащего объектный модуль программы, может

воспользоваться текстовым редактором и исключить часть модуля. Очень

вероятно, что файл перестанет быть целостным.

В современных базах данных дела обстоят несколько лучше (хотя и не

идеально). Во-первых, уже во многих СУБД поддерживается понятие домена

(множества значений некоторого типа данных). При определении столбца

таблицы можно указать домен допустимых значений этого столбца, и после

этого система следит за тем, чтобы в столбце содержались только допустимые

значения. (Конечно, это не значит, что по ошибке нельзя поместить в поле

записи допустимое, но неверное значение.) Во-вторых, для столбца, для

таблицы или для нескольких таблиц одновременно можно определить одно или

несколько ограничений целостности. Ограничение целостности – это логическое

выражение, которое должно быть истинным при целостном состоянии базы

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

результате которых нарушается хотя бы одно ограничение целостности. В-

третьих, в некоторых системах появилась поддержка триггеров – хранимых

процедур, написанных на процедурном расширении языка SQL (например, PL/SQL

в Oracle), которые автоматически вызываются при выполнении

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

ее целостности.

Такие средства в ряде случаев позволяют избежать серьезных ошибок,

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

гарантии отсутствия ошибок. Например, по-прежнему, полномочный пользователь

может неправильно изменить значение мощности мотора в записи марки

автомобиля (удовлетворив при этом ограничение домена и все ограничения

целостности). Пожалуй, единственную на сегодня возможность избежать потери

данных по причине собственной ошибки обеспечивают так называемые

темпоральные системы баз данных (примером может служить СУБД Postgres).

В таких системах при любом обновлении записи образуется ее полная

копия, а предыдущий вариант продолжает существовать вечно. Даже после

удаления записи все накопленные варианты продолжают оставаться в базе

данных. Можно потребовать выборку из базы данных любого варианта записи,

если указать момент или интервал времени, когда этот вариант был текущим

(потому такие базы данных и называются темпоральными). В темпоральных базах

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

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

правильному состоянию данных (если, конечно, они находились в правильном

состоянии в некоторый известный момент времени).

Кстати, нужно, наверное, заметить, что как обычно случается в

программировании, передовой в мире СУБД подход темпоральных баз данных в

большой степени основан на старых идеях операционных систем компании

Digital RSX и VMS. В этих системах каждое обновление файла приводило к

созданию его новой версии, и все предыдущие версии сохранялись до явного

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

версий доходило до сотни. Частенько случалось по ошибке уничтожить именно

правильную версию. Темпоральные СУБД не допускают уничтожения существующих

вариантов записей, но чтобы не переполнить магнитные диски, приходится

время от времени архивировать наиболее старую часть активной порции базы

данных.

До сих пор в качестве примера распространенного вида ошибок

фигурировал случай, когда неправильно обновлялось индивидуальное поле

некоторой записи. Однако часто возникают ситуации, когда совокупные данные

записи становятся неверными по той причине, что значения нескольких полей

должны изменяться согласованно. Расширим немного пример базы данных марок

автомобилей. Пусть каждая запись содержит еще одно поле – класс автомобиля.

Например, пусть при весе до 3,5 тонн автомобиль относится к классу B, а при

большем весе – к классу С. Конечно, это ограничение целостности, и его

можно сформулировать, например, на языке SQL. Конечно, можно определить

триггер, который будет автоматически изменять значение класса автомобиля в

зависимости от устанавливаемого значения его веса. Но все это ужасно

громоздко.

На мой взгляд, более изящное решение подобных проблем обеспечивают

системы объектно-ориентированных баз данных (ООБД). В таких системах

хранятся не записи данных, а объекты. Каждый объект обладает внутренним

состоянием (по-простому, хранит внутри себя запись данных), а также набором

методов, т.е. процедур, с помощью которых (и только таким образом) можно

обратиться к данным, составляющим внутреннее состояние объекта, и/или

изменить их.

В случае ООБД конструирование базы данных состоит в разработке

структуры и методов объектов. Поэтому можно написать методы таким образом,

чтобы при работе с любым объектом было невозможно нарушить его целостность.

Например, ООБД марок автомобилей состояла бы из объектов, внутреннее

состояние которых представляло бы собой записи той же структуры, как и

раньше, а в число методов входил бы метод «Изменить вес автомобиля». Тогда

код этого метода автоматически изменял бы и класс автомобиля при

возникновении соответствующего условия. Кстати, заметим, что отсутствовал

бы метод «Изменить класс автомобиля», значение класса было бы доступно

только по чтению. Ошибочные состояния объектов все равно возможны,

поскольку никто не мешает обратиться к методу «Изменить вес автомобиля» с

неверными, хотя и правдоподобными параметрами. Как и прежде, единственным

способом сохранить возможность доступа к последнему варианту объекта с

правильным состоянием является использование техники темпоральных баз

данных.

По поводу подхода ООБД существует и ряд критических замечаний. В

частности, многих не устраивает, что вместо чисто декларативных ограничений

целостности и полудекларативных триггеров, используемых в реляционных

системах, в ООБД для поддержания внутренней целостности объектов приходится

писать чисто процедурный код. Но у каждого свои пристрастия. Лично мне

более близок подход ООБД.

Завершая этот небольшой экскурс в область средств поддержки

целостности данных, еще раз заметим, что в любом случае при достаточном

старании можно навредить себе больше, чем злоумышленный враг. Заботясь о

защите от других, следует подумать, насколько ты защищен от собственных

ошибок.

В контексте баз данных термин безопасность означает защиту данных от

несанкционированного раскрытия, изменения или уничтожения. SQL позволяет

индивидуально защищать как целые таблицы, так и отдельные их поля. Для

этого имеются две более или менее независимые возможности:

механизм представлений, рассмотреный в предыдущей главе и используемый для

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

доступа;

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

пользователям определенные привилегии на доступ к данным и дать им

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

привилегий другим пользователям, отменяя впоследствии эти привилегии, если

потребуется.

Обычно при установке СУБД в нее вводится какой-то идентификатор,

который должен далее рассматриваться как идентификатор наиболее

привилегированного пользователя – системного администратора. Каждый, кто

может войти в систему с этим идентификатором (и может выдержать тесты на

достоверность), будет считаться системным администратором до выхода из

системы. Системный администратор может создавать базы данных и имеет все

привилегии на их использование. Эти привилегии или их часть могут

предоставляться другим пользователям (пользователям с другими

идентификаторами). В свою очередь, пользователи, получившие привилегии от

системного администратора, могут передать их (или их часть) другим

пользователям, которые могут их передать следующим и т.д.

Привилегии предоставляются с помощью предложения GRANT (предоставить),

общий формат которого имеет вид

GRANT привилегии ON объект TO пользователи;

В нем «привилегии» – список, состоящий из одной или нескольких

привилегий, разделенных запятыми, либо фраза ALL PRIVILEGES (все

привилегии); «объект» – имя и, если надо, тип объекта (база данных,

таблица, представление, индекс и т.п.); «пользователи» – список, включающий

один или более идентификаторов санкционирования, разделенных запятыми, либо

специальное ключевое слово PUBLIC (общедоступный).

К таблицам (представлениям) относятся привилегии SELECT, DELETE,

INSERT и UPDATE [(столбцы)], позволяющие соответственно считывать

(выполнять любые операции, в которых используется SELECT), удалять,

добавлять или изменять строки указанной таблицы (изменение можно ограничить

конкретными столбцами). Например, предложение

GRANT SELECT, UPDATE (Труд) ON Блюда TO cook;

позволяет пользователю, который представился системе идентификатором cook,

использовать информацию из таблицы Блюда, но изменять в ней он может только

значения столбца Труд.

Если пользователь USER_1 предоставил какие-либо привилегии другому

пользователю USER_2, то он может впоследствии отменить все или некоторые из

этих привилегий. Отмена осуществляется с помощью предложения REVOKE

(отменить), общий формат которого очень похож на формат предложения GRANT:

REVOKE привилегии ON объект FROM пользователи;

Например, можно отобрать у пользователя cook право изменения значений

столбца

5. Перспективы развития сетевых баз данных

Термин «системы следующего (или третьего) поколения» вошел в жизнь после

опубликования группой известных специалистов в области БД «Манифеста систем

баз данных третьего поколения». Cторонники этого направления придерживаются

принципа эволюционного развития возможностей СУБД без коренной ломки

предыдущих подходов и с сохранением преемственности с системами предыдущего

поколения.

Частично требования к системам следующего поколения означает просто

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

большинстве текущих реляционных СУБД (ограничения целостности, триггеры,

модификация БД через представления и т.д.). В число новых требований входит

полнота системы типов, поддерживаемых в СУБД; поддержка иерархии и

наследования типов; возможность управления сложными объектами и т.д.

Одной из наиболее известных СУБД третьего поколения является система

Postgres, а создатель этой системы М.Стоунбрекер, по всей видимости,

является вдохновителем всего направления. В Postgres реализованы многие

интересные средства: поддерживается темпоральная модель хранения и доступа

к данным и в связи с этим абсолютно пересмотрен механизм журнализации

изменений, откатов транзакций и восстановления БД после сбоев;

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

ненормализованные отношения (работа в этом направлении началась еще в среде

Ingres), хотя и довольно странным способом: в поле отношения может

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

Одно свойство системы Postgres сближает ее с объектно-ориентированными

СУБД. В Postgres допускается хранение в полях отношений данных абстрактных,

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

поведенческого аспекта в БД, т.е. решает ту же задачу, что и ООБД, хотя,

конечно, семантические возможности модели данных Postgres существенно

слабее, чем у объектно-ориентированных моделей данных.

Хотя отнесение СУБД к тому или иному классу в настоящее время может быть

выполнено только условно (например, иногда объектно-ориентированную СУБД O2

относят к системам следующего поколения), можно отметить три направления в

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

обозначать их именами наиболее характерных СУБД.

1. Направление Postgres. Основная характеристика: максимальное следование

(насколько это возможно с учетом новых требований) известным принципам

организации СУБД (если не считать упоминавшейся коренной переделки

системы управления внешней памятью).

2. Направление Exodus/Genesis. Основная характеристика: создание

собственно не системы, а генератора систем, наиболее полно

соответствующих потребностям приложений. Решение достигается путем

создания наборов модулей со стандартизованными интерфейсами, причем

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

3. Направление Starburst. Основная характеристика: достижение

расширяемости системы и ее приспосабливаемости к нуждам конкретных

приложений путем использования стандартного механизма управления

правилами. По сути дела, система представляет собой некоторый

интерпретатор системы правил и набор модулей-действий, вызываемых в

соответствии с этими правилами. Можно изменять наборы правил

(существует специальный язык задания правил) или изменять действия,

подставляя другие модули с тем же интерфейсом.

В целом можно сказать, что СУБД следующего поколения – это прямые

наследники реляционных систем.

6. Список литературы.

1. Браун М., Ханикатт Д. “HTML 3.2”, К., 1996

2. Вьюкова Н.И., Галатенко В.А., “Информационная безопасность систем

управления базами данных”, СУБД № 1 1996

3. Грабер М., “Справочное руководство по SQL”, М., 1997

4. Дейта К. “Введение в системные баз данных”, М., 1999

5. Дунаев С.Б. “Intranet-технологии.”, М., 1997

6. Кириллов В.В. “Структуризованный язык запросов (SQL)”, М.,1997

7. Кузнецов С.Д. “Основы современных баз данных”, К., 1999

8. Кузнецов С.Д. “Безопасность и целостность или, Худший враг себе - это

ты сам”, СПб., 1998

9. Мейер М. “Теория реляционных баз данных”, М.,1996

10. ЦНИТ НГУ. “Использование технологий WWW для доступа к базам данных”,

Н., 1997

11. Шпеник М., Следж О. и др. “Руководство администратора баз данных

Microsoft SQL Server 7.0”, М., 1999

12. "SQL Полное руководство" К., 1998

-----------------------

4

5

Инф.

хран.

БД

БД

www-клиент

www-клиент

www-сервер

IP-сеть

преобразователь

БД

www-клиентт

www-сервер

Обработчик

БД

1

6

2

3

5

4

Клиент

SQL-сервер

SQL-запрос

Ответ

БД

3

2

6

1

БД

Обработчик

www-сервер

www-клиентт

Web Connector

yes

no

Содержание “фильтра” полученой из БД информации

yes

no

Содержание “фильтра” полученой из БД информации

Значение “Фильтра” не изменяется

yes

SQL-запрос на вывод атрибутов содержащих в заголовке значение “Критерии

Вывода”

Вывод атрибутов содержащих в заголовке значение “Критерии Вывода”

SQL сервер

регистр

Преобразование значени атрибута в строчные буквы

Значение “Фильтра” преобразуется в строчные буквы

no

Операционная система

Прикладная программа (часть ее на клиенте)

Интерфейс вызова удаленных приложений

Приложения должны быть распределенными. Это резко усложняет систему и

повышает степень ответственности администратора

Прикладные программы и данные распределены между клиентами, и это

небезопасно для системы.

Вызовы хранимых процедур

Драйверы баз данных

Прикладная программа (часть ее на сервере приложений)

Драйвер баз данных.

Прикладная программа (часть ее на сервере)

Так как прикладная программа разделена на части, выполняющиеся на различных

машинах, ее сопровождение и отладка превращается в настоящий кошмар

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

Приложения для WEB получает данные из СУБД

Апплеты Java

HTML-страницы

HTTP WEB SERVER

Любое приложение исполняется на сервере, а вызвается из Web-браузера

Средства Java

Операционная система

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

Сервер приложений

Клиент

Приложение-шлюз

Интерфейс - CGI

Встроенный SQL

Хранимые процедуры

Клиент

Сервер

Логика приложений

Логика приложений

Сохранение процедуры

Пользовательский интерфейс

Web-сервер

SQL-база данных

ЛВС

ЛВС

Навигатор

Сервер приложений

Database Server

Логика приложений

Сохранение процедуры

Пользовательский интерфейс

SQL-база данных

Глобальные или локальные

вычислительные сети

Рабочая станция

Пользовательские приложения

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

Страницы Web

Internet Database Connector (IDC)

HTML Wizard

HTML Wizard

Хранилище данных Exchange

Хранилище данных SQL

Microsoft Exchange

Microsoft SQL Server

Internet information Server

Windows NT Server

ISAPI

Приложения Microsoft BackOffice: Microsoft Txchang, Systems Management

Server, SNA Server.

Приложения третьих фирм

Приложения, написанные на Visual Basic, Basic C++, Perl и т.д.

Windows NT Server + Internet Information Server

Программа просмотра страниц Web

Страницы: 1, 2, 3, 4, 5, 6