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

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

операнда, которые были указаны в проекции.

^ Оператор проекции обозначается [S" ] или π . Здесь S" – подсхема исходной схемы отношения S , т. е. ее некоторые столбцы. Что это означает? Это означает, что у S’ атрибутов меньше, чем у S , потому что в S" остались только те из них, для которых выполнилось условие проекции. А в таблице, представляющей отношение r (S" ), строк столько же, сколько их у таблицы r (S ), а столбцов – меньше, так как остались только соответствующие оставшимся атрибутам. Таким образом, оператор проекции π< S"> применительно к отношению r (S ) дает в результате новое отношение с другой схемой отношения r (S" ), состоящее из проекций t (S ) [S" ] кортежей исходного отношения. Как определяются эти проекции кортежей? Проекция любого кортежа t (S ) исходного отношения r (S ) на подсхему S" определяется следующей формулой:

t (S ) [S’ ] = {t (a )|a ∈ def (t ) ∩ S ’}, S " ⊆S .

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

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

π <S" >r (S ) ≡ π <S’ >r ≡ r (S ) [S ’] ≡ r [S" ] = {t (S ) [S’ ] | t ∈ r };

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

Пусть дано отношение «Сессия» и схема этого отношения:

S : Сессия (№ зачетной книжки, Фамилия, Предмет, Оценка);

Нас будут интересовать только два атрибута из этой схемы, а именно «№ зачетной книжки» и «Фамилия» студента, поэтому подсхема S" будет выглядеть следующим образом:

^ S" : (№ зачетной книжки, Фамилия).

Нужно исходное отношение r (S ) спроецировать на подсхему S" .

t 0 (S ) ∈ r (S ): {(№ зачетной книжки: 100), (Фамилия: ‘Иванов’), (Предмет: ‘Базы данных’), (Оценка: 5)};

Значит, проекция этого кортежа на данную подсхему ^ S" будет выглядеть следующим образом:

t 0 (S ) S" : {(№ зачетной книжки: 100), (Фамилия: ‘Иванов’)};

Если говорить об операции проекции в терминах таблиц, то проекция Сессия [№ зачетной книжки, Фамилия] исходного отношения – это таблица Сессия, из которой вычеркнуты все столбцы, кроме двух: № зачетной книжки и Фамилия. Кроме того, все дублирующиеся строки также удалены.

^

3. Унарная операция переименования

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

^ Оператор переименования выглядит следующим образом: ρ<φ >, здесь φ – функция переименования .

Эта функция устанавливает взаимно

однозначное соответствие между именами атрибутов схем S и Ŝ, где соответственно S – схема исходного отношения, а Ŝ – схема отношения с переименованными атрибутами. Таким образом, оператор ρ <φ> в применении к отношению r (S ) дает новое отношение со схемой Ŝ , состоящее из кортежей исходного отношения только с переименованными атрибутами.

Запишем операцию переименования атрибутов в терминах систем управления базами данных:

ρ <φ > r (S ) ≡ ρ <φ >r = {ρ <φ > t (S )| t ∈ r };

Приведем пример использования этой операции:

Рассмотрим уже знакомое нам отношение Сессия, со схемой:

S: Сессия (№ зачетной книжки, Фамилия, Предмет, Оценка);

Введем новую схему отношения Ŝ, с другими именами атрибутов, которые мы бы хотели видеть вместо имеющихся:

Ŝ : (№ ЗК, Фамилия, Предмет, Балл);

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

φ : (№ зачетной книжки, Фамилия, Предмет, Оценка) → (№ ЗК, Фамилия, Предмет, Балл);

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

φ : (№ зачетной книжки, Оценка) → (№ ЗК, Балл);

t 0 (S ) ∈ r (S ): {(№ зачетной книжки: 100), (Фамилия: ‘Иванов’), (Предмет: ‘Базы данных’), (Оценка: 5)};

Применим оператор переименования к этому кортежу:

ρ<φ> t 0 (S ): {(№ ЗК: 100), (Фамилия: ‘Иванов’), (Предмет: ‘Базы данных’), (Балл: 5)};

Итак, это один из кортежей нашего отношения, у которого переименовали атрибуты.

В табличных терминах отношение

ρ < № зачетной книжки, Оценка → «№ ЗК, Балл > Сессия –

это новая таблица, полученная из таблицы отношения «Сессия», переименованием указанных атрибутов.

^

4. Свойства унарных операций

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

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

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

1) соотношение мощностей:

а) для операции выборки: | σ <P >r |≤ |r |;

б) для операции проекции: | r [S" ] | ≤ |r |;

в) для операции переименования: | ρ <φ >r | = |r |;

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

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

2) свойство идемпотентности:

