Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:

Ю. А. Григорьев, Г. И. Ревунков - Банки данных

.pdf
Скачиваний:
334
Добавлен:
10.02.2015
Размер:
7.54 Mб
Скачать

/. Основы построения банков данных

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

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

Контрольные вопросы

1.Сформулируйте требования, предъявляемые к БД.

2.Укажите последовательность действий СУБД при обработке запросов.

3.Перечислите функции АБД.

4.Что подразумевается под независимостью данных?

5.Назовите отличительные особенности ЭС?

6.Укажите области применения ЭС и дайте характеристику задач, для решения которых целесообразно применять ЭС.

2. МОДЕЛИ ДАННЫХ

Развитие теории и практики проектирования и эксплуатации БД со­ провождается интенсивным развитием МД. В этой главе рассматриваются МД, объектом исследования которых выступают сами данные, га струк­ турная композиция, правила построения, операции, которые мооюно выпол­ нять над этими данными; обсуж:даются три подхода к представлению БД: иерархический, сетевой и реляционный.

2.1. Инфологический подход к проектированию информационных систем

База данных представляет собой некоторую целевую модель ПО. В БД находят отражение факты о ПО, которые лежат в сфере интересов поль­ зователей АС.

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

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

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

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

41

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

сферы: реальный мир или объективную систему, информационную и датологическую сферы.

Основными составляющими объектной системы являются: объект; свойство; связь (или объектное отношение); время.

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

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

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

Каждая связь между объектами по числу входящих в нее объектов ха­ рактеризуется степенью п = 2, 3, ..., к (бинарная, тернарная, ..., /г-арная). Объекты имеют определенное состояние как в отдельные моменты времени, так и в течение некоторых временных интервалов. Концепция времени по­ зволяет строить динамические модели, в которых отображается зависимость от времени составляющих объектной системы.

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

<o.yJ>.

где о — объект (или п объектов); у — свойство (или «-арная связь); t — время. Различают элементарные ситуации типа «свойство»:

<о,р,/>,

и реляционного типа:

«ОиОъ ...,On>,r,t>,

где/? — элемент множества свойств; г — элемент множества связей.

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

42

2.1. Мифологический подход к проектированию ииформациоиных систем

Множество всех объектов, имеющих общее свойство р, называется группой объектов 0(р). В объектной системе группы объектов могут быть пересекающиеся и не пересекающиеся.

В инфологическом подходе используется также понятие типа элемен­ тарной ситуации:

где X — объектная группа; у — атрибут (множество свойств объектной группы или связь между п объектами).

Таким образом, составляющие объектной системы группируются в классы подобных составляющих: объекты — в типы объектов (группы объ­ ектов), свойства формируют атрибуты, а элементарные ситуации группиру­ ются в типы элементарных ситуаций.

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

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

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

<х, у, z>,

где X — сведения об объекте; у — сведения о свойствах или связях; z — сведения о времени.

Аналогично элементарным ситуациям в рассмотрение вводятся эле­ ментарные сообщения типа «свойств» и элементарные сообщения реляци­ онного типа.

Тройка <х, у, z> представляет собой полное элементарное сообщение, содержащее сведения об объекте, предикате и времени. Если отсутствует хотя бы одна составляющая, то получается неполное элементарное сообще­ ние. Запросы к информационной системе представляются в неполных эле­ ментарных сообщениях.

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

43

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

Множеству элементарных фактов соответствует множество истинных пол­ ных элементарных сообщений.

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

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

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

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

Модель «сущность — связь»

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

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

44

2.1. Мифологический подход к проектированию информационных систем

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

Составляющая «время» в составе конструктивных элементов в явном виде отсутствует. Время наступления событий может быть представлено в модели с использованием атрибутов, например: Год рождения, Дата посту­ пления, Окончено в мае. Получено в декабре и т.п.

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

В модели используется также понятие «экземпляр сущности». Тип сущности определяет набор однородных объектов, а понятие «экземпляр сущности» относится к конкретному объекту в наборе. Каждый рассматри­ ваемый в модели тип сущности должен быть поименован.

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

Атрибут — это поименованная характеристика сущности. Атрибут принимает значения из некоторого множества значений. В модели атрибут выступает в качестве средства, с помощью которого моделируются свойства сущностей. Например, для описания свойств сущности Книга могут быть использованы атрибуты Название, Фамилия автора. Год издания.

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

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

45

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

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

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

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

Наиболее часто встречаются бинарные связи. Рассмотрим классифи­ кацию бинарных связей.

