Переход от E/R-диаграмм к реляционным проектам

Переход от диаграммы "сущность-связь" к реляционной схеме БД принципиально аналогичен переходу к ней от проекта ODL. Данный переход достаточно хорошо формализуем.

1. Все простые сущности преобразуется в таблицу. Простая сущность – сущность, не являющаяся подтипом и не имеющая подтипов. Имя сущности становится именем таблицы.

2. Атрибуты становится возможными столбцами с тем же именем; может выбираться более точный формат. Столбцы, соответствующие необязательным атрибутам, могут содержать неопределенные значения; столбцы, соответствующие обязательным атрибутам, – не могут.

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

4. Связи многие-к-одному (и один-к-одному) становятся внешними ключами. Необязательные связи соответствуют столбцам, допускающим неопределенные значения; обязательные связи – столбцам, не допускающим неопределенные значения.

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

6. Если в концептуальной схеме присутствовали слабые сущности, то возможны два способа:

· все слабые сущности в одной таблице (а);

• для каждой слабые сущности – отдельная таблица (б).

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

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

7. При наличии исключающих связей (сущность может быть расщеплена на два или более взаимно исключающих подтипа, каждый из которых включает общие атрибуты и/или связи) имеется два способа работы.

· общий домен (а);

• явные внешние ключи (б).

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

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

Преимущества перехода к схеме БД от E/R-моделей по сравнению с ODL-проектом заключаются в следующем:

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

Ø Двухсторонние связи ODL заменяются единственным отношением, представляющим связи в обоих направлениях.

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

 

Контрольные вопросы и задания

 

1. Пояснить основные положения объектно-ориентированного проектирования.

2. Каким образом представляются объекты в ODL?

3. Как описываются атрибуты в ODL?

4. Охарактеризовать типы связей в ODL.

5. Привести пример обратной связи в ODL.

6. Привести пример связи "многие-ко-многим" в ODL.

7. Привести пример связи "многие-к-одному" в ODL.

8. Привести пример связи "один-к-одному" в ODL.

9. Перечислить базовые типы данных в ODL.

10. Чем отличается тип множество от типа мультимножество?

11. Перечислить принципы проектирования с использованием ODL.

12. Что такое подкласс?

13. Привести пример множественного наследования в ODL.

14. Каким образом осуществляется моделирование ограничений в ODL?

15. Какова последовательность действий для преобразования ODL-модели в реляционную?

16. Перечислить компоненты E/R диаграммы.

17. Каким образом выражается множественность связей в E/R диаграммах?

18. Привести примеры многосторонних связей.

19. В чем заключается суть ролей в связях?

20. Привести пример перемещения атрибута в множество сущностей.

21. Описать слабые множества сущностей.

22. Какова технология конвертирования многосторонних связей в бинарные?

23. Указать рекомендации по проектированию E/R-моделей.

24. Каким образом выбираются типы элементов проекта?

25. Для чего предназначена связь isa?

26. Как осуществляется моделирование ограничений в E/R-модели?

27. Описать технологию перехода от E/R-модели к реляционной модели.

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

29. Описать в ODL БД, содержащую следующую информацию о командах, игроках и их спонсорах:

Ø название каждой команды, ее игроков, капитана
(одного из игроков) и цвета ее спортивной формы;

Ø имя, фамилия, отчество, место в команде (вратарь, защитник и т. д.) каждого игрока.

Ø информацию о спонсорах.

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

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

32. Допустимо ли, чтобы тип был одновременно типом атрибута ODL и типом связи ODL? Объяснить, почему.

33. В условия задания 1 добавлены новые элементы – проекты. Проект имеет название, общий бюджет, объединяет несколько сотрудников для его выполнения. Описать такую БД в ODL.

34. Представить БД предприятия из задания 1 в виде Е/R-модели. Обязательно ввести стрелки (там, где они необходимы) для выражения множественности связи.

35. Представить БД команды/игроки /болельщики из задания 2 в виде E/R-модели. Учтите, что множество цветов – неподходящий тип атрибута для команд. Как можно обойти это ограничение?

36. Альтернативный способ представления информации задания 4, ввести тернарную связь Семья, полагая, что тройкой в множестве отношений для Семья является (особа, отец, мать) и все ее члены, разумеется, входят во множество Люди.

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

