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

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

Для чего нужны базы данных

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

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

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

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

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

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

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

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

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

управление данными во внешней памяти (на дисках);

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

поддержание языков БД (язык определения данных, язык манипулирования данными).

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

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

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

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

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

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

1.1.Типы и структуры данных

1.1.1.Основные типы данных.

Данные, хранящиеся в памяти ЭВМ представляют собой совокупность нулей и едениц (битов). Биты объединяются в последовательности: байты, слова и т.д. Каждому участку оперативной памяти, который может вместить один байт или слово, присваивается порядковый номер (адрес).

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

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

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

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

* Запись(декартово произведение) - совокупность элементов данных разного типа. В простейшем случае запись содержит постоянное количество элементов, которые называют полями. Совокупность записей одинаковой структуры называется файлом. (Файлом называют также набор данных во внешней памяти, например, на магнитном диске). Для того, чтобы иметь возможность извлекать из файла отдельные записи, каждой записи присваивают уникальное имя или номер, которое служит ее идентификатором и располагается в отдельном поле. Этот идентификатор называют ключом.

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

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

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

1.1.2.Обобщенные структуры или модели данных.

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

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

Любая модель данных должна содержать три компоненты:

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

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

3. ограничения целостности - механизм поддержания соответствия данных предметной области на основе формально описанных правил.

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

В последнее время все большее значение приобретает объектно-ориентированный подход к представлению данных (параграфы 6.3 и 6.4). 1.2.Методы доступа к данным.

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

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

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

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

1.2.1.Методы поиска по дереву.

Определение: Деревом называется конечное множество, состоящее из одного или более элементов, называемых узлами, таких, что:

1. между узлами имеет место отношение типа "исходный-порожденный";

2. есть только один узел, не имеющий исходного. Он называется корнем;

3. все узлы за исключением корня имеют только один исходный; каждый узел может иметь несколько порожденных;

4. отношение "исходный-порожденный" действует только в одном направлении, т.е. ни один потомок некоторого узла не может стать для него предком.

Число порожденных отдельного узла (число поддеревьев данного корня) называется его степенью. Узел с нулевой степенью называют листом или концевым узлом. Максимальное значение степени всех узлов данного дерева называется степенью дерева.

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

Упорядоченное дерево, степень которого не больше 2 называется бинарным деревом. Бинарное дерево особенно часто используется при поиске в оперативной памяти. Алгоритм поиска: вначале аргумент поиска сравнивается с ключом, находящимся в корне. Если аргумент совпадает с ключом, поиск закончен, если же не совпадает, то в случае, когда аргумент оказвается меньше ключа, поиск продолжается в левом поддереве, а в случае когда больше ключа - в правом поддереве. Увеличив уровень на 1 повторяют сравнение, считая текущий узел корнем.

Пример: Пусть дан список студентов, содержащий их фамили и средний бал успеваемости (см. таблицу 1.1). В качестве ключа используется фамилия студента. Предположим, что все записи имеют фиксированную длину, тогда в качестве указателя можно использовать номер записи. Смещение записи в файле в этом случае будет вычислятся как ([номер_записи] -1 ) * [длина_записи]. Пусть аргумент поиска "Петров". На рисунке 1.2 показаны одно из возможных для этого набора данных бинарных деревьев поиска и путь поиска.

Заметим, что здесь используется следующее правило сравнения строковых переменных: считается, что значение символа соответствует его порядковому номеру в алфавите. Поэтому "И" меньше "К", а "К" меньше "С". Если текущие символы в сравниваемых строках совпадают, то сравниваются символы в следующих позициях.

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

Определение: Бинарное дерево называют сбалансированным (balanced), если высота левого поддерева каждого узла отличается от высоты правого поддерева не более чем на 1.

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

Определение: В-деревом порядка n называется сильно ветвящееся дерево степени 2n+1, обладающее следующими свойствами:

1. Каждый узел, за исключением корня, содержит не менее n и не более 2n ключей.

2. Корень содержит не менее одного и не более 2n ключей.

4. Каждый нелистовой узел содержит два списка: упорядоченный по возрастанию значений список ключей и соответсвующий ему список указателей (для листовых узлов список указателей отсутствует).

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

* при добавлении и изменении ключей все изменения ограничиваются, как правило, одним узлом.

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

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

R-дерево (R-Tree) это индексная структура для доступа к пространственным данным, предложенная А.Гуттманом (Калифорнийский университет, Беркли). R-дерево допускает произвольное выполнение операций добавления, удаления и поиска данных без периодической переиндексации.

Для представления данных используются записи, каждая из которых имеет уникальный идентификатор (tuple-identifier). В каждом концевом узле (листе) дерева содержится запись вида (I,tuple-identifier), где I - n-мерный параллелепипед, содержащий указатели на пространственные данные (его также называют minimal bounding rectangle, MBR), а каждый элемент в tuple-identifier содержит верхнюю и нижнюю границу параллелепипеда в соответствующем измерении.

Неконцевые узлы содержат записи вида (I, childnode-pointer), где I минимальный ограничивающий параллелепипед для MBR всех узлов, производных по отношению к данному. Childnode-pointer - это указатель на производные узлы.

Пусть M и m * R-Tree является сильно сбалансированным деревом, т.е. все листья находятся на одном уровне.

* Корневой узел имеет, как минимум, двух потомков.

* Для каждого элемента (I, childnode-pointer) в неконцевом узле I является наименьшим возможным параллелепипедом, т.е. содержит все параллелепипеды производных узлов.

* Каждый концевой узел (лист) содержит от m до M индексных записей.

* Для каждой индексной записи (I, tuple-identifier) в концевом узле I является параллелепипедом, который содержит n-мерный объект данных, на который указывает tuple-identifier

1.2.2.Хеширование.

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

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

Н.Вирт. Алгоритмы и структуры данных.-М.:"Мир",1989.

М.Сибуя, Т.Ямамото. Алгоритмы обработки данных.-М.:"Мир",1986

2.1.Представление данных с помощью модели "сущность-связь".

2.1.1.Назначение модели.

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

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

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

Модель "сущность-связь" была предложена в 1976 г. Питером Пин-Шэн Ченом, русский перевод его статьи 'Модель "сущность-связь" - шаг к единому представлению данных' опубликован в журнале "СУБД" N 3 за 1995 г.

2.1.2.Элементы модели.

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

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

