Базы данных. Курс лекций

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

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

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

2.Модели данных

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

По концепции формирования модели данных разделяются следующим образом (рис. 2).

2.1.Картотеки

Название происходит от «карто-» и «тека», т. е. собрание, хранилище (как библиотека – книгохранилище). Внимание обращается на сущность хранящихся в

10

«-теке» предметов: книг, карточек. С картотеками мы встречаемся часто в библиотеках — знаменитые шкафы с многочисленными карточками, на которых отражено содержимое библиотеки – каталог библиотеки.

Базы данных

Многометные

Рис. 2. Классификация моделей представления данных

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

2.2. Иерархические

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

Иерархическая БД состоит из упорядоченного набора деревьев (экземпляров). В иерархических структуpax сегмент-потомок должен иметь в точности одного предка.

11

ПОКУПАТЕЛЬ

ИМЯ

АДРЕС

ТЕЛЕФОН

НОМЕР_СЧЕТА

ЗАКАЗ

НОМЕР_ЗАКАЗА

ДАТА_ЗАКАЗА

СТОИМОСТЬ

Рис. 3. Пример схемы иерархической БД

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

«заказ».

ПОКУПАТЕЛЬ

Школа «Феникс» Москва 499 125 10 10 8881250357

ЗАКАЗЫ

………………………………………

Рис. 4. Один экземпляр дерева

В этой БД запрос, направленный вниз по иерархии, прост (например: какие заказы принадлежат этому покупателю); однако запрос, направленный вверх по иерархии, более сложен (например, какой покупатель поместил этот заказ).

12

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

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

2.3. Сетевые

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

2.4. Реляционные

Реляционные базы данных (РБД), основанные на реляционной модели. Слово «реляционный» происходит от английского «relation» (отношение). Для работы с реляционными БД применяют реляционные СУБД. Теория реляционных баз данных была разработана доктором Коддом из компании IBM в 1970 г.

Эдгар Франк Тед Кодд (23 августа 1923 г. – 18 апреля 2003 г.)

– британский ученый, работы которого заложили основы тео-

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

математике и химии в Оксфордском университете (Exeter College). Во время Второй мировой войны служил пилотом в военно-воздушных силах. В 1948 г. переехал в Нью-Йорк, чтобы работать в IBM как математик-программист. В 1953 г. из-за преследований со стороны сенатора

13

Джозефа Маккарти (Joseph McCarthy) Кодд переехал в Оттаву (Канада). В 1963 г. он вернулся в США и получил докторскую степень по информатике и вычислительной технике в Университе-

те Мичигана (University of Michigan, Ann Arbor). В 1965 г. переехал в Сан-Хосе (Калифорния),

чтобы работать в Альмаденском исследовательском центре IBM. В 60-х – 70-х годах он работал над своими теориями хранения данных. В 1970 г. издал работу «A Relational Model of Data for Large Shared Data Banks», которая считается первой работой по реляционной модели данных. Кодд продолжил разрабатывать и расширять реляционную модель. Одна из нормальных форм названа в его честь (нормальная форма Бойса-Кодда). В начале 80-х годов реляционная модель начала входить в моду. Борясь с недобросовестными поставщиками СУБД, которые утверждали, что их устаревшие продукты поддерживают реляционную технологию, Кодд опубликовал «12 правил Кодда», описывающих, что должна содержать реляционная СУБД. Его борьба коснулась языка SQL, который Кодд считал неправильной реализацией теории. Это делало его положение в компании IBM достаточно тяжелым, так как та поставляла продукты, основанные на SQL. Он покинул IBM и организовал вместе с Кристофером Дейтом и несколькими другими людьми собственную консалтинговую компанию. Кодд ввел в оборот термин OLAP и написал 12 законов аналитической обработки данных. Он также занимался клеточными автоматами. В 1976 г. Кодд получил почетное звание IBM Fellow. В 1981 г. получил премию Тьюринга. В 2002 г. журнал Forbes поместил реляционную модель данных в список важнейших инноваций последних 85 лет. Эдгар Ф. Кодд умер от сердечного приступа у себя дома во Флориде на острове Вильямс в возрасте 79 лет в пятницу 18 апреля 2003 г. У него было четверо детей и шесть внуков.

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

•данные хранятся в таблицах, состоящих из столбцов и строк;

•на пересечении каждого столбца и строки стоит в точности одно значение;

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

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

14

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

Общепринятым стандартом языка работы с реляционными базами данных является язык SQL.

2.5. Объектно-ориентированные