Ø заменить тернарную связь Семья множеством сущностей и бинарными связями; для отражения множественности связей используйте стрелки.

37. Пусть в условиях задания 1 каждый отдел имеет сектор, с названиями сектор1, сектор2, и т.д. Сотрудники относятся непосредственно к секторам. Привести полную Е/R – диаграмму такой информационной системы.

38. Один из способов представления студентов и оценок, полученных ими на учебных курсах, использование множеств сущностей, соответствующих студентам, курсам и "зачислениям". Зачисления образуют множество "связующих" сущностей между студентами и курсами. Их можно использовать не только для представления того факта, что студент проходит определенный курс, но для выражения отметок, полученных студентом по данному курсу. Представить эту ситуацию в E/R-диаграмме, указав слабые множества сущностей и их ключи. Является ли отметка частью ключа для "зачислений"?

39. Выбрать и определить ключи для ODL-разработок из задания 1.

40. Выбрать и определить ключи для Е/R – диаграмм из задания 2.

 

5. БАЗЫ ДАННЫХ В СЕТЯХ

 

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

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

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

В этой главе мы рассмотрим некоторые варианты распределенной обработки данных.

 

5.1. Архитектура "клиент-сервер"

 

Определим основные понятия сервер и клиент. Под сервером в информационных системах понимается программа (компьютер), предоставляющая услуги по запросам других программ (компьютеров), называемых клиентами. В контексте баз данных вводится понятие сервер баз данных [15]:

1. СУБД в архитектуре "клиент-сервер".

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

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

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

Ø хранение и резервное копирование данных;

Ø поддержка ссылочной целостности данных согласно правилам, определенным в базе данных;

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

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

Клиентские узлы поддерживают пользовательские интерфейсы и функциональность приложений.

Основой архитектуры "клиент-сервер" является принцип централизации хранения и обработки данных. Централизованная база данных физически сосредоточена в одном месте и управляется одним компьютером-сервером. Классическая двухзвенная схема "клиент-сервер" представлена на рис. 62.

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

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

2. Прикладные функции, определяющие основные алгоритмы решения задач (Business Logic – бизнес-логика).

3. Функции обработки данных внутри приложения (Database Logic – логика обработки данных).

4. Функции управления информационными ресурсами (Database Manager Logic). Это собственно СУБД, обеспечивающая хранение и управление базами данных.

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

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

В модели удаленного доступа к данным (Remote Data Access, RDA) на сервере хранится база данных и ядро СУБД. На клиенте располагается презентационная логика и бизнес-логика. Клиент обращается к серверу с запросом на языке SQL, либо посредством средств пользовательского интерфейса (API). Данную модель поддерживает большое число серверных СУБД, имеющих SQL-интерфейсы, и инструментальных средств, обеспечивающих создание клиентской части.

Модель сервера БД (Database Server – DBS) характеризуется тем, что функции компьютера-клиента ограничиваются презентационной логикой. Большая часть бизнес-логики переложена на сервер. Иногда такую модель называют моделью с "тонким клиентом". Эта модель является более технологичной, чем RDA и применяется в таких СУБД как Informix, Ingres, Sybase, Oracle, SQL MS Server.

Существуют и более сложные варианты реализации архитектуры "клиент-сервер", например, трехзвенные информационные системы с использованием серверов приложений, реализующих бизнес-логику информационной системы (модель сервера приложений – Application Server (AS)) (рис. 63).

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

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

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

Транзакцией называется совокупность операций манипулирования данными (вставкой, удалением, выборкой, обновлением) в системах баз данных, которая переводит базу данных из одного целостного (непротиворечивого) состояния в другое целостное состояние. Транзакция рассматривается как некоторое неделимое с точки зрения пользователя действие над базой данных. Например, транзакцией может быть последовательность операций по формированию заказа на сборку компьютера в компьютерной фирме: ввод нового заказа с реквизитами заказчика, формирование платежного документа, запрос на комплектующие. С точки зрения сотрудника компьютерной фирмы, это единая операция: если она будет прервана, то база данных потеряет свое целостное состояние. Восстановление данных в СУБД является составной часть управления данными и подразумевает восстановление самой базы данных, т.е. возвращение базы данных в правильное состояние в случае изменения данных в результате сбоя. Восстановление данных реализуется через механизм транзакций. Завершение транзакции означает, что все операции, входящие в состав транзакций, успешно завершены и результат их работы сохранен в базе данных. Откат транзакции означает, что все уже выполненные операции отменяются и все объекты базы данных, затронутые этими операциями возвращены в исходное состояние. Для реализации возможности отката транзакций большинство СУБД поддерживают запись в журналы транзакций, позволяющие сохранять промежуточные состояния и восстанавливать исходные данные при откате. Существуют различные модели транзакций [10,14, 26 и др.].

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

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

 

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

 

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