Набор сущностей (entity set) - множество сущностей одного типа (обладающих одинаковыми свойствами). Примеры: все люди, предприятия, праздники и т.д. Наборы сущностей не обязательно должны быть непересекающимися. Например, сущность, принадлежащая к набору МУЖЧИНЫ, также принадлежит набору ЛЮДИ.

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

Пример: рассмотрим множество работников некого предприятия. Каждого из них можно описать с помощью характеристик табельный номер, имя, возраст. Поэтому, сущность СОТРУДНИК имеет атрибуты ТАБЕЛЬНЫЙ_НОМЕР, ИМЯ, ВОЗРАСТ. Используя нотацию языка Pascal этот факт можно представить как:

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

Например отделы,на которые подразделяется предприятие, и в которых работают сотрудники, можно описать как ОТДЕЛ(НОМЕР_ОТДЕЛА, НАИМЕНОВАНИЕ).

Множество значений (область определения) атрибута называется доменом. Например, для атрибута ВОЗРАСТ домен (назовем его ЧИСЛО_ЛЕТ) задается интервалом целых чисел больших нуля, поскольку людей с отрицательным возрастом не бывает.

В упомянутой статье П.Чена атрибут определяется как функция, отображающая набор сущностей в набор значений или в декартово произведение наборов значений. Так атрибут ВОЗРАСТ производит отображение в набор значений (домен) ЧИСЛО_ЛЕТ. Атрибут ИМЯ производит отображение в декартово произведение наборов значений ИМЯ, ФАМИЛИЯ и ОТЧЕСТВО.

Отсюда определяется ключ сущности - группа атрибутов, такая, что отображение набора сущностей в соответствующую группу наборов значений является взаимнооднозначным отображением. Другими словами: ключ сущности - это один или более атрибутов уникально определяющих данную сущность. В нашем примере ключем сущности СОТРУДНИК является атрибут ТАБЕЛЬНЫЙ_НОМЕР (конечно, только в том случае, если все табельные номера на предприятии уникальны).

Связь (relationship) - это ассоциация, установленная между несколькими сущностями. Примеры:

* поскольку каждый сотрудник работает в каком-либо отделе, между сущностями СОТРУДНИК и ОТДЕЛ существует связь "работает в" или ОТДЕЛ-РАБОТНИК;

* так как один из работников отдела является его руководителем, то между сущностями СОТРУДНИК и ОТДЕЛ имеется связь "руководит" или ОТДЕЛ-РУКОВОДИТЕЛЬ;

* могут существовать и связи между сущностями одного типа, например связь РОДИТЕЛЬ - ПОТОМОК между двумя сущностями ЧЕЛОВЕК;

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

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

Связь также может иметь атрибуты. Например, для связи ОТДЕЛ-РАБОТНИК можно задать атрибут СТАЖ_РАБОТЫ_В_ОТДЕЛЕ.

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

Набор связей (relationship set) - это отношение между n (причем n не меньше 2) сущностями, каждая из которых относится к некоторому набору сущностей.

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

В случае n=2, т.е. когда связь объединяет две сущности, она называется бинарной. Доказано, что n-арный набор связей (n>2) всегда можно заменить множеством бинарных, однако первые лучше отображают семантику предметной области.

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

* один к одному (обозначается 1 : 1 ). Это означает, что в такой связи сущности с одной ролью всегда соответствует не более одной сущности с другой ролью. В рассмотренном нами примере это связь "руководит", поскольку в каждом отделе может быть только один начальник, а сотрудник может руководить только в одном отделе. Данный факт представлен на следующем рисунке, где прямоугольники обозначают сущности, а ромб - связь. Так как степень связи для каждой сущности равна 1, то они соединяются одной линией.

Другой важной характеристикой связи помимо ее степени является класс принадлежности входящих в нее сущностей или кардинальность связи. Так как в каждом отделе обязательно должен быть руководитель, то каждой сущности "ОТДЕЛ" непременно должна соответствовать сущность "СОТРУДНИК". Однако, не каждый сотрудник является руководителем отдела, следовательно в данной связи не каждая сущность "СОТРУДНИК" имеет ассоциированную с ней сущность "ОТДЕЛ".

Таким образом, говорят, что сущность "СОТРУДНИК" имеет обязательный класс принадлежности (этот факт обозначается также указанием интервала числа возможных вхождений сущности в связь, в данном случае это 1,1), а сущность "ОТДЕЛ" имеет необязательный класс принадлежности (0,1). Теперь данную связь мы можем описать как 0,1:1,1. В дальнейшем кардинальность бинарных связей степени 1 будем обозначать следующим образом:

* один ко многим ( 1 : n ). В данном случае сущности с одной ролью может соответствовать любое число сущностей с другой ролью. Такова связь ОТДЕЛ-СОТРУДНИК. В каждом отделе может работать произвольное число сотрудников, но сотрудник может работать только в одном отделе. Графически степень связи n отображается "древообразной" линией, так это сделано на следующем рисунке.

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

Здесь также необходимо учитывать класс принадлежности сущностей. Каждый сотрудник должен работать в каком-либо отделе, но не каждый отдел (например, вновь сформированный) должен включать хотя бы одного сотрудника. Поэтому сущность "ОТДЕЛ" имеет обязательный, а сущность "СОТРУДНИК" необязательный классы принадлежности. Кардинальность бинарных связей степени n будем обозначать так:

* много к одному (n : 1 ). Эта связь аналогична отображению 1 : n. Предположим, что рассматриваемое нами предприятие строит свою деятельность на основании контрактов, заключаемых с заказчиками. Этот факт отображается в модели "сущность-связь" с помощью связи КОНТРАКТ-ЗАКАЗЧИК, объединяющей сущности КОНТРАКТ(НОМЕР, СРОК_ИСПОЛНЕНИЯ, СУММА) и ЗАКАЗЧИК(НАИМЕНОВАНИЕ, АДРЕС). Так как с одним заказчиком может быть заключено более одного контракта, то связь КОНТРАКТ-ЗАКАЗЧИК между этими сущностями будет иметь степень n : 1.

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

* многие ко многим ( n : n ). В этом случае каждая из ассоциированных сущностей может быть представлена любым количеством экземпляров. Пусть на рассматриваемом нами предприятии для выполнения каждого контракта создается рабочая группа, в которую входят сотрудники разных отделов. Поскольку каждый сотрудник может входить в несколько (в том числе и ни в одну) рабочих групп, а каждая группа должна включать не менее одного сотрудника, то связь между сущностями СОТРУДНИК и РАБОЧАЯ_ГРУППА имеет степень n : n.