Объектно-ориентированные – базы данных, в которых объектная ориентация сочетается с возможностями баз данных. Объектная ориентация дает возможность более непосредственно представлять и моделировать проблемы реального мира, а функциональность баз данных требуется для обеспечения стабильности данных и многопользовательского параллельного доступа к информации приложений. Разработка систем объектно-ориентированных баз данных (так называемые технологии баз данных пятого поколения) началась в середине 1980- х годов в связи с необходимостью удовлетворения требований приложений, отличных от тех приложений обработки данных, которые характерны для систем реляционных баз данных (технология баз данных четвертого поколения). Попытки использования технологий реляционных баз данных в таких сложных приложениях, как автоматизированное проектирование (computer aided design, CAD); автоматизированное производство (computer aided manufacturing, CAM); технология программирования; системы, основанные на знаниях, и мультимедийные системы, обнажили ограничения систем реляционных баз данных (РБД). В условиях, когда появилось новое поколение приложений баз данных, возникли потребности, которые лучшим образом удовлетворялись при применении объектно-

ориентированных баз данных (ООБД).

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

15

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

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

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

Вбольшинстве моделей допускается перегрузка унаследованных свойств и методов. Перегрузка состоит в замене базового набора свойств новым или в замене одной реализации метода другой его реализацией [7].

Внастоящее время на рынке представлено свыше 25 систем ООБД. Среди них система GemStone компании Servio, ONTOS компании Ontos, ObjectStore

компании Object Design и многие другие1. Кроме того, системы управления реляционными базами данных, разработанные компаниями Oracle, Microsoft, Borland, Informix, включали объектно-ориентированные средства. Многие из этих продуктов появились еще во второй половине 80-х годов, и сегодня, по прошествии полутора десятилетий разработки, они все еще не вступили в пору зрелости; в этом одна из причин того, что по сей день мировой рынок реальных приложений не торопится принимать системы ООБД. Среди современных ООБД почти нет полностью оперившихся систем, сопоставимых с современными системами реляционных баз данных. Обсудим основные достижения и проблемы, связанные с нынешним состоянием ООБД.

2.6.Многомерные

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

1 Leung T. W., et al, «Aqua Data Model and Algebra». Technical Report CS-93-09, Brown University, Mar. 1993.

16

Набор соответствующих кубов составляет многомерную базу данных (или хранилище данных). Технология многомерных баз данных, сложившаяся в последние десять лет, – ключевой фактор интерактивного анализа больших массивов данных с целью поддержки принятия решения. Подобные базы данных трактуют данные как многомерные кубы, что очень удобно именно для их анализа. Однако централизация и удобное структурирование – это далеко не все, что нужно аналитику. Необходим инструмент для просмотра и визуализации информации. Традиционные отчеты, даже построенные на основе единого хранилища, лишены гибкости. Их нельзя «покрутить», «развернуть» или «свернуть», чтобы получить желаемое представление данных, что недостаточно для быстрого и полного анализа ситуации. Чем больше «срезов» и «разрезов» данных можно получить, тем больше возможностей для анализа. В качестве такого инструмента и выступает OLAP2, предоставляющий удобные быстродействующие средства доступа, просмотра и анализа деловой информации. Двенадцать определяющих принципов OLAP сформулировал в 1993 г. Ф. Кодд – основоположник реляционных БД. Позже его определение было переработано в так называемый тест FASMI3, требующий, чтобы OLAP-приложение предоставляло возможности быстрого анализа разделяемой многомерной информации. Пользователь получает естественную, интуитивно понятную модель данных, организуя их в виде многомерных кубов (cubes). Осями многомерной системы координат служат основные атрибуты анализируемого бизнес-процесса. Например, для продаж это могут быть товар, регион, тип покупателя. В качестве одного из измерений используется время. На пересечениях осей – измерений (Dimensions) – находятся данные, количественно характеризующие процесс, – меры (Measures). Это могут быть объемы продаж в штуках или в денежном выражении, остатки на складе, издержки и т. п. Пользователь, анали-

2OLAP — это Online Analytical Processing, т. е. оперативный анализ данных.

3Fast (быстрый) — анализ должен производиться одинаково быстро по всем аспектам информации. Приемлемое время отклика — 5 с или менее.

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

Multidimensional (многомерной) — это основная, наиболее существенная характеристика OLAP. Information (информации) — приложение должно иметь возможность обращаться к любой нужной информации независимо от ее объема и места хранения.

17

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

процессе анализа.

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

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

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

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

18

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

На рис. 6 изображен двумерный срез куба для одной меры – Unit Sales (продано штук) и двух «неразрезанных» измерений – Store (магазин) и Time (время). На рис. 7 представлено лишь одно «неразрезанное» измерение – Store, но зато здесь отображаются значения нескольких мер – Unit Sales (продано штук), Store Sales (сумма продажи) и Store Cost (расходы магазина).

Двумерное представление куба возможно и тогда, когда «неразрезанными» остаются и более двух измерений. При этом на осях среза (строках и столбцах) будут размещены два или более измерений «разрезаемого» куба – см. рис. 8.

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

Рис. 8. Двумерный срез куба с несколькими измерениями на одной оси

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

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

19