а) для операции выборки: σ <P > σ <P >r = σ <P >;

б) для операции проекции: r [S’ ] [S’ ] = r [S" ];

в) для операции переименования в общем случае свойство идемпотентности неприменимо.

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

либо отношению равносильно его однократному применению.

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

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

И последнее свойство, которое мы рассмотрим, – это свойство монотонности. Интересно заметить, что при любых условиях все три оператора монотонны;

3) свойство монотонности:

а) для операции выборки: r 1 ⊆ r 2 ⇒ σ <P > r 1 ⇒ σ <P >r 2 ;

б) для операции проекции: r 1 ⊆ r 2 ⇒ r 1 [S" ] ⊆ r 2 [S" ];

в) для операции переименования: r 1 ⊆ r 2 ⇒ ρ <φ >r 1 ⊆ ρ <φ >r 2 ;

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

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

• деревья (a) и (b), показанные на рис. 4.2 , заменяются одной сетевой структурой, в которой запись СОТРУДНИК входит в два групповых отношения;
• для отображения типа M:N вводится запись СОТРУДНИК_КОНТРАКТ, которая не имеет полей и служит только для связи записей КОНТРАКТ и СОТРУДНИК, (см. рис. 4.3). Отметим, что в этой записи может храниться и полезная информация, например, доля данного сотрудника в общем вознаграждении по данному контракту.

Рис. 4.3.

Каждый экземпляр группового отношения характеризуется следующими признаками:

Способ упорядочения подчиненных записей:

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

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

Режим включения подчиненных записей:

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

Режим исключения.

Принято выделять три класса членства подчиненных записей в групповых отношениях:

• Фиксированное. Подчиненная запись жестко связана с записью владельцем и ее можно исключить из группового отношения только удалив. При удалении записи -владельца все подчиненные записи автоматически тоже удаляются. В рассмотренном выше примере фиксированное членство предполагает групповое отношение "ЗАКЛЮЧАЕТ" между записями "КОНТРАКТ" и "ЗАКАЗЧИК", поскольку контракт не может существовать без заказчика.
• Обязательное. Допускается переключение подчиненной записи на другого владельца, но невозможно ее существование без владельца. Для удаления записи-владельца необходимо, чтобы она не имела подчиненных записей с обязательным членством. Таким отношением связаны записи "СОТРУДНИК" и "ОТДЕЛ". Если отдел расформировывается, все его сотрудники должны быть либо переведены в другие отделы, либо уволены.
• Необязательное. Можно исключить запись из группового отношения, но сохранить ее в базе данных не прикрепляя к другому владельцу. При удалении записи -владельца ее подчиненные записи - необязательные члены сохраняются в базе, не участвуя более в групповом отношении такого типа. Примером такого группового отношения может служить "ВЫПОЛНЯЕТ" между "СОТРУДНИКИ" и "КОНТРАКТ", поскольку в организации могут существовать работники, чья деятельность не связана с выполнением каких-либо договорных обязательств перед заказчиками.

Операции над данными в сетевой модели БД

Ограничения целостности

Как и в иерархической модели обеспечивается только поддержание целостности по ссылкам (владелец отношения - член отношения).

Достоинства и недостатки ранних СУБД

Достоинства ранних СУБД:

• развитые средства управления данными во внешней памяти на низком уровне;
• возможность построения вручную эффективных прикладных систем;
• возможность экономии памяти за счет разделения подобъектов (в сетевых системах)

Недостатки ранних СУБД:

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

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

Объектно-ориентированные СУБД

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

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

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

Структура

Структура объектной модели описывается с помощью трех ключевых понятий:

Целостность данных

Для поддержания целостности объектно-ориентированный подход предлагает использовать следующие средства:

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

Средства манипулирования данными

К сожалению, в объектно-ориентированном программировании отсутствуют общие средства манипулирования данными, такие как реляционная алгебра или реляционное счисление. Работа с данными ведется с помощью одного из объектно-ориентированных языков программирования общего назначения, обычно это SmallTalk, C++ или Java.

Подведем теперь некоторые итоги

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

В то же время, ОО - модели присущ и ряд недостатков :

• отсутствуют мощные непроцедурные средства извлечения объектов из базы. Все запросы приходится писать на процедурных языках, проблема их оптимизации возлагается на программиста;
• вместо чисто декларативных ограничений целостности (типа явного объявления первичных и внешних ключей реляционных таблиц с помощью ключевых слов PRIMARY KEY и REFERENCES ) или полудекларативных триггеров для обеспечения внутренней целостности приходится писать процедурный код.

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

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

Поехали …

Что такое SQL?

SQL (Structured Query Language) – структурированный язык запросов, универсальный компьютерный язык, применяемый для создания, модификации и управление данными в реляционных базах данных