Компьютеры объединяются в локальные сети.

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

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

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

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

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

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

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

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

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

Проиллюстрируем это понятие примером из [24]. В БД имеется таблица, содержащая данные о сотрудниках, работающих в различных филиалах, или о заказах на продажу. Таблица может быть разделена на фрагменты по географическому или другому характеристическому признаку.

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

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

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

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

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

Тиражирование (или репликация) означает создание копий некоторых фрагментов базы данных с целью приближения данных к месту их использования. Основное достоинство метода заключается в сокращении сетевого трафика и увеличение производительности системы. Репликаторы представляют множество различных физических копий некоторого объекта базы данных (обычно таблицы), для которых в соответствии с определенными в базе данных правилами поддерживается синхронизация (идентичность) с некоторой "главной" копией. Теоретически значения всех данных в тиражированных объектах должны автоматически и незамедлительно синхронизироваться друг с другом. (На практике это правило обычно несколько ослабляется.) В некоторых системах копии используются исключительно в режиме чтения и обновляются в соответствии с заданным расписанием. В других средах допускается модификация отдельных значений в копиях, и эти изменения распространяются в соответствии с процедурами планирования и координации. Подробнее с различными моделями тиражирования можно ознакомится в [24.]

Основной недостаток метода тиражирования БД заключается в том, что на некотором интервале времени возможно "расхождение" копий БД.

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

Ø Прозрачность относительно местоположения. Для пользователя не должно быть разницы где физически находятся данные, данные должны "выглядеть" так, если бы они находились на локальном компьютере.

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

Ø Прозрачность относительно сети. СУБД должны работать одинаково в разнородных сетях: от высокоскоростных ЛВС до телефонных линий.

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

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

Ø Распределенные транзакции. СУБД должна выполнять транзакции, выходящие за границы одной вычислительной системы, и при этом поддерживать целостность данных при появлении отказов, как в отдельных системах, так и в сети в целом.

Ø Безопасность. СУБД должна обеспечить защиту всей распределенной базы от несанкционированного доступа.

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

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

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

Уровень 1. У даленный запрос.

На данном уровне пользователь может выполнить инструкцию SQL, которая производит доступ или модификацию информации в одной удаленной базе данных (рис. 65).

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

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

Уровень 2. Удаленная транзакция. На данном уровне обеспечиваются более сложные транзакции, состоящие из нескольких инструкций SQL (рис. 66)

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

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

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

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

Уровень 4. Распределенный запрос (рис. 68). На данном уровне один оператор SQL может обращаться к таблицам из двух или более баз данных, которые расположены в различных вычислительных системах. При этом СУБД отвечает за автоматическое выполнение оператора во всех системах, участвующих в запросе. Транзакция представляет собой последовательность инструкций. Как и на предыдущем уровне, СУБД должна обеспечить целостность распределенной транзакции во всех участвующих системах.

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

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

Ряд новых направлений открывается в связи с развитием объектно-ориентированных систем, в частности сред, основанных на объектно-реляционном подходе. Пожалуй, наиболее важная область в управлении распределенными объектами – это брокеры объектных запросов (Object Request Broker, ORB). Концепция распределения объектов распространилась не только на среды объектно-ориентированных СУБД, но и почти на любые мыслимые среды информационных систем главным образом благодаря работам, проводимым под эгидой Object Management Group (OMG), которая разработала стандарт общей архитектуры брокера объектных запросов – CORBA (Common Object Request Broker Architecture).

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

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

 

5.3. Базы данных в Интернет

 

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

Архитектура "клиент/сервер" на базе Интернет имеет трехуровневую организацию. Пользовательским интерфейсом является Web-браузер, расположенный на персональном компьютере – "тонком" клиенте. Web-браузер взаимодействует с Web-сервером, последний в свою очередь является клиентом для сервера баз данных (рис. 69).

