Базы данных и их сравнительные характеристики

РЕФЕРАТ
по дисциплине «Информатика»
на тему «Базы данных и их сравнительные характеристики»
1. Классификация моделей построения баз данных
Взависимости от архитектуры СУБД делятся на локальные и распределенные СУБД. Всечасти локальной СУБД размещаются на одном компьютере, а распределенной нанескольких. За несколько десятилетий последовательно появлялись системы (СУБД),основанные на трех базовых моделях данных: иерархической, сетевой иреляционной. Основные определения теории баз знаний и баз данных представлены втаблице 1.
Табл.1.Основные определения Термин Определение База данных (БД) Базами данных называют электронные хранилища информации, доступ к которым осуществляется с помощью одного или нескольких компьютеров. Системы управления базами данных (СУБД) это программные средства для создания, наполнения, обновления и удаления баз данных. База знаний Базы знаний это хранилища знаний, представленных в формализованном виде. Система управления базами знаний СУБЗ это программные средства для создания, наполнения, обновления и удаления баз знаний
Виды знаний:
Процедурные
Декларативные
Каузальные
Неточные
Знания, отвечающие на вопрос «Как решать поставленную задачу?»
Знания, не содержащие в явном виде процедуры решения задач.
Знания о причинно-следственных связях между объектами предметной области
Знания отличающиеся неполнотой или противоречивостью.
Парадигмы решения задач
В СУБД
В СУБЗ
Данные + Алгоритм = Программа решения задачи
Знания + Стратегия вывода = Решение проблемы.
Модели знаний
Продукционная
Фреймовая
Семантическая сеть
Знания представленные в формате «ЕСЛИ-ТО»
Знания представленные в виде набора взаимосвязанный фреймов.
Граф, вершины которого соответствуют объектам или понятиям, а дуги определяют отношения между вершинами.
Фрейм
Фрейм прототип
Конкретный фрейм
Структурированное описание объекта предметной области состоящее из наименования объекта (имя фрейма), атрибутов объекта (свойств, характеристик) — слоты фрейма.
Это фрейм у которого значения слотов не определены.
Это фрейм прототип с конкретными значениями. Enterprise JavaBeans. Стандарт для создания средствами языка Java пригодных для многократного использования компонентов, из которых формируются прикладные программы. Компоненты Enterprise JavaBeans облегчают разработку программ, обеспечивающих доступ к хранимой в базе данных информации. Распараллеливание обработки запроса (Intraquery parallelism). Использование нескольких ЦП для обработки одного запроса. Параллельная обработка запросов (interquery parallelism) подразумевает параллельную обработку нескольких запросов (на разных ЦП). Уровень изоляции  (Isolation level). Установочный параметр БД, определяющий, в какой степени одновременно обратившиеся к базе данных пользователи могут оказывать влияние на работу друг друга. Как правило, используются три уровня изоляции: завершение чтения (read committed), характеризуется большим количеством одновременно обслуживаемых пользователей и низким уровнем изоляции каждого из них); в установленном порядке (serializable), небольшое число одновременно обслуживаемых пользователей, высокая степень изоляции и повторяющееся чтение (repeatable read), сочетание двух первых уровней. Технология СОМ COM — Component Object Model — Компонентная модель объектов, предложена корпорацией Микрософт. Технология CORBA CORBA — Common Object Require Broker Architecture — архитектура с брокером требуемых общих объектов, разработана независимой группой OMG. JDBC (Java Database Connectivity). Интерфейс взаимодействия с базами данных на языке Java. Этот стандарт, разработанный фирмой Sun Microsystems, определяет способы доступа Java-приложений к данным БД. ODBC (Open Database Connectivity). Открытый интерфейс взаимодействия с базами данных. Предложенный корпорацией Microsoft стандарт, регулирующий доступ Windows -приложений к базам данных. Стандарт ODBC постепенно заменяется спецификацией OLE DB. OLAP (Online analytical processing). Оперативный анализ данных. Этот метод обработки применяется с целью ускорения обработки запросов и предусматривает предварительный расчет часто запрашиваемых данных (например, сумм или значений счетчика). OLE DB (Object Linking and Embedding Database). OLE для баз данных. Новый стандарт Microsoft, регулирующий доступ приложений к базам данных. Имеет расширения для серверов OLAP и предусматривает применение специальных средств обработки мультимедийных данных. Операция соединения (Join). Процесс, позволяющий объединять данные из двух таблиц посредством сопоставления содержимого двух аналогичных столбцов. SQL (Structured query language). Язык структурированных запросов, язык S0L. Является принятым в отрасли стандартом для выполнения операций вставки, обновления, удаления и выборки данных из реляционных БД. Хранимая процедура (Stored procedure). Программа, которая выполняется внутри базы данных и может предпринимать сложные действия на основе информации, задаваемой пользователем. Поскольку хранимые процедуры выполняются непосредственно на сервере базы данных, обеспечивается более высокое быстродействие, нежели при выполнении тех же операций средствами клиента БД. Транзакция (Transaction). Совокупность операций базы данных, выполнение которых не может быть прервано. Для того чтобы изменения, внесенные в БД в ходе выполнения любой из входящих в транзакцию операций, были зафиксированы в базе данных, все операции должны завершиться успешно. Все базы данных, представленные в нашем обзоре, позволяют использовать транзакции, тогда как БД для настольных систем, например Visual dBase фирмы Inprise или Microsoft Access, не предусматривают применения механизма транзакций. Триггер (Trigger). Программа базы данных, вызываемая всякий раз при вставке, изменении или удалении строки таблицы. Триггеры обеспечивают проверку любых изменений на корректность, прежде чем эти изменения будут приняты 2. Иерархическая модель
Первыеиерархические и сетевые СУБД были созданы в начале 60-х годов. Причинойпослужила необходимость управления миллионами записей (связанных друг с другомиерархическим образом), например при информационной поддержке лунного проектаАполлон. Среди реализуемых на практике СУБД этого типа преобладает система IMS(Information Management System компании IBM) (На данный момент это самаяраспространенная СУБД из всех данного типа). Применяются и другие иерархические системы: TDMS (Time-SharedDate Management System) компании Development Corporation; Mark IV Multi — AccessRetrieval System компании Control Data Corporation; System — 2000 разработкиSAS-Institute.
Отношенияв иерархической модели данных организованы в виде совокупностей деревьев, где дерево- структура данных, в которой тип сегмента потомка связан только с одним типомсегмента предка. Графически: Предок — точка на конце стрелки, а Потомок — точкана острие стрелки. В базах данных определено, что точки — это типы записей, астрелки представляют отношения один — к — одному или один — ко — многим.
Кограничения иерархической модели данных можно отнести:
1. Отсутствуетявное разделение логических и физических характеристик модели;
2. Дляпредставления неиерархических отношений данных требуются дополнительныеманипуляции;
3. Непредвиденныезапросы могут требовать реорганизации базы данных.3. Сетевая модель
Сети — естественный способпредставления отношений между объектами. Они широко применяются в математике,исследованиях операций, химии, физике, социологии и других областях знаний.Сети обычно могут быть представлены математической структурой, котораяназывается направленным графом. Направленный граф имеет простую структуру. Онсостоит из точек или узлов, соединенных стрелками или ребрами. В контекстемоделей данных узлы можно представлять как типы записей данных, а ребрапредставляют отношения один-к -одному или один-ко-многим. Структура графаделает возможными простые представления иерархических отношений (таких, какгенеалогические данные) .
Сетеваямодель данных- это представление данных сетевыми структурами типов записей и связанныхотношениями мощности один-к-одному или один-ко-многим. В конце 60-х конференцияпо языкам систем данных (Conference on Data Systems Languages, CODASYL)поручила подгруппе, названной Database Task Group (DTBG), разработать стандартысистем управления базами данных. На DTBG оказывала сильное влияние архитектура,использованная в одной из самых первых СУБД, Iategrated Data Store (IDS),созданной ранее компанией General Electric.Это привело к тому, что быларекомендована сетевая модель.
ДокументыDatabase Task Group (DTBG) (группа для разработки стандартов систем управлениябазами данных) от 1971 года остается основной формулировкой сетевой модели, нанего ссылаются как на модель CODASYL DTBG. Она послужила основой для разработкисетевых систем управления базами данных нескольких производителей. IDS(Honeywell) и IDMS (Computer Associates) — две наиболее известных коммерческихреализации. В сетевой модели существует две основные структуры данных: типызаписей и наборы:
· Типзаписей.Совокупность логически связанных элементов данных.
· Набор. В модели DTBG отношениеодин-ко-многим между двумя типами записей.
· Простаясеть.Структура данных, в которой все бинарные отношения имеют мощностьодин-ко-многим.
· Сложнаясеть.Структура данных, в которой одно или несколько бинарных отношений имеютмощность многие-ко-многим.
· Типзаписи связи.Формальная запись, созданная для того, чтобы преобразовать сложную сеть вэквивалентную ей простую сеть.
Вмодели DBTG возможны только простые сети, в которых все отношения имеютмощность один-к-одному или один-ко-многим. Сложные сети, включающие одно илинесколько отношений многие-ко-многим, не могут быть напрямую реализованы вмодели DBTG. Следствием возможности создания искусственных формальных записейявляется необходимость дополнительного объема памяти и обработки, однако приэтом модель данных имеет простую сетевую форму и удовлетворяет требованиямDBTG.4. Реляционная модель
В1970-1971 годах Е.Ф. Кодд опубликовал две статьи, в которых ввел реляционнуюмодель данных и реляционные языки обработки данных — реляционную алгебру иреляционное исчисление.
· Реляционнаяалгебра — Процедурныйязык обработки реляционных таблиц.
· Реляционноеисчисление — Непроцедурный язык создания запросов.
Всесуществующие к тому времени подходы к связыванию записей из разных файловиспользовали физические указатели или адреса на диске. В своей работе Коддпродемонстрировал, что такие базы данных существенно ограничивают число типовманипуляций данными. Более того, они очень чувствительны к изменениям вфизическом окружении. Когда в компьютерной системе устанавливался новыйнакопитель или изменялись адреса хранения данных, требовалось дополнительноепреобразование файлов. Если к формату записи в файле добавлялись новые поля, тофизические адреса всех записей файла изменялись. То есть такие базы данных непозволяли манипулировать данными так, как это позволяла бы логическаяструктура. Все эти проблемы преодолела реляционная модель, основанная налогических отношениях данных.
Существуетдва подхода к проектированию реляционной базы данных.
· Первыйподходзаключается в том, что на этапе концептуального проектирования создается неконцептуальная модель данных, а непосредственно реляционная схема базы данных,состоящая из определений реляционных таблиц, подвергающихся нормализации.
· Второйподходоснован на механическом преобразовании функциональной модели, созданной ранее,в нормализованную реляционную модель. Этот подход чаще всего используется припроектировании больших, сложных схем баз данных, необходимых для корпоративныхинформационных систем.
Табл.1.Основные определения реляционных СУБД Термин Определение Реляционная модель данных Организует и представляет данные в виде таблиц или реляций. Реляционная база данных (РБД, RDBMS). База данных, построенная на реляционной модели. Реляция (таблица-элементарная информационная единица) Двумерная таблица, содержащая строки и столбцы данных. Степень реляции. Количество атрибутов реляции. При том необходимо помнить, что никакие два атрибута реляции не могут иметь одинаковых имен. Кортежи Строки реляции (таблицы), соответствуют объекта, конкретному событию или явлению. Атрибуты Столбцы таблицы, характеризующие признаки, параметры объекта, события, явления. Область атрибута Набор всех возможных значений, которые могут принимать атрибуты. Если в процессе работы возникает ситуация, что атрибут неприменим или значения одного или нескольких атрибутовстроки пока неизвестны, то строка запишется в базуданных с пустыми значениямиэтих атрибутов (NULL строка). Пустое значение Значение, приписываемое атрибуту в кортеже, если атрибут неприменим или его значение неизвестно Ключ Любой набор атрибутов, однозначно определяющий каждый кортеж реляционной таблицы. Ключ реляции Ключ также можно описать как минимальное множество атрибутов, однозначно определяющих (или функционально определяющих)каждое значение атрибута в кортеже. Составной ключ Ключ содержащий два или более атрибута. Потенциальный ключ В любой данной реляционной таблице может оказаться более одного набора атрибутов. Обычно в качестве первичного ключа выбирают потенциальный ключ, которым проще всего пользоваться при повседневной работе по вводу данных. Первичный ключ. Поле или набор полей, однозначно идентифицирующий запись. Внешний ключ. Набор атрибутов одной таблицы, являющийся ключом другой (или той же самой) таблицы; используется для определения логических связей между таблицами. Атрибуты внешнего ключа не обязательно должны иметь те же имена, что и атрибуты ключа, которым они соответствуют. Рекурсивный внешний ключ. Внешний ключ, ссылающийся на свою собственную реляционную таблицу. Родительская реляция (таблица) Таблица, поля которой входят в другую таблицу. Дочерняя реляция (таблица) Таблица, поля которой используют информацию из полей другой таблицы, являющейся по отношению к данной родительской. Отношение один-к-одному Когда одной записи в родительской таблицы соответствует одна запись в дочерней таблице Отношение один-ко-многим Когда одной записи в родительской таблицы соответствует несколько записей в дочерней таблице Отношение многие-ко-многим Когда многим записям в родительской таблицы соответствуют несколько записей в дочерней таблице Рекурсивное отношение. Отношение, связывающее объектное множество с ним самим. View (Представления) Информационная единица РБД (по структуре аналогичная таблице), записи которой сформированы в результате выполнения запросов к другим таблицам. Ссылочная целлостность Адекватное воспроизведение записей в ссылочных полях таблиц. Триггер Средство обеспечения ссылочной целостности на основе механизма каскадных изменений. Индекс Механизмы быстрого доступа к хранящимся в таблицах данных путем их предварительной сортировки. Транзакция Такое воздействие на СУБД, которое переводит ее из одного целостного состояния в другое. Ограничительные условия, поддерживающие целостность базы данных.
Какследует из определения ссылочной целостности при наличии в ссылочных полях двухтаблиц различного представления данных происходит нарушение ссылочнойцелостности, такое нарушение делает информацию в базе данных недостоверной.Чтобы предотвратить потерю ссылочной целостности, используется механизмкаскадных изменений (который чаще всего реализуется специальными объектами СУБД- триггерами). Данный механизм состоит в следующей последовательности действий:
· приизменении поля связи в записи родительской таблицы следует синхронно изменитьзначения полей связи в соответствующих записях дочерней таблицы;
· приудалении записи в родительской таблицы следует удалить соответствующие записи ив дочерней таблице.Процесс нормализации
Нормализация- процессприведения реляционных таблиц к стандартному виду. В базе данных могутприсутствовать такие проблемы как:
· Избыточностьданных. Повторениеданных в базе данных.
· Аномалияобновления.Противоречивость данных, вызванная их избыточностью и частичным обновлением.
· Аномалияудаления.Непреднамеренная потеря данных, вызванная удалением других данных.
· Аномалияввода.Невозможность ввести данные в таблицу, вызванная отсутствием других данных.
Длярешения этих проблем применяют разбиение таблиц — разделение таблицы нанесколько таблиц. Для того чтобы это сделать пользуются нормальными формами илиправилами структурирования таблиц.
Перваянормальная форма
Реляционнаятаблица находится в первой нормальной форме (1НФ), если значения в таблицеявляются атомарными для каждого атрибута таблицы, т.е. такими значениями,которые не являются множеством значений или повторяющейся группой. Вопределении Кодда реляционной модели уже заложено, что реляционные таблицынаходились в 1НФ,
Втораянормальная форма.
Реляционнаятаблица находится во второй нормальной форме (2НФ), если никакие неключевыеатрибуты не являются функционально зависимыми лишь от части ключа. Такимобразом, 2НФ может оказаться нарушена только в том случае, когда ключсоставной.
Функциональнаязависимость. Значениеатрибута в кортеже однозначно определяет значение другого атрибута в кортеже.
Болееформально можно определить функциональную зависимость следующим образом: если Аи В — атрибуты в таблице В, то запись ФЗ (функциональную зависимость): А — " В обозначает, что если два кортежа в таблице В имеют одно и то жезначение атрибута А, то они имеют одно и то же значение атрибута В. Этоопределение такжеприменимо, если А и В — множества столбцов, а не простоотдельные столбцы.
Атрибутв левой части ФЗ называется детерминантом, так как его значение определяетзначение атрибута в правой части. Ключ таблицы является детерминантом, так какего значение однозначно определяет значение каждого атрибута таблицы.
Процессразбиения на две 2НФ-таблицы состоит из следующих шагов:
1. Создаетсяновая таблица, атрибутами которой будут атрибуты исходной таблицы, входящие впротиворечащую правилу ФЗ. Детерминант ФЗ становится ключом новой таблицы.
2. Атрибут,стоящий в правой части ФЗ, исключается из исходной таблицы.
3. Еслиболее одной ФЗ нарушают 2НФ, то шаги 1 и 2 повторяются для каждой такой ФЗ.
4. Еслиодин и тот же детерминант входит в несколько ФЗ, то все функционально зависящиеот него атрибуты помещаются в качестве неключевых атрибутов в таблицу, ключомкоторой будет детерминант.
Третьянормальная форма
Реляционнаятаблица имеет третью нормальную форму (ЗНФ), если для любой ФЗ: Х — У — Хявляется ключом. Заметим, что любая таблица, удовлетворяющая ЗНФ, такжеудовлетворяет и 2НФ. Однако обратное неверно.
Критерийнормальной формы Бойса-Кодда (НФБК) утверждает, что таблица удовлетворяет ЗНФ, еслив ней нет транзитивных зависимостей. Транзитивная зависимость возникает, еслинеключевой атрибут функционально зависит от одного или более неключевыхатрибутов. То есть этот критерий учитывает следующие два случая:
1. Неключевойатрибут зависит от ключевого атрибута, входящего в составной ключ (критерийнарушения 2НФ).
2. Ключевойатрибут, входящий в составной ключ, зависит от неключевого атрибута.
Такимобразом, если таблица удовлетворяет НФБК, то она также удовлетворяет ЗНФ всмысле транзитивных зависимостей и 2НФ.
Четвертаянормальная форма
Таблицаимеет четвертую нормальную форму (4НФ), если она имеет ЗНФ и не содержитмногозначных зависимостей. Поскольку проблема многозначных зависимостейвозникает в связи с многозначными атрибутами, то мы можем решить проблему,поместив каждый многозначный атрибут в свою собственную таблицу вместе сключом, от которого атрибут зависит.
Пятаянормальная форма.
Пятаянормальная форма (5НФ) была предложена для того, чтобы исключить аномалии,связанные с особым типом ограничительных условий, называемых совместнымизависимостями. Эти зависимости имеют в основном теоретический интерес исомнительную практическую ценность. Следовательно, пятая нормальная форма вдействительности не имеет практического применения.
Нормальнаяформа область/ключ.
Таблицаимеет нормальную форму область/ключ (НФОК), если любое ограничительное условиев таблице является следствием определений областей и ключей. Однако не был данобщий метод приведения таблицы к НФОК.
Вкачестве примера, рассмотрим структуру реляционной базы данных, описывающей«отношения» пациентов и докторов в произвольной клинике (областьприложения примера выбрана из-за того, что в сертификационных тестах Oracleаналогичные примеры встречаются очень часто). Пусть существует некая клиника,основные характеристики которой описываются в таблице CLINICS, в данной клиникеработают доктора, основные характеристики которых описывает таблица DOCTORS.Данные пациентов клиники хранятся в таблице PATIENTS. Взаимосвязи междутаблицами представлены на рис.10. (Для упрощения предполагается, что у доктораможет быть несколько пациентов, которые не являются пациентами других докторов,для реализации реальной картины, когда один пациент может относиться кнескольким разным докторам, между таблицами DOCTORS и PATIENTS необходимовключить дополнительную связывающую таблицу).
/>
Рис.2. Диаграмма, иллюстрирующая отношения таблиц АИС.
№ Наименование столбца Описание Таблица CLINICS 1 CS_NNN Индекс 2 CS_REG_NUMBER Регистрационный номер 3 CS_CITY_NNN Ссылка на справочник городов и регионов 4 CS_NAME Наименование клиники 5 CS_ADDRESS Адрес клиники 6 CS_PHONE_NUMBER Номер телефона 7 CS_TYPE Профиль клиники Таблица DOCTORS 1 DC_NNN Индекс 2 DC_NAME Ф.И.О. доктора 3 DC_CS_NNN Ссылка на таблицу CLINICS 4 DC_DIPLOM_NUMBER Номер диплома 5 DC_SPECIALTY_NNN Ссылка на справочник специальностей 6 DC_SHTAT_NNN Ссылка на штатное расписание 7 DC_CALENDAR_NNN Ссылка на расписание приема Таблица PATIENTS 1 PT_NNN Индекс 2 PT_REG_NUMBER Регистрационный номер 3 PT_NAME Ф.И.О. пациента 4 PT_ADDRESS Адрес пациента 5 PT_POLIS_NUMBER Номер полиса 6 PT_PHONE_NUMBER Номер телефона 7 PT_BIRTHDATE Дата рождения 8 PT_FIRST_VISIT Дата первого визита 9 PT_LAST_VISIT Дата последнего визита 10 PL_PT_NNN Ссылка на таблицу платежей Таблица PAYMENTS PL_NNN Индекс PL_ACCOUNT_NUMBER Номер расчетного счета PL_PAY_NNN Ссылка на таблицу расчетов