Что такое реляционная база данных?

Это совокупность взаимосвязанных данных хранящихся в виде отношений

Что такое отношения?

Отношение это некое множество картежей

Что такое кортеж?

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

Продемонстрирую кортеж из двух элементов с помощью графа:

Вершины графа это элементы их некоторого множества, в данном случае, это элемент а1 из множества А и элемент b1 из множества B . Ребро между вершинами обозначает связь между элементами или как говорят элемент а1 находится в отношение с b1 .

Продемонстрирую этот же кортеж с помощью таблицы:

Номер 1 у а1 и b1 , был выбран произвольно.

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

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

Продемонстрирую, как представить отношение в виде графа:

На графике видно, что есть несколько кортежей, причем какой кортеж первый, а какой второй и третий не важно , это просто множество кортежей. В множестве нет такого понятия «первый», «второй» и «третий», это всё сразу и очередность не важна.

Продемонстрирую, как представить отношение в виде таблицы:

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

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

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

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

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

1. Селекция (другие имена операции — выборка, ограничение)

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

Пусть есть отношение, назовем его «исходная таблица №1»:

Результат «выборки» из исходной таблицу №1, при условии что А=а3

На языке SQL:

синтаксис — SELECT * FROM имя_таблицы WHERE имя_столбца=значение

SELECT * FROM исходная_таблица WHERE А=a3

2. Проекция

Операция «проекция» выполняется над одним отношением , в результате неё формируется новое отношение с указанными столбцами таблицы .

Например, есть отношение, назовем ее «исходная таблица №2»:

Произведем над данным отношением операцию «проекция» по атрибутам А и С , результат:

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

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

На языке SQL:

синтаксис — SELECT список_столбцов FROM имя_таблицы

реализация для данного случая — SELECT А,С FROM исходная_таблица_№2

3. Естественное соединение

Операция «естественное соединение » выполняется над двумя логическими связанными отношениями , в результате неё формируется новое отношение со столбцами первого и второго отношения и с кортежами, которые получаются в результате соединения каждого кортежа первого и второго отношения . На примере должно быть более понятно, пусть есть два отношения, назовем их исходная таблица №3.1 и исходная таблица №3.2:

Исходная таблица №3_1

Исходная таблица №3_2

Проведем операцию «соединения» первого и второго отношения, результат:

Интересно заметить, что мы получили исходное отношение из раздела «2. Проекция», последовательность столбцов в отношение значения не имеет.

На языке SQL:

реализация для данного случая — SELECT исходная_таблица_№3_1.*, исходная таблица №3_2.В FROM исходная_таблица_№3_1, исходная таблица №3_2 WHERE исходная таблица №3_1.A= исходная таблица №3_2.A

4. Объединение

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

Исходная таблица №4_1

Исходная таблица №4_2

Произведем операцию «объединения» отношения №4.1 и отношения №4.2 , результат:

На языке SQL:

синтаксис — SELECT список_столбцов_таблицы1 FROM таблица1 UNION SELECT список_столбцов_таблицы2 FROM таблица2

реализация для данного случая — SELECT А,В FROM исходная_таблица_№4_1 UNION SELECT А,В FROM исходная_таблица_№4_2

5. Пересечение

Операция «пересечение» выполняется , результат операции новое отношение, которое включает в себя одинаковые кортежи «первого» и «второго» отношения .

Пример, пусть есть два отношения:

Исходная таблица №5_1

Исходная таблица №5_2

Произведем операцию «пересечения» с данными отношениями, результат:

Т.е. в результирующее отношение, попали повторяющиеся кортежи из «первого» и «второго» отношения.

На языке SQL:

синтаксис — SELECT одна_из_таблиц.столбец1, одна_из_таблиц.столбец2, … FROM таблица1,таблица2 WHERE таблица1.столбец1=таблица2.столбец1 AND таблица1.столбец2= таблица2.столбец2 AND …

реализация для данного случая –

SELECT исходная_таблица_№5_1.А, исходная_таблица_№5_1.В FROM исходная_таблица_№5_1, исходная_таблица_№5_2 WHERE исходная_таблица_№5_1.А = исходная_таблица_№5_2.А AND исходная_таблица_№5_1.В = исходная_таблица_№5_2.В

6. Вычитание (разность)

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

Пример, пусть есть два отношения:

Исходная таблица №6_1

Исходная таблица №6_2

Произведем операцию «разность» , т.е. от исходной таблицы №6_1 отнимем исходную таблицу №6_2, результат:

Т.е. результирующее отношение, это «первое» отношение без повторяющихся кортежей «второго» отношения.

На языке SQL:

реализация для данного случая – SELECT исходная_таблица_№6_1.А, исходная_таблица_№6_1.В FROM исходная_таблица_№6_1 WHERE NOT EXISTS (SELECT исходная_таблица_№6_2.А, исходная_таблица_№6_2.В FROM исходная_таблица_№6_2
WHERE исходная_таблица_№6_2.А= исходная_таблица_№6_1.А AND исходная_таблица_№6_2.В= исходная_таблица_№6_1.В)

7. Декартово произведение

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

Пример, пусть есть два произвольных отношения:

Исходная таблица №7_1

Исходная таблица №7_2

Произведем «декартово произведение» данных двух отношений, результат:

На языке SQL:

реализация для данного случая – SELECT исходная_таблица_№7_1.А, исходная_таблица_№7_1.В, исходная_таблица_№7_2.А, исходная_таблица_№7_2.В FROM исходная_таблица_№7_1, исходная_таблица_№7_2

Мы разобрались с основными операции над отношениями и напоследок теоретической части поста разберемся что такое ключ.

Что такое ключ?

Ключ – это один или не сколько столбцов таблицы , которые однозначно определяют запись (строку) . Пример, пусть есть отношение представленное в виде таблицы:

Ключом данного отношения может быть столбец А . Т.к. значения только данного столбца в отношение , например: а3 определяет запись «а3 b1 d3» , a2 определят запись «a2 b2 d3» , a1 определяет запись «a1 b2 d1» . Другие столбцы данную функцию нести не могут.

Если ключ состоит из одного столбца , то его называют простым , если из нескольких его называют составным . В данной таблице, помимо простого ключа, есть еще один – составной, состоящий из столбцов B и D . Значения этих столбцов однозначной определят запись (строки), пример: b1 и d3 однозначно определяет запись «a3 b1 d3» , b2 и d3 однозначной определяет запись «a2 b2 d3» , b2 и d1 однозначно определяет запись «a1 b2 d1» .

На практике обычно выбирают один ключ , причем самый простой , в данном случае это столбец А . Такой ключ также называют «первичный ключ ».

Вам будет интересно:

Введение. 4

1. Базы данных и СУБД 6

2. Реляционные базы данных 20

3. Операции над таблицами реляционных баз данных 29

4. Разработка инфологических моделей 49

5. Организация доступа к данным 64

6. Принципы построения систем, ориентированных на анализ данных 96

Заключение. 106

Список наиболее часто встречающихся сокращений. 107

Введение.

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

1. 
   концепция баз данных, архитектура СУБД (инфологическая модель данных, даталогическая модель данных, физическая модель данных, типы даталогических моделей данных, иерархическая даталогическая модель, сетевая даталогическая модель, даталогическая модель на основе инвертированных списков, реляционная даталогическая модель, объектно-реляционная даталогическая модель);
2. 
   реляционные базы данных (основные понятия реляционных баз данных, тип данных, домен, схема отношения, схема базы данных, кортеж, отношение, целостность реляционных баз данных, основные свойства отношений реляционных баз данных);
3. 
   операции над таблицами реляционных баз данных (операции теории множеств, нормализация отношений реляционных баз данных);
4. 
   использование языка ER-диаграмм для построения инфологических моделей (диаграммы "сущность-связь", информационное моделирование, методология IDEF1X, этапы разработки инфологической модели данных);
5. 
   организация доступа к данным (средства ускоренного доступа к данным, язык запросов, обработка транзакций, средства восстановления после сбоев);
6. 
   принципы построения систем, ориентированных на анализ данных (хранилища данных; модели данных, используемые при построении хранилищ данных).

1. Базы данных и СУБД

Восприятие реального мира можно соотнести с последовательностью разных, хотя иногда и взаимосвязанных, явлений. С давних времен люди пытались описать эти явления (даже тогда, когда не могли их понять). Такое описание называют данными .

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

Нередко данные и интерпретация разделены. Например, "Расписание движения самолетов" может быть представлено в виде таблицы (рис. 1.1.1), в верхней части которой (отдельно от данных) приводится их интерпретация. Такое разделение затрудняет работу с данными (попробуйте быстро получить сведения из нижней части таблицы).

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

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

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

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

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

При выполнении основных из этих функций СУБД должна использовать различные описания данных. А как создавать эти описания?

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

1.2.1. Инфологическая модель данных

Рис. 1.2.1. Уровни моделей данных

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

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

1.2.2. Даталогическая модель данных

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

1.2.3. Физическая модель данных

• 
  ограничения на длину имен объектов базы данных (таблиц, столбцов, индексов),
• 
  использование специальных символов в именах,
• 
  допустимые типы данных и их внутреннее представление на устройствах хранения данных в ЭВМ.

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