Наиболее часто в качестве сервера БД используется SQL-сервер.

Различают следующие механизмы доступа к БД: на стороне Web-сервера и на стороне Web-клиента.

В первом случае обращение к серверу БД производится следующим путем. Web-клиент заполняет специальную форму запроса к БД и пересылает ее Web-серверу. Программами Web-сервера вызываются внешние по отношению к ним программы в соответствии с соглашениями одного из интерфейсов: СGI или API. Внешние программы пишутся на языках программирования типа С++, Perl, PHP. Программы, написанные в соответствии с интерфейсом СGI, называются СGI-сценариями. Внешние программы взаимодействуют с сервером БД на языке SQL, преобразуя текст запроса в HTML-форме в SQL-запрос. После получения результатов запроса внешняя программа формирует требуемую HTML-страницу, передает ее Web-серверу, который пересылает ее Web-клиенту.

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

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

Развитие интернет-технологий стимулирует появление новых направлений в сфере сервиса. Уже никого не удивляют интернет-библиотеки, интернет-магазины, интернет-справочники. Интересным перспективным направлением в сфере сервиса является проект "интеллектуальная квартира". Например, одной из задач программы менеджера такой квартиры является следить за наличием в холодильнике заданного набора продуктов; при необходимости менеджер посылает заказ в интернет-магазин, который впоследствии выполняется.

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

 

Контрольные вопросы и задания

 

1. Определить основные понятия архитектуры "клиент-сервер".

2. Перечислить функции сервера баз данных.

3. Какой принцип является основой архитектуры "клиент-сервер"?

4. Нарисовать двухзвенную схему модели "клиент-сервер".

5. Охарактеризовать функции стандартного интерактивного приложения.

6. Назвать варианты разделения функций между компьютером-сервером и компьютером-клиентом для двухзвенной модели.

7. Охарактеризовать модель удаленного доступа к данным (RAD).

8. Назвать достоинства и недостатки модели сервера баз данных.

9. Какие средства относятся к категории программного обеспечения промежуточного слоя?

10. Определить назначение сервера приложений.

11. Что такое транзакция?

12. Указать функции монитора транзакций.

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

14. Охарактеризовать однородные распределенные системы.

15. Каким методом проектируются неоднородные распределенные системы?

16. Указать достоинства и недостатки метода фрагментации данных.

17. Описать метод тиражирования данных.

18. Перечислить характеристики "идеальной" РаСУБД.

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

20. Нарисовать модель доступа к данным на базе Интернет.

21. Указать основные механизмы доступа к БД в сети Интернет.

22. Каковы перспективы развития интернет-технологий в сфере сервиса?

 

6. СОВРЕМЕННОЕ СОСТОЯНИЕ И

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

 

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

Одним из направлений является развитие объектных технологий баз данных. Объектно-ориентированные языки программирования (такие как С++ и Java), объектно-ориентированные средства создания приложений и сетевого программирования стали базовыми технологиями разработки современного программного обеспечения. Идейную поддержку развитию данного направления оказал опубликованный в 1989 году "Манифест объектно-ориентированных систем баз данных", в котором содержались основные требования относительно обязательных свойств объектно-ориентированных баз данных, и, предполагалось, что новые системы должны строиться на базе объектно-ориентированного подхода, и нет особого смысла, так или иначе, использовать реляционный подход. В данном манифесте были приведены также необязательные свойства и открытые возможности объектных систем. В области формирования инфраструктуры объектных систем направляющую роль играет учрежденный в 1989 г. консорциум OMG (Object Management Group), целью которого является разработка и поддержка индустриальных стандартов архитектуры программного обеспечения промежуточного слоя (уровня архитектуры, занимающего промежуточное место между сетевым уровнем и уровнем приложений) для создания распределенных неоднородных объектных интероперабельных систем. Традиционно к промежуточному слою относились средства управления и доступа к данным, средства разработки программ, средства управления распределенными вычислениями (включая поддержку необходимых протоколов взаимодействия), средства поддержки пользовательского интерфейса и др. Такие инфраструктуры использовались как отдельными компаниями (IBM), так и в международных проектах (UNIX – ориентированная интеграционная среда). Применяемые идеи и технологии не позволяли до сих пор решить радикально архитектуру промежуточного слоя. OMG на основе объектной технологии и идеи интероперабельности вводит концепцию промежуточного слоя последовательно, радикально и до конца. Технически интероперабельность компонентов (представляемых объектами) решена введением базовой объектной модели, унифицированного языка спецификации интерфейсов объектов, отделением реализации компонентов от спецификации их интерфейсов, введением общего механизма поддержки интероперабельности объектов (брокера объектных заявок, играющего роль "общей шины", поддерживающей взаимодействие объектов). Тем самым достигается однородность представления компонентов и их взаимодействия. Далее, для формирования информационной архитектуры вводится слой унифицированных (ортогональных) служб, которые используются как при конструировании прикладных систем, так и для формирования функционально законченных средств промежуточного слоя, предлагающих конкретные виды услуг. Существенно, что и службы и средства представляются однородно своими объектными интерфейсами, что позволяет обеспечить их интероперабельность посредством брокера объектных заявок.