Представленнаяструктура, конечно, не обладает функциональной полнотой с точки зренияпроектирования АИС клиники, с ее помощью мы лишь рассмотрим различные типыотношений в реляционных СУБД.
Передтем, как перейти к рассмотрению вопросов стандартизации и целостности данных вРСУБД несколько рекомендаций по выбору наименований таблиц и полей. Внимательновзглянув на описание таблиц можно заметить, что генерация наименований таблиц истолбцов подчиняется некоторой синтаксической конструкции, которая в общем видеможет быть представлена следующим образом:
Длятаблиц:
 
__:__
Например,если бы мы разрабатывали АИС клиники c сокращенным названием CSL, то всетаблицы входящие в данную систему было бы целесообразно называть
 
CSL__.
Длястолбцов:
 
_.
Например,как показано на рис.2. Регистрационный номер пациента храниться в полеPT_REG_NUMBER, таблицы PATIENTS, имеющий псевдоним PT.
Конечно,использование этих не хитрых правил не является обязательным, но позволяетзначительно облегчить читаемость разработанной информационной структуру.Предположите, как было бы все, если бы поля таблиц назывались P111, P112 ит.п., а ведь такие вещи встречаются практически очень часто, например в FoxPro2.6.
Перейдемк рассмотрению вопросов стандартизации и обеспечения ссылочной целостностиреляционных таблиц.
Преобразованиеотношений
Полятаблиц могут находиться между собой в одном из следующих отношений:
один-к-одному,один-ко-многим, многие-ко-многим и рекурсивных, определения которых приведены втабл.1. Рассмотрим преобразование отношений на примере АИС«ДОКТОР-ПАЦИЕНТ» (рис.2).
Отношениеодин-к-одному представляет собой такое отношение, при котором каждой записи втаблице А соответствует единственная запись в таблице В (рис.1). Применениетакого типа отношений встречается крайне редко и предназначено в основном дляфункционального разделения информации на несколько таблиц, т.е. когда не хотят,чтобы таблица БД «распухала» от второстепенной информации. На рис.10представлено, как используя отношение один-к-одному таблица PATIENTS преобразованав две таблицы: PATIENTS_REG и PATIENTS_KART (на рисунке показаны толькоосновные атрибуты таблиц). Также необходимо принимать во внимание, что БДиспользующие такие отношения не могут быть полностью нормализованы.
/>
Рис.1. Отношение один кодному.