Если существование сущности x зависит от существования сущности y, то x называется зависимой сущностью (иногда сущность x называют "слабой", а "сущность" y - сильной). В качестве примера рассмотрим связь между ранее описанными сущностями РАБОЧАЯ_ГРУППА и КОНТРАКТ. Рабочая группа создается только после того, как будет подписан контракт с заказчиком, и прекращает свое существование по выполнению контракта. Таким образом, сущность РАБОЧАЯ_ГРУППА является зависимой от сущности КОНТРАКТ. Зависимую сущность будем обозначать двойным прямоугольником, а ее связь с сильной сущностью линией со стрелкой:

Заметим, что кардинальность связи для сильной сущности всегда будет (1,1). Класс принадлежности и степень связи для зависимой сущности могут быть любыми. Предположим, например, что рассматриваемое нами предприятие пользуется несколькими банковскими кредитами, которые представляются набором сущностей КРЕДИТ(НОМЕР_ДОГОВОРА,СУММА, СРОК_ПОГАШЕНИЯ, БАНК). По каждому кредиту должны осуществляться выплаты процентов и платежи в счет его погашения. Этот факт представляется набором сущностей ПЛАТЕЖ(ДАТА, СУММА) и набором связей "осуществляется по". В том случае, когда получение запланированного кредита отменяется, информация о нем должна быть удалена из базы даных. Соответственно, должны быть удалены и все сведения о плановых платежах по этому кредиту. Таким образом, сущность ПЛАТЕЖ зависит от сущности КРЕДИТ.

2.2.Диаграмма "сущность-связь".

Очень важным свойством модели "сущность-связь" является то, что она может быть представлена в виде графической схемы. Это значительно облегчает анализ предметной области. Существует несколько вариантов обозначения элементов диаграммы "сущность-связь", каждый из которых имеет свои положительные черты. Краткий обзор некоторых из этих нотаций будет сделан в параграфе 2.4. Здесь мы будем использовать некий гибрид нотаций Чена (обозначение сущностей, связей и атрибутов) и Мартина (обозначение степеней и кардинальностей связей). В таблице 2.1 приводится список используемых здесь обозначений.

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

В процессе построения диаграммы можно выделить несколько очевидных этапов:

1. Идентификация представляющих интерес сущностей и связей.

2. Идентификация семантической информации в наборах связей (например, является ли некоторый набор связей отображением 1:n).

4. Определение атрибутов и наборов их значений (доменов).

5. Организация данных в виде отношений "сущность-связь".

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

Выделим интересующие нас сущности и связи:

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

и и набор связей РАБОТАЕТ_В с атрибутом ставка между ними. Атрибут ставка может принимать значения из интервала ]0,1] (больше нуля, но меньше или равен единице), он определяет какую часть должностного оклада получает данный сотрудник.

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

o Тренарная связь, показанная здесь, безусловно несет более полную информацию о предметной области. Действительно, она однозначно отображает тот факт, что оклад сотрудника зависит от его должности, отдела, где он работает, и ставки. Однако, в этом случае возникают некоторые проблемы с определением степени связи. Хотя, как было сказано, каждый работник может занимать несколько должностей, а в штате каждого отдела существуют вакансии с различными должностями, тем не менее класс принадлежности сущности ДОЛЖНОСТЬ на приведенном рисунке установлен в (1,1). Это объясняется тем, что ДОЛЖНОСТЬ ассоциируется фактически не с сущностями СОТРУДНИК и ОТДЕЛ, а со связью между ними. Обозначать этот факт предлагается так, как это показано на следующей диаграмме:

Здесь сущности СОТРУДНИК, ОТДЕЛ и связь РАБОТАЕТ_В аггрегируются в некую новую абстрактную сущность, которая ассоциируется с сущностью ДОЛЖНОСТЬ с помощью связи степени n:1. (Это обозначение заимствовано из книги Silberschatz, Korth and Sudarshan Database System Concepts, 1997).

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

В этом случае для адекватного описания семантики предметной области необходимо ввести еще одну сущность ШТАТНАЯ_ЕДИНИЦА, которая фактически заменяет собой связь РАБОТАЕТ_В в абстрактной сущности и поэтому имеет атрибут ставка.

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

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

o КОНТРАКТ(НОМЕР,СРОК_НАЧАЛА,СРОК_ОКОНЧАНИЯ,СУММА)

Атрибут "процент_вознаграждения" отражает ту долю стоимости контракта, которая предназначена для оплаты труда членов соответствующей рабочей группы. Смысл остальных атрибутов понятен без дополнительных пояснений. Связи между перечисленными сущностями также описаны в предыдущем параграфе. Как правило, один из членов рабочей группы является руководителем по отношению к другим сотрудникам, входящим в ее состав. Для отражения этого факта мы должны ввести связь "руководит" с кардинальностью 1,1:0,n между сущностями СОТРУДНИК и РАБОЧАЯ_ГРУППА (сотрудник может руководить в произвольном числе рабочих групп, но каждая рабочая группа имеет одного и только одного руководителя).

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

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

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

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

1. ограничения на допустимые значения в наборе значений (домене). Домен можно трактовать как область определения атрибута, которая может быть задана либо непрерывным или дискретным интервалом, либо фиксированным списком значений.

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

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

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

2.4.1.Нотация Чена.

родительская сущность в иерархической связи

внешний ключ (понятие внешнего ключа вводится в реляционной модели данных)

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

Связь соединяется с ассоциируемыми сущностями линиями. Возле каждой сущности на линии, соединяющей ее со связью, цифрами указывается класс принадлежности. Пример:

2.4.2.Нотация Мартина

родительская сущность в иерархической связи

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

Имя связи указывается на линии ее обозначающей. Пример:

2.4.3.Нотация IDEF1X.

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

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

Также может существовать отношение неполной категоризации (сущности-категории составляют неполное множество потомков общей сущности):

2.4.4.Нотация Баркера.

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

Для обозначения отношения категоризации вводится элемент "дуга":

3.1.Иерархическая модель данных.

3.1.1.Структура данных.

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

* Атрибут (элемент данных) - наименьшая единица структуры данных. Обычно каждому элементу при описании базы данных присваивается уникальное имя. По этому имени к нему обращаются при обработке. Элемент данных также часто называют полем.

* Запись - именованная совокупность атрибутов. Использование записей позволяет за одно обращение к базе получить некоторую логически связанную совокупность данных. Именно записи изменяются, добавляются и удаляются. Тип записи определяется составом ее атрибутов. Экземпляр записи - конкретная запись с конкретным значением элементов

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

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