Базовый стандарт OMG – CORBA, принятый в 1991 г., получил широкое признание и активно применяется на практике. Наряду с созданием инфраструктуры для эффективного использования объектного подхода в технологиях баз данных архитектура CORBA предоставила один из методов обеспечения дальнейшего применения информационных ресурсов и функциональности унаследованных систем. Идея метода состоит в "объектизации" морально устаревшей системы путем создания для нее "обертки" (Wrapper) с помощью средств языка определения интерфейса IDL стандарта CORBA. Система превращается в обычный стандартный объект и может быть интегрирована в распределенную объектную среду.

К другим активно развиваемым важнейшим стандартам OMG относятся язык UML для объектного анализа и проектирования, стандарт XMI обмена метаданными между CASE-системами, основанный на языке XML.

Развитие производства объектных СУБД потребовало стандартизации модели данных и языковых средств, чтобы обеспечить переносимость приложений и ресурсов данных между объектными системами. Для решения этих задач ведущие поставщики объектных СУБД учредили консорциум ODMG (Object Database Management Group). В базовом стандарте ODMG определяются объектная модель, являющаяся расширением объектной модели CORBA, и язык определения объектов ODL. Был создан ряд чисто "объектных" программных продуктов, соответствующих различным компонентам данного стандарта: Objectivity/DB, GemStone, ObjectStore, POET, Versant и др. Объектно-ориентированная модель является наиболее подходящей платформой для CASE- и CAD-технологий.

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

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

Одновременно с развитием чисто "объектного подхода" разработчики реляционных баз данных развивают объектно-реляционную модель данных. На развитие данного направления повлияли идеи, высказанные в "Манифесте систем баз данных третьего поколения". Авторами были сформулированы основные принципы построения СУБД нового поколения, предполагающие развитие реляционной платформы с применением богатой системы типов и расширением объектно-ориентированными возможностями, в частности о расширении языка SQL базовыми объектными возможностями (SQL:1999). СУБД, поддерживающие объектно-реляционную модель данных, разрабатываются многими ведущими компаниями, производителями программного обеспечения: Informix Universal Database Server (Informix), DB2 Universal Database (IBM), Oracle8 (Oracle). В последнее время появились предложения о расширении SQL средствами интеграции с XML-данными, поддержки языка Java. Предполагается дальнейшее совершенствование стандарта SQL:1999 в рамках проекта SQL3.

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

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

Перспективным направлением развития взаимодействия Web-технологий и баз данных являются разработки систем баз данных XML. В программе работ по созданию новой версии стандарта языка SQL предусмотрено включение средств интеграции реляционных данных и XML-данных.