Отношениеодин-ко-многим можно без преувеличения назвать основным типом отношенийиспользующемся при проектировании современных БД, так как позволяетпредставлять иерархические структуры данных. Под данным отношение понимаетсятакое отношение, когда одной записи в родительской таблице соответствуют записив дочерней таблице (причем число соответствующих записей выражается рядомнатуральных чисел 0,1,2,:N и т.п.) (рис.2). Отношенияодин-ко-многим могут быть жесткими и нежесткими. Для жестких отношений должновыполнять требование, что каждой записи в родительской таблице должнасоответствовать хотя бы одна запись в дочерней таблице.
/>
Рис.2. Отношение один комногим.
Отношениемногие-ко-многим представляет собой отношение при котором записям родительскойтаблицы соответствуют записи дочерней таблицы, а ряду записей дочерней таблицысоответствуют записи в родительской таблицы (рис.13). Использование такого типаотношений крайне ограничено, не только из-за того, что некоторые БД его вообщене поддерживают на уровне индексов и ссылочной целостности, но и потому, чтопрактически любое отношение многие-ко-многим может быть заменено одним илиболее отношением один-ко-многим (посмотрите на пример на рис.3. и так не когдане делайте).

/>
Рис.3. Отношение многие комногим.
Другимважным типом отношений — является рекурсивное отношение, т.е. такое отношениекоторое описывает связи между записями внутри одной таблицы БД, т.е. оносвязывает объектное множество с ним самим. Пример рекурсивных отношений показанна рис.4., который иллюстрирует, что доктора Петров А.А. и Васин Н.Н. находятсяв зависимости от доктора Сидорова В.Н… В зависимости от функциональногоназначения этого отношения оно может иллюстрировать, например, что они являютсяпациентами доктора Сидорова В.Н., или Сидорова В.Н. является по отношению к нимначальником и т.п. Данный тип отношений позволят реализовать древовиднуюструктуру функциональных отношений, например, структуру организации.
/>
Рис.4. Отношение многие комногим.
Учитываятребования ссылочной целостности и нормализации на основе применениярассмотренных выше типов отношений осуществляется преобразование функциональноймодели бизнес — процессов и реаляционную модель. Итогом этапа являетсядиаграмма «Сущность-связь» (часто называемая CASE диаграмма,ER-диаграама, рис.2).Преобразование функциональной модели в реляционную.
Результатомпервого этапа проектирования АИС является функциональная модель системысодержащая множество объектов (процессов, операций), их атрибутов.
Объектноемножество с атрибутами может быть преобразовано в реляционную таблицу с именемобъектного множества в качестве имени таблицы и атрибутами объектного множествав качестве атрибутов таблицы. Если некоторый набор этих атрибутов может бытьиспользован в качестве ключа таблицы, то он выбирается ключом таблицы. Впротивном случае мы добавляем к таблице атрибут, значения которого будутоднозначно определять объекты-элементы исходного объектного множества, икоторый, таким образом, может служить ключом таблицы.
Преобразованиеотношений
Полятаблиц могут находиться между собой в обном из следующих отношений:один-к-одному, один-ко-многим, многие-ко-многим и рекурсивных, определения которыхпредставлены в табл.1. Прежде чем рассмотреть реализацию и преобразованиеотношений более подробно, обсудим реторический вопрос о правилах именованиятаблиц и столбцов. Как мы уже ранее отмечали, что практически любая АИС имеетмодульную структуру и соответствено, в каждый модель входит определенное числотаблиц. Пусть имеется модуль «Операционный День», условно назовем егоOPDAY, тогда удобно, что все таблицы данного модуля наименовались следующимобразовам OPDAY_CUSTOMERS (ТАБЛИЦА КЛИЕНТОВ), OPDAY_ACCOUNT (таблица счетов) ит.п. При наменовании столбцов таблицы желательно придерживаться следующегоподхода: _.Например, для таблицы OPDAY_CUSTOMERS наименование столбцов удобно реализоватьследующим образом CUST_NNN (порядковый номер записи), CUST_FIO (фио клиента),CUST_ACCOUNT_NNN (ссылка на таблицу счетов) и т.п. Практически в каждойорганизации, занимающейся разработкой АИС существуют свои нормы к наименованиюмодулей, таблиц, столбцов и объектов базы данных, однако общие принципы вомногом схожи с приведенным в данных примерах. Теперь рассмотрим основныепринципы преобразования отношений:
Отношениеодин-к-одному.
Рассмотримпример установки отношений клиентов и счетов в АБС (см. рис.5).
/>
Рис.5. Отношение один кодному.
ОтношениеИМЕЕТ ТЕКУЩИЙ СЧЕТ представляет собой связь один-к-одному. Это означает, чтоклиент имеет не более одного текущего счета и каждым текущим счетом пользуетсятолько один клиент. Если мы решим, что ключами являются №-КЛИЕНТА для CUSTOMER(КЛИЕНТ) и №-ТЕКУЩЕГО-СЧЕТА для ACCOUNT_NUMBER (ТЕКУЩИЙ СЧЕТ), то мы получимдве реляционные таблицы, каждая из которых состоит из одного столбца.
CUSTOMER (CUST_NNN)
ACCOUNT (ACCOUNT_NUMBER)
Длятого чтобы показать связь между этими двумя таблицами, мы должны включитьссылку на ACCOUNT_NUMBER в таблицу CUSTOMER и и ссылку на СUST_NNN в таблицуACCOUNT. Каждый из этих столбцов будет внешним ключом, указывающим на другуютаблицу.
CUSTOMER (CUST_NNN, CUST_ACCOUNT_NUMBER )
Внешний ключ:CUST_ACCOUNT_NUMBER ссылается наACCOUNT_NUMBER.
ACCOUNT (ACCOUNT_NUMBER, ACCOUNT_CUST_NNN)
Внешнийключ: ACCOUNT_CUST_NNN ссылается на CUST_NNN.
Резюме:отношение один-к-одному преобразуется путем помещения одного из объектныхмножеств в качестве атрибута в таблицу второго объектного множества. Его выборопределяется потребностями конкретного приложения. Во многих случаях обаварианта приемлемы.
Отношениеодин-ко-многим.
Предположим,что отношение ИМЕЕТ-ТЕКУЩИЙ-СЧЕТ имеет мощность «много» со стороныACCOUNT.
/>
Рис.6. Отношение один комногим.
Этоозначает, что у клиента может быть несколько текущих счетов, но каждым текущимсчетом по-прежнему пользуется только один клиент. Таким образом, в любомотношении один-ко-многим в. таблицу, описывающую объект, мощность со стороныкоторого равна «многим», включается столбец, являющийся внешнимключом, указывающим на другой объект.
Отношениемногие-ко-многим.
ОтношениеИМЕЕТ-ТЕКУЩИЙ-СЧЕТ имеет мощность многие-ко-многим.
база данных реляционный