При графическом изображении групповые отношения изображают дугами ориентированного графа, а типы записей - вершинами (диаграмма Бахмана).

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

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

Поэтому, для информационной системы управления персоналом необходимо создать групповое отношение, состоящее из родительской записи ОТДЕЛ (НАИМЕНОВАНИЕ_ОТДЕЛА, ЧИСЛО_РАБОТНИКОВ) и дочерней записи СОТРУДНИК (ФАМИЛИЯ, ДОЛЖНОСТЬ, ОКЛАД). Это отношение показано на рис. (а) (Для простоты полагается, что имеются только две дочерние записи).

Для автоматизации учета контрактов с заказчиками необходимо создание еще одной иерархической структуры : заказчик - контракты с ним - сотрудники, задействованные в работе над контрактом. Это дерево будет включать записи ЗАКАЗЧИК(НАИМЕНОВАНИЕ_ЗАКАЗЧИКА, АДРЕС), КОНТРАКТ(НОМЕР, ДАТА,СУММА), ИСПОЛНИТЕЛЬ (ФАМИЛИЯ, ДОЛЖНОСТЬ, НАИМЕНОВАНИЕ_ОТДЕЛА) (рис. (b)).

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

* Частично дублируется информация между записями СОТРУДНИК и ИСПОЛНИТЕЛЬ (такие записи называют парными), причем в иерархической модели данных не предусмотрена поддержка соответствия между парными записями.

* Иерархическая модель реализует отношение между исходной и дочерней записью по схеме 1:N, то есть одной родительской записи может соответствовать любое число дочерних. Допустим теперь, что исполнитель может принимать участие более чем в одном контракте (т.е. возникает связь типа M:N). В этом случае в базу данных необходимо ввести еще одно групповое отношение, в котором ИСПОЛНИТЕЛЬ будет являться исходной записью, а КОНТРАКТ - дочерней (рис. (c)). Таким образом, мы опять вынуждены дублировать информацию.

3.1.2.Операции над данными, определенные в иерархической модели:

* ДОБАВИТЬ в базу данных новую запись. Для корневой записи обязательно формирование значения ключа.

* ИЗМЕНИТЬ значение данных предварительно извлеченной записи. Ключевые данные не должны подвергаться изменениям.

* УДАЛИТЬ некоторую запись и все подчиненные ей записи.

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

o извлечь следующую запись (следующая запись извлекается в порядке левостороннего обхода дерева)

В операции ИЗВЛЕЧЬ допускается задание условий выборки (например, извлечь сотрудников с окладом более 1 тысячи руб.)

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

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

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

Бойко В.В., Савинков В.М. Проектирование баз данных информационных систем. -М.:"Финансы и статистика",1989.

3.2.Сетевая модель данных

3.2.1.Структура данных.

На разработку этого стандарта большое влияние оказал американский ученый Ч.Бахман. Основные принципы сетевой модели данных были разработны в середине 60-х годов, эталонный вариант сетевой модели данных описан в отчетах рабочей группы по языкам баз данных (COnference on DAta SYstem Languages) CODASYL (1971 г.).

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

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

Иерархическая структура из п.3.1. преобразовывается в сетевую следующим образом (см. рис. 3.2):

* древья (a) и (b), показанные на рис. 3.1, заменяются одной сетевой структурой, в которой запись СОТРУДНИК входит в два групповых отношения;

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

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

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

o автоматический - невозможно занести в БД запись без того, чтобы она была сразу же закреплена за неким владельцем;

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

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

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

2. Обязательное. Допускается переключение подчиненной записи на другого владельца, но невозможно ее существование без владельца. Для удаления записи-владельца необходимо, чтобы она не имела подчиненных записей с обязательным членством. Таким отношением связаны записи "СОТРУДНИК" и "ОТДЕЛ". Если отдел расформировывается, все его сорудники должны быть либо переведены в другие отделы, либо уволены.

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

3.2.2.Операции над данными.

* ДОБАВИТЬ - внести запись в БД и, в зависимости от режима включения, либо включить ее в групповое отношение, где она объявлена подчиненной, либо не включать ни в какое групповое отношение.

* ВКЛЮЧИТЬ В ГРУППОВОЕ ОТНОШЕНИЕ - связать существующую подчиненную запись с записью-владельцем.

* ПЕРЕКЛЮЧИТЬ - связать существующую подчиненную запись с другой записью-владельцем в том же групповом отношении.

* ОБНОВИТЬ - изменить значение элементов предварительно извлеченной записи.

* ИЗВЛЕЧЬ - извлечь записи последовательно по значению ключа, а также используя групповые отношения - от владельца можно перейти к записям - членам, а от подчиненной записи к владельцу набора.

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

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

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

Бойко В.В., Савинков В.М. Проектирование баз данных информационных систем. -М: "Финансы и статистика", 1989.

4.1.Реляционная модель данных

Реляционная модель предложена сотрудником компании IBM Е.Ф.Коддом в 1970 г. (русский перевод статьи, в которой она впервые описана опубликован в журнале "СУБД" N 1 за 1995 г.). В настоящее время эта модель является фактическим стандартом, на который ориентируются практически все современные коммерческие СУБД.

4.1.1.Структура данных.

В реляционной модели достигается гораздо более высокий уровень абстракции данных, чем в иерархической или сетевой. В упомянутой статье Е.Ф.Кодда утверждается, что "реляционная модель предоставляет средства описания данных на основе только их естественной структуры, т.е. без потребности введения какой-либо дополнительной структуры для целей машинного представления". Другими словами, представление данных не зависит от способа их физической организации. Это обеспечивается за счет использования математической теории отношений (само название "реляционная" происходит от английского relation - "отношение").

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

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

Пример: если даны два множества A (a1,a2,a3) и B (b1,b2), их декартово произведение будет иметь вид С=A*B (a1*b1, a2*b1, a3*b1, a1*b2, a2*b2, a3*b2)

* Отношение: Отношением R, определенным на множествах называется подмножество декартова произведения. При этом:

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

o число n определяет степень отношения ( n=1 - унарное, n=2 - бинарное, ..., n-арное)

o количество кортежей называется мощностью отношения

Пример: на множестве С из предыдущего примера могут быть определены отношения R1 (a1*b1, a3*b2) или R2 (a1*b1, a2*b1, a1*b2)