Одной из основных тенденций, определяющих современные направления развития технологий баз данных, является стремительный рост популярности хранилищ данных (Data Warehousing), концепция которых была разработана Б. Инмоном. Хранилище данных понимается как логически интегрированный источник данных для систем поддержки принятия решений (DSS) и информационных систем руководителя (EIS), который обеспечивает поддержку принятия стратегических решений в крупной организации на основе хранящихся исторических данных, отражающих деятельность этой организации за продолжительный период времени. Накапливая данные в хранилище, предприятие получает возможность проведения статистических исследований, анализа тенденций и перспектив развития, выявления слабых мест своей деятельности и скрытых резервов. Хранилища данных используются для принятия решений на основе сбора и анализа информации. Их главные пользователи – это менеджеры, служащие планового отдела и отдела маркетинга. Хранилища данных активно применяются в тех областях, где информация о тенденциях бизнеса служит основой для принятия решений, приводящих к значительной экономии средств или приносящих большую прибыль. Например, в крупных производствах – для анализа тенденций в области сбыта, в коммерции – для анализа эффективности мероприятий, направленных на увеличения сбыта и изучения демографических факторов, в финансовых структурах – для анализа факторов, связанных с получением и погашением кредитов клиентами и др. Хранилище данных – не то же самое, что база данных, так как данные, поступившие в хранилище, приобретают статус "неизменных". Вносимые изменения в хранилище носят характер только "пополнения", а не произвольных поэлементных обновлений, как в операционных базах данных, предназначенных для каждодневной деятельности предприятия.

Основные компоненты хранилища:

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

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

Ø Средства анализа данных – программный комплекс, выполняющий статистический и временный анализ и представление результатов в графической форме.

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

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

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

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

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

Программные средства, реализующие технологии OLAP и хранилищ данных, выпускаются многими производителями программных продуктов: IBM DB2 OLAP Server, Visual Warehouse (IBM); MetaCube (Informix); Oracle Data Mart Suite (Oracle); группа продуктов Express OLAP. Программные компоненты для поддержки функциональных возможностей OLAP и хранилищ данных предусмотрены в Microsoft SQL Server 2002 (Microsoft). Поддержка временных рядов реализована в продуктах Informix Universal Database Server и Oracle8.

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

Еще одним из перспективных направлений развития баз данных является развитие дедуктивных баз данных. Эти базы данных основаны на применении аппарата математической логики и средств логического программирования в области систем баз данных. Получение сведений из баз данных осуществляется не путем запросов или аналитической обработки, а путем использования правил вывода и построения цепочек применения этих правил для вывода ответов на запросы. Для этих баз данных существуют языки запросов, отличные от SQL.

Дальнейшее развитие архитектурных подходов информационных систем связано с архитектурой "клиент-сервер". По такому принципу строятся сервисы CORBA, Интернет, современные серверы баз данных.

Развитие архитектуры распределенных систем связано с концепцией промежуточного слоя. Имеются в виду средства программного обеспечения, позволяющие изолировать приложения от сетевых протоколов и особенностей конкретных операционных систем. На принципах промежуточного слоя строятся многие стандартные интерфейсы распределенных систем, например, ODBC, JDBC. Одной из важнейших задач средств промежуточного слоя – обеспечение интероперабельности (способности системы к взаимодействию с другими системами) программных продуктов различных поставщиков.

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

В ближайшее время возможно появление принципиально новых подходов и направлений в области баз данных. Технической базой для этого могут служить такие прогрессивные технологии повышения производительности, как RAID (Redundat Arrays of Inexpensive disk – эта аббревиатура обычно расшифровывается как "избыточные массивы недорогих дисков"). Сочетание быстро увеличивающейся мощности обработки с возможностью значительно быстрого выполнения операций ввода-вывода в действительности приведет к появлению среды, в которой увеличение производительности обработки транзакций аппаратным путем представляется приемлемым и желательным решением проблемы.

Эксперты определяют следующие основные направления исследований в области баз данных:

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

Ø Создание новых технологий для крупномасштабных федеративных систем. Примером такой системы является Web. К кругу проблем данного направления относится обработка запросов большой вычислительной сложности.

Ø Разработка новых подходов к архитектуре систем баз данных. Эксперты полагают, что необходимо пересмотреть 20-летние архитектурные принципы организации системы баз данных в связи с изменением аппаратурных средств. Например, при объеме оперативной памяти в пределах терабайта традиционные подходы оказываются неэффективными.

Ø Интеграция структурированных и слабоструктурированных данных. Имеется в виду интеграция технологий баз данных и Web-технологий.

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

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

 

Контрольные вопросы и задания

 

1. Дать характеристику объектно-ориентированной технологии баз данных.

2. Перечислить чисто "объектные" программные продукты.

3. Каковы достоинства и недостатки ООБД?

4. Указать тенденции развития реляционных баз данных.

5. Каковы перспективы интеграции технологий баз данных и Web-технологий?

6. Что такое хранилище данных?