/>
Рис.7. Отношение многие комногим.
Такимобразом, мы предполагаем, что у клиента может быть несколько текущих счетов, ичто каждым текущим счетом могут пользоваться несколько клиентов. Для того чтобыпреобразовать отношение многие-ко-многим целесообразно создать таблицупересечения, представляющую элементы двух других таблиц, находящихся вотношении многие-ко-многим.
Рекурсивныеотношения
/>
Рис.8. Рекурсивные отношения.
Объектноемножество WORKER(РАБОЧИЙ), дважды встречающееся на диаграмме, и это одно и тоже объектное множество в обоих случаях. Обе копии объектного множестваWORKER(РАБОЧИЙ) имеют одни и те же атрибуты. В этой модели два экземпляраобъектного множества WORKER(РАБОЧИЙ) использованы для удобства, чтобы показатьотношение SUPERVISES(КОНТРОЛИРУЕТ), существующее между объектамиWORKER(РАБОЧИЙ) и WORKER(РАБОЧИЙ). Это отношение называется рекурсивным,поскольку оно связывает объектное множество с ним самим. В данном случаеотношение мощности один-ко-многим означает, что одному работнику подчиняютсянесколько других работников.
WORKER (WORKER-ID, NAME, HOURLY-RATE, WORKER-ID)