Отношения удобно представлять в виде таблиц. На рис. 4.1 представлена таблица (отношение степени 5), содержащая некоторые сведения о работниках гипотетического предприятия. Строки таблицы соответствуют кортежам. Каждая строка фактически представляет собой описание одного объекта реального мира (в данном случае работника), характеристики которого содержатся в столбцах. Можно провести аналогию между элементами реляционной модели данных и элементами модели "сущность-связь". Реляционные отношения соответствуют наборам сущностей, а кортежи - сущностям. Поэтому, также как и в модели "сущность-связь" столбцы в таблице, представляющей реляционное отношение, называют атрибутами.

Рис.4.1 Основные компоненты реляционного отношения.

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

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

Именнованное множество пар "имя атрибута - имя домена" называется схемой отношения. Мощность этого множества - называют степенью или "арностью" отношения. Набор именованных схем отношений представляет из себя схему базы данных.

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

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

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

Рис.4.2. База данных о подразделениях и сотрудниках предприятия.

Например, связь между отношениями ОТДЕЛ и СОТРУДНИК создается путем копирования первичного ключа "Номер_отдела" из первого отношения во второе. Таким образом:

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

1. из таблицы ОТДЕЛ установить значение атрибута "Номер_отдела", соответствующее данному "Наименованию_отдела"

2. выбрать из таблицы СОТРУДНИК все записи, значение атрибута "Номер_отдела" которых равно полученному на предыдушем шаге.

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

1. определяем "Номер_отдела" из таблицы СОТРУДНИК

2. по полученному значению находим запись в таблице ОТДЕЛ.

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

4.1.2.Свойства отношений.

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

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

4. Атомарность значений атрибутов, т.е. среди значений домена не могут содержаться множества значений (отношения).

Более подробно о фундаментальных свойствах отношений можно прочитать в "Введении в СУБД" С.Д.Кузнецова. 4.2.Теория нормальных форм.

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

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

Функциональная зависимость обозначается X -> Y. Отметим, что X и Y могут представлять собой не только единичные атрибуты, но и группы, составленные из нескольких атрибутов одного отношения.

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

Некоторые функциональные зависимости могут быть нежелательны.

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

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

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

* не должны появляться ранее отсутствовавшие кортежи;

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

4.2.2. 1NF - первая нормальная форма.

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

Простой атрибут - атрибут, значения которого атомарны (неделимы).

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

отношение находится в 1NF если значения всех его атрибутов атомарны.

Рассмотрим пример, заимствованный из уже упоминавшейся статьи Е.Ф.Кодда:

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

СЛУЖАЩИЙ(НОМЕР_СЛУЖАЩЕГО, ИМЯ, ДАТА_РОЖДЕНИЯ, ИСТОРИЯ_РАБОТЫ, ДЕТИ).

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

* ИСТОРИЯ_РАБОТЫ (ДАТА_ПРИЕМА, НАЗВАНИЕ, ИСТОРИЯ_ЗАРПЛАТЫ),

* ИСТОРИЯ_ЗАРПЛАТЫ (ДАТА_НАЗНАЧЕНИЯ, ЗАРПЛАТА),

Для приведения исходного отношения СЛУЖАЩИЙ к первой нормальной форме необходимо декомпозировать его на четыре отношения, так как это показано на следующем рисунке:

Рис.4.4. Нормализованное множество отношений.

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

Алгоритм нормализации описан Е.Ф.Коддом следующим образом:

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

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

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

4.2.3. 2NF - вторая нормальная форма.

Очень часто первичный ключ отношения включает несколько атрибутов (в таком случае его называют составным) - см., например, отношение ДЕТИ, показанное на рис. 4.4. При этом вводится понятие полной функциональной зависимости.

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

Пусть имеется отношение ПОСТАВКИ (N_ПОСТАВЩИКА, ТОВАР, ЦЕНА). Поставщик может поставлять различные товары, а один и тот же товар может поставляться разными поставщиками. Тогда ключ отношения - "N_поставщика + товар". Пусть все поставщики поставляют товар по одной и той же цене. Тогда имеем следующие функциональные зависимости:

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

Отношение находится во 2НФ, если оно находится в 1НФ и каждый неключевой атрибут функционально полно зависит от ключа.

4.2.4. 3NF - третья нормальная форма.

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

Пусть X, Y, Z - три атрибута некоторого отношения. При этом X --> Y и Y --> Z, но обратное соответствие отсутствует, т.е. Z -/-> Y и Y -/-> X. Тогда Z транзитивно зависит от X. Пусть имеется отношение ХРАНЕНИЕ (ФИРМА, СКЛАД, ОБЪЕМ), которое содержит информацию о фирмах, получающих товары со складов, и объемах этих складов. Ключевой атрибут - "фирма". Если каждая фирма может получать товар только с одного склада, то в данном отношении имеются следующие функциональные зависимости:

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

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

Для устранения этих аномалий необходимо декомпозировать исходное отношение на два:

Отношение находится в 3НФ, если оно находится во 2НФ и каждый неключевой атрибут нетранзитивно зависит от первичного ключа.

4.2.5. BCNF - нормальная форма Бойса-Кодда.

Эта нормальная форма вводит дополнительное ограничение по сравнению с 3НФ. Определение нормальной формы Бойса-Кодда:

Отношение находится в BCNF, если оно находится во 3НФ и в ней отсутствуют зависимости атрибутов первичного ключа от неключевых атрибутов.

Ситуация, когда отношение будет находится в 3NF, но не в BCNF, возникает при условии, что отношение имеет два (или более) возможных ключа, которые являются составными и имеют общий атрибут. Заметим, что на практике такая ситуация встречается достаточно редко, для всех прочих отношений 3NF и BCNF эквивалентны.

4.2.6. Многозначные зависимости и четвертая нормальная форма (4NF).

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

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

В качестве примера рассмотрим отношение ПРЕПОДАВАТЕЛЬ (ИМЯ, КУРС, УЧЕБНОЕ_ПОСОБИЕ), хранящее сведения о курсах, читаемых преодавателем, и написанных им учебниках. Пусть профессор N читает курсы "Теория упругости" и "Теория колебаний" и имеет соответствующие учебные пособия, а профессор K читает курс "Теория удара" и является автором учебников "Теория удара" и "Теоретическая механика". Тогда наше отношение будет иметь вид:

| K | Теория упругости | Теоретическая механика |