Отобралсение 1:1 {связь один к одному). Это отображение опреде­ ляет такой тип связи между элементами А и В, когда каждому экземпляру элемента В соответствует один и только один экземпляр элемента А. Это означает, что один экземпляр элемента, от которого направлена связь, на­ пример А, идентифицирует один и только один экземпляр другого элемента В (к которому направлена связь), и наоборот. Идентификация экземпляров элементов уникальна в обоих направлениях для отображения 1:1.

Отобраэюение \:М (связь один ко многим). Отображение 1:М опре­ деляет такой тип связи между элементами А и В, когда одному экземпляру элемента А соответствует О, 1 или несколько экземпляров элемента В. Но при этом каждый экземпляр элемента В связан только с одним экземпляром элемента^, т.е. идентификация экземпляров при отображении 1:Муникаль­ на только в направлении от В к А.

Отобраэюение М: 1 {связь многие к одному). Это отображение явля­ ется обратным отображению 1 :М.

Отобраэюение М.М {связь многие ко многим). Отображение М\М

определяет тип связи между элементами А и В, при котором каждому эк­ земпляру элемента А соответствует 0; 1 или несколько экземпляров элемен­ та 5 и наоборот, т.е. с одним экземпляром А может быть связано либо не­ сколько экземпляров элемента В, либо один, либо ни одного. И наоборот, с одним экземпляром элемента В также может быть связано либо несколько экземпляров элемента А, либо один, либо ни одного, т.е. идентификация экземпляров элементов является неуникальной в обоих направлениях.

Ассоциация типа 1 {простая). Ассоциация этого типа определяет од­ нонаправленную связь от элемента А к элементу В, при которой одному и

46

2.1. Мифологический подход к проектированию информационных систем

тому же экземпляру элемента А соответствует один и тот же экземпляр эле­ мента В. При этом обратная связь не определена. Идентификация экземпляров элемента5 экземплярами элемента^ является уникальной (однозначной).

Ассоциация типа М (слоэ/сиая). Ассоциация типа Л/определяет одно­ направленную связь от элемента А к элементу В, при которой одному и тому же экземпляру элемента А соответствует 0; 1 или несколько экземпляров элемента В. При этом обратная связь не определена. Идентификация экземп­ ляров элемента В экземплярами элементам! не является уникальной.

Иногда специально выделяют частный случай М-ассоциации — когда одному экземпляру элемента А соответствует только один или ни одного экземпляра элемента В, Такая ассоциация называется «условная» и обозна­ чается как ассоциация типа С.

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

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

Деталь X размещена на складе 4

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

Или, например, отношение Экзамен между сущностями Студент, Дисциплина и Преподаватель само может рассматриваться как сущность и иметь, например, следующие описательные атрибуты: Оценка и Дата Экзамена.

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

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

пами сущностей ненаправленными ребрами; связи (отношения) представлять ромбами, соединяя их с соответст­

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

При выполнении моделирования применяют следующие общие пра­

вила:

47

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

используют только три типа конструктивных элементов сущность, ат­ рибут, связь;

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

Для моделирования ПО проектировщик разбивает ее на ряд локаль­ ных областей, в каждой из которых и выполняет моделирование. Затем мо­ дели объединяются.

2.2. Понятие модели данных

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

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

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

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

2)специфицируют признаки (характеристики) структур данного типа;

3)специфицируют правила композиции (составления) структур дан­ ного типа из логических структур других типов;

4)специфицируют правила обработки структур данного типа проце­ дурными операторами.

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

48

2.2, Понятие модели данных

ления логической структуры БД и динамического моделирования в БД со­ стояний ПО.

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

Выбор модели данных

Существование различных моделей данных обусловлено большим ко­ личеством разработанных к настоящему времени разнообразных СУБД.

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

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

1)атрибут сущности будет смоделирован полем;

2)значение атрибута — значением поля;

3)тип сущности будет смоделирован типом записи.

Например, тип сущности Служащий, описываемый атрибутами Табельный номер. Фамилия, Год рождения и Образование, может быть смоделирован типом записи, схема которой имеет вид

Служащий (Табельный номер. Фамилия, Год рождения. Образование)

Или, если придерживаться символики, принятой в языках описания многих СУБД:

01 Служащий

02 Табельный номер;ШАБЛОН 9999;КЛЮЧ

02 Фамилия;ШАБЛОН А(25)

02 Год рождения;ШАБЛОН 9999

02 Образование;ШАБЛОН А(10),

где 9999 означает, что значение поля представляет собой число, состоящее из четы­ рех десятичных цифр; А(25) означает, что значение поля будет символьное, длиной

49