Чтобыпреобразовать объектное множество WORKER вместе с его атрибутами и отношениемSUPERVISES в реляционную таблицу нужно изменить имя второго атрибута WORKER-IDна имя, соответствующее отношению SUPERVISES, которое оно представляет. SUPV-ID.
WORKER (WORKER-ID, NAME, HOURLY-RАТЕ, SUPV-ID)
Внешнийключ: SUPV-ID ссылается на WORKER
SUPV-ID- это рекурсивный внешний ключ, поскольку он ссылается на WORKER-ID, то естьключ своей собственной таблицы. Таким образом, в результате преобразованиярекурсивных отношений появляются рекурсивные внешние ключи.
Функциональныезависимости, определенные для реляционной модели, являются атрибутами отношенияодин-к-одному или один-ко-многим.
Описанныйпроцесс преобразования каждой из этих конструкций в атрибуты реляционных таблицгарантирует, что они будут зависеть только от ключевых атрибутов. Такимобразом, каждая полученная реляционная таблица будет иметь ЗНФ. Многозначныеатрибуты реляционной модели встречаются только в отношениях многие-ко-многим. Посколькуони преобразуются в реляционные таблицы, обладающие составными ключами изключевых атрибутов отдельных объектных множеств, то они гарантированно имеют4НФ.5. Понятие языка определения данных (ЯОД — DBTG)
Язык- средство, при помощи которого определяется структура данных или схема, атакже происходит запоминание данных и манипуляция ими. Язык, которымопределяется схема, называется языком определения данных (ЯОД), а язык,используемый для запоминания данных и манипуляции ими, называется языком манипуляцииданными (ЯМД).
Процедураприменения ЯОД и определения схемы такова:
1. Создаетсяконцептуальная модель данных.
2. Концептуальнаямодель данных преобразуется в диаграмму сетевой структуры данных.
3. Проверяется,существуют ли между типами записей отношения один-ко-многим. Они могут бытьнепосредственно реализованы в виде наборов DBTG.
4. Еслиесть отношения мощности многие-ко-многим, то каждое из них преобразуется в дванабора путем создания записи связи.
5. Еслиесть n-арные отношения, то они преобразуются в бинарные отношения.
6. ПрименяетсяЯОД для реализации схемы.
Схемасостоит из следующих частей:
1. Разделсхемы.Раздел схемы DBTG, задающий имя схемы.
2. Разделзаписей.Раздел схемы DBTG, определяющий каждую запись: ее элементы данных и ее адрес.
3. Разделнаборов.Раздел схемы DBTG, определяющий наборы, включая типы записей владельцев ичленов.
Подсхемы- это в основном, подмножества схемы. В подсхеме могут быть сгруппированыэлементы данных, которые не были сгруппированы в схеме; записи и наборы могутбыть переименованы и порядок описаний может быть изменен.
Принятогостандарта DBTG для подсхемы не существует; однако, обычно используютсяследующие отделы:
1. Отделзаголовка, позволяющий присвоить имя подсхеме и указать связанную с ней схему.
2. Отделпреобразования, в котором при желании производится замена имен из схемы нанужные в подсхеме.
3. Структурныйотдел, в котором задается, какие записи, элементы данных и наборы из схемыдолжны присутствовать в подсхеме. Этот отдел состоит из разделов записей инаборов.
Разделзаписей подсхемы. Раздел структурного отдела, в котором задаются записи, элементыданных и типы данных подсхемы.
Разделнаборов подсхемы. Раздел структурного отдела, в котором задаются наборы, которыедолжны быть включены в подсхему.
Подсхемапозволяет пользователю строить из предопределенной схемы схему, соответствующуюнуждам конкретного приложения.6. Язык манипуляции данными (ЯМД)
Языкманипуляции данными (ЯМД) обеспечивает эффективные команды манипуляции сетевой системойбазы данных. ЯМД позволяет пользователям выполнять над базой данных операции вцелях получения информации, создания отчетов, а также обновления и изменениясодержимого записей.
Основныекоманды ЯМД можно классифицировать следующим образом: команды передвижения,команды извлечения, команды обновления записей, команды обновления наборов.
Табл.2.Основные типы команд ЯМД. Наименование типа команд Назначение Команды передвижения. Команды, применяемые для поиска записей базы данных. Команды извлечения. Команды, применяемые для извлечения записей базы данных. Команды обновления записей. Команды, применяемые для изменения значений записей. Команды обновления наборов. Команды, применяемые для добавления, изменения или удаления экземпляров наборов.

Список литературы
 
1. ПоповИ.Г., Мамонов С.Г. Информационные системы. М.: Инфра, 2007.
2. АбросимовА.Г. Бородинова М.А. Теория экономических информационных систем. Учебноепособие — Самара. Изд-во Самарск.гос. экон. акад., 2007.
3.Информационные системы. Учебник /Петров В.Н. – СПб.: Питер, 2008.
4.Информационное обеспечение систем управления. Учебное пособие/Голенищев Э.П.,Клименко И.В. — Ростов н/Д: Феникс, 2009.
5.Интеллектуальные информационные системы в экономике. Учебное пособие/ТельновЮ.Ф. Издание третье, расширенное и доработанное. Серия «Экономика и бизнес». –Москва.: СИНТЕГ, 2009.