Это отношение имеет значительную избыточность и его использование приводит к возникновению аномалии обновления. Например, добавление информации о том, что профессор K будет также читать лекции по курсу "Теория упругости" приводит к необходимости добавить два кортежа (по одному для каждого написанного им учебника) вместо одного. Тем не менее, отношение ПРЕПОДАВАТЕЛЬ находится в NFBC (ключевой атрибут - ИМЯ).

Заметим, что указанные аномалии исчезают при замене отношения ПРЕПОДАВАТЕЛЬ его проекциями:

| K | Теория удара | | K |Теоретическая механика |

Аномалия обновления возникает в данном случае потому, что в отношении ПРЕПОДАВАТЕЛЬ имеются:

1. зависимость множества значений атрибута КУРС от множества значений атрибута ИМЯ

2. зависимость множества значений атрибута УЧЕБНОЕ_ПОСОБИЕ от множества значений атрибута ИМЯ.

Такие зависимости и называются многозначными и обозначаются как

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

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

Отношение находится в 4NF если оно находится в BCNF и в нем отстутсвуют многозначные зависимости, не являющиеся функциональными зависимостями.

4.2.7. Зависимости по соединению и пятая нормальная форма (5NF).

До сих пор мы предполагали, что единственной операцией, необходимой для устранения избыточности в отношении, была декомпозиция его на две проекции. Однако, существуют отношения, для которых нельзя выполнить декомпозицию без потерь на две проекции, но которые можно подвергнуть декомпозиции без потерь на три (или более) проекций. Этот факт получил название зависимости по соединению, а такие отношения называют 3-декомпозируемые отношения (ясно, что любое отношение можно назвать "n-декомпозируемым", где n >= 2).

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

Отношение находится в 5НФ тогда и только тогда, когда любая зависимость по соединению в нем определяется только его возможными ключами.

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

Следующая глава: 4.3.Ограничения целостности. 4.3.Ограничения целостности

Целостность данных - это механизм поддержания соответствия базы данных предметной области. В реляционной модели данных определены два базовых требования обеспечения целостности:

4.3.1.Целостность сущностей.

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

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

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

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

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

4.3.2.Целостность ссылок

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

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

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

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

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

Пусть, например, даны отношения ОТДЕЛ (N_ОТДЕЛА, ИМЯ_ОТДЕЛА) и СОТРУДНИК (N_СОТРУДНИКА, N_ОТДЕЛА, ИМЯ_СОТРУДНИКА), в которых хранятся сведения о работниках предприятия и подразделениях, где они работают. Отношение ОТДЕЛ в данной паре является родительским, поэтому его первичный ключ "N_отдела" присутствует в дочернем отношении СОТРУДНИК. Требование целостности по ссылкам означает здесь, что в таблице СОТРУДНИК не может присутствовать кортеж со значением атрибута "N_отдела", которое не встречается в таблице ОТДЕЛ. Если такое значение в отношении ОТДЕЛ отсутствует, значение внешнего ключа в отношении СОТРУДНИК считается неопределенным.

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

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

4.4.Операции над данными (реляционная алгебра).

4.4.0.Система управления базами данных LEAP

Для практического изучения команд реляционной алгебры здесь используется СУБД LEAP, разработанная Ричардом Лейтоном. Для того, чтобы закрепить свои знания:

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

2. Здесь находится более подробное описание возможностей СУБД LEAP.

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

4. Здесь лежит список заданий, которые предлагается выполнить как средствами реляционной алгебры, так и средствами языка SQL.

4.4.1.Операции обработки кортежей.

Эти операции связаны с изменением состава кортежей в каком-либо отношении.

* ДОБАВИТЬ - необходимо задать имя отношения и ключ кортежа.

* УДАЛИТЬ - необходимо указать имя отношения, а также идентифицировать кортеж или группу кортежей, подлежащих удалению.

* ИЗМЕНИТЬ - выполняется для названного отношения и может корректировать как один, так и несколько кортежей.

4.4.2.Операции обработки отношений.

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

В рассмотренных ниже примерах (которые заимствованы из книги Э.Озкарахан "Машины баз данных и управление базами данных" -М: "Мир", 1989) используются следующие отношения:

В реляционной алгебре определены следующие операций обработки отношений:

* ПРОЕКЦИЯ (ВЕРТИКАЛЬНОЕ ПОДМНОЖЕСТВО). Операция проекции представляет из себя выборку из каждого кортежа отношения значений атрибутов, входящих в список A, и удаление из полученного отношения повторяющихся строк.

* ВЫБОРКА (ОГРАНИЧЕНИЕ, ГОРИЗОНТАЛЬНОЕ ПОДМНОЖЕСТВО). На входе используется одно отношение, результат - новое отношение, построенное по той же схеме, содержащее подмножество кортежей исходного отношения, удовлетворяющих условию выборки.

* ОБЪЕДИНЕНИЕ. Отношения-операнды в этом случае должны быть определены по одной схеме. Результирующее отношение содержит все строки операндов за исключением повторяющихся.

* ПЕРЕСЕЧЕНИЕ. На входе операции два отношения, определенные по одной схеме. На выходе - отношение, содержащие кортежи, которые присутствуют в обоих исходных отношениях.

* РАЗНОСТЬ. Операция во многом похожая на ПЕРЕСЕЧЕНИЕ, за исключением того, что в результирующем отношении содержатся кортежи, присутствующие в первом и отсутствующие во втором исходных отношениях.

* ДЕКАРТОВО ПРОИЗВЕДЕНИЕ Входные отношения могут быть определены по разным схемам. Схема результирующего отношения включает все атрибуты исходных. Кроме того:

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

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

* СОЕДИНЕНИЕ Данная операция имеет сходство с ДЕКАРТОВЫМ ПРОИЗВЕДЕНИЕМ. Однако, здесь добавлено условие, согласно которому вместо полного произведения всех строк в результирующее отношение включаются только строки, удовлетворяющие опредленному соотношению между атрибутами соединения (А1,A2) соответствующих отношений.