7. Перечислить основные компоненты хранилища.

8. Дать характеристику OLAP-системам.

9. Каковы современные направления и архитектурные подходы в развитии распределенных систем?

10. Что такое RAID-технологии?

11. Охарактеризовать основные направления исследований в области баз данных.

Заключение

 

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

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

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

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

 

библиографический список

 

1. Базы данных: достижения и перспективы на пороге XXI столетия: Пер. с англ. / Под ред. А. Зильбершатца, М. Стоунбрекера и Дж. Ульмана // СУБД. 1996. № 3. С. 103–117

2. Баркер Скотт Ф. Профессиональное программирование в Microsoft Access 2002: Пер. с англ. М.: Издательский дом "Вильямс", 2002. 992 с.

3. Боровиков В.В. Microsoft Access 2002. Программирование и разработка баз данных и приложений. М.: СОЛОН-Р, 2002. 560 с.

4. Брукшир Дж. Гленн. Введение в компьютерные науки. Общий обзор. 6-е изд.: Пер. с англ. М.: Издательский дом "Вильямс", 2001. 688 с.

5. Вендров А. М. Проектирование программного обеспечения экономических информационных систем. М.: Финансы и статистика, 2000. 352 с.

6. Вендров А. М. CASE-технологии. Современные методы и средства проектирования информационных систем. М.: Финансы и статистика, 1998. 176 с.

7. Виллариал Б.. Программирование в Access 2002 в примерах: Пер. с англ. М.: КУДИЦ-ОБРАЗ, 2003. 496 с.

8. Григорьев Ю. А., Ревунков Г. И. Банки данных: Учеб. для вузов. М.: Изд-во МГТУ им. Н. Э. Баумана, 2002. 320 с.

9. Дарвин Х., Дейт К. Третий манифест: Пер. с англ. // СУБД. 1996. № 1. С. 110–123

10. Дейт К. Дж. Введение в системы баз данных. 6-е изд.: Пер. с англ. М.: Издательский дом "Вильямс", 2000. 848 с.

11. Дженнингс Р. Использование Microsoft Access 2002. Спец. изд.: Пер. с англ. М.: Издательский дом "Вильямс", 2002. 1012 с.

12. Дунаев С. С. Доступ к базам данных и техника работы в сети. Практические приемы современного программирования. М.: Диалог – МИФИ, 1999.

13. Зильбершац А, Здоник С. Стратегические направления в системах баз данных: Пер. с англ. // СУБД. 1997. № 4. С. 4–23

14. Карпова Т.С. Базы данных: модели, разработка, реализация. СПб.: Питер, 2001. 304 с.

15. Когаловский М.Р. Энциклопедия технологий баз данных. М.: Финансы и статистика, 2002. 800 с.

16. Корнеев В. В., Гареев А. Ф. и др. Базы данных. Интеллектуальная обработка информации. М.: Изд-во Нолидж, 2001. 496 с.

17. Литвин П, Гетц К, Гунделой М. Разработка корпоративных приложений в Access 2002. Для профессионалов. СПб.: Питер; Киев: BHV, 2003. 848 с.

18. Мартен Д. Базы данных: практические методы. М.: Радио и связь, 1983. 168 с.

19. Мартин Дж.. Организация баз данных в вычислительных системах. М.: Мир, 1980. 662 с.

20. Мейер Д. Теория реляционных баз данных. М.: Мир, 1987. 608 с.

21. Михеева В. Д., Харитонова И.А.. Microsoft Access 2002. СПб.: БВХ-Петербург, 2002. 1040 с.

22. Послед Б.С. Access 2002. Приложения баз данных: Лекции и упражнения. СПб., 2002. 656 с.

23. Риордан Р.М. Программирование в Microsoft SQL Server 2000. Шаг за шагом: Практ. пособ. / Пер. с англ. М.: Изд-во ЭКОМ, 2002. 608 с.

24. Саймон А.Р. Стратегические технологии баз данных: менеджмент на 2000 год: Пер. с англ. / Под ред. и с предисл. М.Р. Когаловского. М.: Финансы и статистика, 1999. 479 с.

25. Слама Д., Гарбис Д., Рассел П. Корпоративные системы на основе CORBA: Учеб. пособ.: Пер. с англ. М.: Издательский дом "Вильямс", 2000. 368 с.