* ДЕЛЕНИЕ Пусть отношение R , называемое делимым, содержит атрибуты (A1,A2,...,An). Отношение S - делитель содержит подмножество атрибутов A: (A1,A2,...,Ak) (k

4.5.Реляционное исчисление.

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

* основанная на теории множеств реляционная алгебра

* основанное на математической логике реляционное исчисление.

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

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

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

СОТРУДНИКИ (СОТР_НОМЕР, СОТР_ИМЯ, СОТР_ЗАРПЛ, ОТД_НОМЕР) ОТДЕЛЫ(ОТД_НОМЕР, ОТД_КОЛ, ОТД_НАЧ)

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

(1).выполнить соединение отношений СОТРУДНИКИ и ОТДЕЛЫ по условию СОТР_НОМ = ОТДЕЛ_НАЧ.

(2).из полученного отношения произвести выборку по условию ОТД_КОЛ > 10

(3).спроецировать результаты предыдущей операции на атрибуты СОТР_ИМЯ, СОТР_НОМЕР

Заметим, что порядок выполнения шагов может повлиять на эффективность выполнения запроса. Так, время выполнения приведенного выше запроса можно сократить, если поменять местами этапы (1) и (2). В этом случае сначала из отношения СОТРУДНИКИ будет сделана выборка всех кортежей со значением атрибута ОТДЕЛ_КОЛ > 10, а затем выполнено соединение результирующего отношения с отношением ОТДЕЛЫ. Машинное время экономится за счет того, что в операции соединения участвуют меньшие отношения. На языке реляционного исчисления данный запрос может быть записан как:

Выдать СОТР_ИМЯ и СОТР_НОМ для СОТРУДНИКИ таких, что

существует ОТДЕЛ с таким же, что и СОТР_НОМ значением ОТД_НАЧ

Здесь мы указываем лишь характеристики результирующего отношения, но не говорим о способе его формирования. СУБД сама должна решить какие операции и в каком порядке надо выполнить над отношениями СОТРУДНИКИ и ОТДЕЛЫ. Задача оптимизации выполнения запроса в этом случае также ложится на СУБД.

4.6.Язык SQL

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

Язык SQL (эта аббревиатура должна произноситься как "сикуель", однако все чаще говорят "эс-ку-эль") в настоящее время является промышленным стандартом, который в большей или меньшей степени поддерживает любая СУБД, претендующая на звание "реляционной". В то же время SQL подвергается суровой критике как раз за недостаточное соответствие реляционным принципам (см. например, статью Х. Дарвина и К.Дейта Третий манифест, опубликованную в журнале СУБД N 1 за 1996 год).

В начале 70-х годов в компании IBM была разработана экспериментальная СУБД System R на основе языка SEQUEL (Structured English Qeury Language - структурированный английский язык запросов), который можно считать непосредственным предшественником SQL. Целью разработки было создание простого непроцедурного языка, которым мог воспользоваться любой пользователь, даже не имеющий навыков программирования. В 1981 году IBM объявила о своем первом, основанном на SQL программном продукте, SQL/DS. Чуть позже к ней присоединились Oracle и другие производители. Первый стандарт языка SQL был принят Американским национальным институтом стандартизации (ANSI) в 1987 (так называемый SQL level /уровень/ 1) и несколько уточнен в 1989 году (SQL level 2). Дальнейшее развитие языка поставщиками СУБД потребовало принятия в 1992 нового расширенного стандарта (ANSI SQL-92 или просто SQL-2). В настоящее время ведется работа по подготовке третьего стандарта SQL, который должен включать элементы объекто-ориентрованного доступа к данным.

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

* SQL-DDL (Data Definition Language) - язык определения структур и ограничений целостности баз данных. Сюда относятся команды создания и удаления баз данных; создания, изменения и удаления таблиц; управления пользователями и т.д.

* SQL-DML (Data Manipulation Language) - язык манипулирования данными: добавление, изменение, удаление и извлечение данных, управления транзакциями

Здесь не дается строгое описание всех возможностей SQL-92. Во-первых, ни одна СУБД не поддерживает их в полной мере, а во-вторых, производители СУБД часто предлагают собственные расширения SQL, несовместимые друг с другом. Поэтому мы рассматриваем некое подмножество языка, которое дает общее представление о его специфике и возможностях. В то же время, этого подмножества достаточно, чтобы начать самостоятельную работу с любой СУБД. Более формальный (и более полный) обзор стандартов SQL сделан в статье С. Д. Кузнецова "Стандарты языка реляционных баз данных SQL: краткий обзор",журнал СУБД N 2, 1996 г. Ознакомится с русским переводом стандарта SQL можно на сервере Центра информационных технологий, сравнительное описание различных версий языка (для СУБД Sybase SQL Server, Sybase SQL Anywhere, Microsoft SQL Server, Informix, Oracle Server) приводится в книге Дж.Боуман, С.Эмерсон, М.Дарновски "Практическое руководство по SQL", Киев, Диалектика, 1997.

Следует также отметить, что в отличие от "теретической" терминологии, используемой при описании реляционной модели (отношение, атрибут, кортеж), в литературе при описании SQL часто используется терминология "практическая" (соответственно - таблица, столбец, строка). Здесь мы следуем этой традиции.

Все примеры построены применительно к базе данных publications, содержащей сведения о публикациях (как печатных, так и электронных), относящихся к теме данного курса. Структуру этой базы данных можно посмотреть здесь, ее проектирование описано в разделе 5.4, доступ к ней для практических занятий можно получить через Internet посредством СУБД Leap (реляционная алгебра) или СУБД PostgreSQL. (язык SQL).

4.6.1.Типы данных SQL.

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

o CHAR или CHAR(n) -символьные строки фиксированной длины. Длина строки определяется параметром n. CHAR без параметра соответсвует CHAR(1). Для хранения таких данных всегда отводится n байт вне зависимости от реальной длины строки.

o VARCHAR(n) - символьная строка переменной длины. Для хранения данных этого типа отводится число байт, соответствующее реальной длине строки.

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

o INTEGER или INT- целое, для хранения которого отводится, как правило, 4 байта. (Замечание: число байт, отводимое для хранения того или иного числового типа данных зависит от используемой СУБД и аппаратной платформы, здесь приводятся наиболее "типичные" значения) Интервал значений от - 2147483647 до + 2147483648

o SMALLINT - короткое целое (2 байта), интервал значений от - 32767 до +32768

* Вещественные типы данных - описывают числа с дробной частью.

o FLOAT и SMALLFLOAT - числа с плавающей точкой (для хранения отводится обычно 8 и 4 байта соответсвенно).

o DECIMAL(p) - тип данных аналогичный FLOAT с числом значащих цифр p.

o DECIMAL(p,n) - аналогично предыдущему, p - общее количество десятичных цифр, n - количество цифр после десятичной запятой.

* Денежные типы данных - описывают, естественно, денежные величины. Если в ваша система такого типа данных не поддерживает, то используйте DECIMAL(p,n).

o MONEY(p,n) - все аналогично типу DECIMAL(p,n). Вводится только потому, что некоторые СУБД предусматривают для него специальные методы форматирования.

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

o INTERVAL - тип данных для хранения верменного интервала.

o DATETIME - тип данных для хранения моментов времени (год + месяц + день + часы + минуты + секунды + доли секунд).

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

* Последовательные типы данных - используются для представления возрастающих числовых последовательностей.

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

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

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

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

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

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

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

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

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

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

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

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

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

2. Проблемы информационного обеспечения туристского бизнеса в России

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

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

Практически полное отсутствие в Российской Федерации статистики на региональном и местном уровнях затрудняет разработку планов регионального планирования развития туризма. Сильная информационно-аналитическая служба, как в случае Ярославской области, может помочь не только в сборе и анализе необходимой информации, но и в формировании своего регионального информационно-рекламного продукта.

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

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

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

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

3. Существующие туристские интернет-проекты

По уровню представления в сети он-лайновые туристские ресурсы Рунета можно подразделить следующим образом:

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

- специализированные туристические порталы и сайты

3.1 Сайты и порталы общего назначения с туристическими разделами

Наиболее часто туристические разделы встречаются в каталогах ресурсов - больших систематизированных сборниках ссылок.

Наиболее полным собранием туристических сайтов является, раздел «Вокруг света» каталога «Майл.Ру» - list.mail.ru/catalog/10894.html. Здесь собраны ссылки более чем на 4000 страниц, посвященных туризму, путешествиям, странам, курортам, турфирмам, причем они сгруппированы в несколько десятков подкатегорий, что иногда значительно облегчает поиск нужного ресурса.

Однако наиболее посещаемым потенциальными туристами является раздел «Путешествия» рейтинга-классификатора Rambler - counter.rambler.ru/top100/Travel/ . Здесь все страницы, а их около 800, отсортированы в порядке популярности, т.е. чем больше сегодня посмотрело людей ту или иную страничку на сайте, тем она выше в рейтинге, тем ее, соответственно, легче найти.

Заслуживают также упоминания каталоги www.pingwin.ru, www.ru, weblist.ru - в них собрано большое количество ссылок по туризму.

Кроме каталогов туристические разделы встречаются на сайтах развлекательной тематики, на мегапорталах, претендующих на всеохватность тематики, например, на www.gala.net, www.estart.ru, www.emax.ru, www.km.ru. Но информация, представленная в таких разделах, значительно уступает по объему и качеству специализированным туристическим сайтам. Исключение составляет туристический раздел мегапортала «Кирилла и Мефодия», который можно уверенно отнести к специализированным туристическим порталам.

3.2. Специализированные туристические порталы и сайты

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

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

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

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

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

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

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

На многих порталах собраны большие коллекции различных рассказов туристов о своих поездках и впечатлениях. Особенно в этом плане хочется отметить «Архив путешественника» arhive.travel.ru и «Рассказы туристов» www.tours.ru/story. В этих разделах содержатся сотни рассказов о поездках, из которых можно почерпнуть немало полезной для себя информации.

Наиболее известные и популярные туристические порталы на сегодня:

- «100 Дорог» - www.tours.ru - существует с 1996 года, создатель «АримСофт». Средняя посещаемость 100 - 120 тысяч чел./мес.

- TRAVEL.RU - сервер о туризме и путешествиях. Существует с 1997 года, основатель и совладелец - Анастасия Патрышева совместно с Порт.Ру. Средняя посещаемость 90 - 150 тыс./мес.

- Time2Travel - www.km.ru/tourism активно продвигается с 1998 года известным производителем мультимедийных программ - фирмой «Кирилл и Мефодий» . Средняя посещаемость 30 тыс./мес.

- Turizm.ru - сайт администрирует «Бюро интернет - маркетинга». Существует с 1998 года. Средняя посещаемость 30 - 60 тыс./мес.

- Туристический маяк - www.mayakinfo.ru - рекламно-информационный сервер. В сети с 1998 года. Средняя посещаемость 40 - 70 тыс. чел./мес.

- РБК-Туризм - tour.rbc.ru - туристический портал от известного холдинга РосБизнесКонсалтинг. В сети с 2001 года. Средняя посещаемость 80 - 100 тыс. чел./мес.

3.3 Сайты туроператоров и их классификация

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

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

К классическим, добротно сделанным веб-витринам можно отнести сайты таких турфирм, как «Русибер», «Интраст-тур», «Пак-Групп», «Чайка-тур», «Креста-туризм» и др.

Система «Туроператор - турагент» - большая редкость в Рунете.

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

Преимущества таких систем очевидны: практически полная автоматизация всех бизнес-процессов, минимизация влияния негативных последствий «человеческого фактора» (забыл заявку подтвердить, факс не отправил и т.п.), оперативная поставка информации, необходимой агентствам (цены, stop-sale, загрузка отелей и т.п.).

3.4. Сайты туристических агентств

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

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

Туристический электронный магазин - такой вид агентских сайтов только начинает вырисовываться на современном он-лайновом туристическом рынке. В качестве реально работающего электронного магазина можно привести сервер «Сети магазинов горящих путевок».

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

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

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

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

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

Список использованной литературы

1. Информационные технологии в управлении туристским бизнесом. - Вестник СП6ГУ, Серия Экономика. - 1995.- Вып. 3, №19.

2. Туристский бизнес в Интернет. /Инвестиционная политика России в современных условиях: Тезисы докладов и выступлений Всероссийской научной конференции, СП6ГУ.- 1997.

3. Использование сети Интернет в индустрии путешествий. - Вестник СП6ГУ, Серия Экономика. - 1997.- Вып. 4, №26.

4. Проблемы информационного обеспечения регионального планирования развития туризма. /Актуальные проблемы развития туризма на современном этапе: Тезисы докладов и выступлений Второй научно-практической конференции, СП6ГУ. - 1998.

5. Юрий Гриценко. Состояние и перспективы использования Интернета в туристском бизнесе России. // Вокруг света. - 2002. - № 1. - С. 14 - 17.

6. Квартальнов В.А., Романов А.А. Международный туризм: политика развития. - Москва: Советский спорт, 1998.

7. А.П.Дурович, АСКомпанев. Маркетинг в туризме: учебное пособие. Минск: Экономпресс, 1998.

8. 4. Че6отарь Ю.М. Туристический бизнес -Москва: Мир деловой книги ,1997.

Описание предмета: «СУБД»

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

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

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

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

Внимание!

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

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