Гайдамакин Н.А. Автоматизированные информационные системы, базы и банки данных. Вводный курс Учебное пособие

Подождите немного. Документ загружается.

3.2. Проектирование банков данных фактографических АИС

видно, должны являться работники СлДОУ, руководители и ис-

полнители документов в подразделениях.

Главным итоговым результатом

концептусшьного

проекти-

рования является определение основных объектов-сущностей

предметной области

отношений

мсусду

ними. В большин-

стве

случаев

организационные,

технологические

и прочие от-

ношения предметной области имеют

документальное

выраже-

ние в различного рода оргаиизациотю-распорядительпых, ин-

формационно-справочных

других

нормативио-слулсебиых

документах. Поэтому

вьщсление

основных информационных

объектов-сущностей предметной области начинается с анализа

таких документов и

регламентации

(положения, инструкции,

бланки, формализованные карточки и отчеты, формы, журна-

лы

т. п.).

Анализ «бумаж1юй» документации

позволяет

с^юрмировать

перечень атрибутов, характеризующих те или иные объекты-

сущности и отношения предметной области. При этом в одном

нормативном или служебном документе могут быть отражены

атрибуты различных объектов сущностей и отношений. Поэто-

му можно выделить два подхода формирования

перечня

сущ-

ностных объектов предметной области и их атрибутов — де-

дуктивный и иидуктивный.

В первом подходе на основе формирования

общего

пред-

ставления о предметной области АИС, функций АИС, а также

информационных потребностей основных абонентов-пользо-

вателей выделяются основные понятия

категории, которыми

оперируют (которыми выражаются) фрагменты пред.метиой

области. Данные понятия и категории принимаются за перво-

начальную основу списка объектов-сущностей предметной об-

ласти. Далее на основе анализа служебной и технологической

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

за-

тказчиком

формируются атрибуты, характеризующие

вьщелен-

ные объекты-сущности.

При определении перечня атрибутов каждого объекта пред-

метной области, как и самого перечня объектов сущностей, ру-

ководствуются соображениями минимальной

достаточнос-

3. Основы создания информационных

систем

пш, соблюдая знаменитый принцип «бритвы

Оккама»^

извест-

ного английского философа Уильяма

Оккама

(1285-1349).

Ина-

че говоря, и перечень самих объектов-сущностей и набор их

атрибутов должен быть достаточным для решения всех част-

ных задач системы и удовлетворять информационным потреб-

ностям абонентов-пользователей системы, но он также не дол-

жен быть избыточным, чтобы минимизировать расходы по

накоплению информации и эксплуатации АИС.

Во втором подходе на основе анализа служебной и техно-

логической документации выделяются все необходимые для

решения частных задач АИС сведения, их характеристики и

параметры, и на этой основе формируется общий перечень ат-

рибутов предметной области. Далее на основе эвристическо-

го анализа производится агрегация (группирование) атрибутов

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

ной области.

Часть атрибутов и понятий предметной области выражают

процессы-отношения между объектами-сущностями. Такие

атрибуты

вьщеляются,

и анализируются параметры

харак-

тер связен, которые они

выражают—структурность,

направ-

ленность, мноэюественность, обязательность наличия для эк-

земпляров объектов.

Чаще всего выделение объектов-сущностей, их атрибутов

и отношений-связей осуществляется комбинировситым спосо-

бом на итерсщионной основе, с многократным уточнением ис-

ходного списка объектов, агрегацией атрибутов в группы и т. д.

Распространенным приемом в этом случае является

«обобще-

ние» некоторых понятий и атрибутов. Суть обобщения заклю-

чается в объединении в одну сущность близких или однотип-

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

ных проявлений и вариантов. К примеру, совокупность понятий

«холодильник», «стиральная машина», «телевизор», «пылесос»

и т. п. обобщается сущностью «Бытовые электроприборы» с

-«Не умножай число сущностей без

необходимости».

См., например, с.

.^17

работе:

Филосо(1)ский

словарь / Под ред.

М.

Т.

Тимо(1)еева.

6-е изд., перераб. и доп. —

М.:

Политиздат,

1991.

3.2.

Проектирование

банков данных фактографических АИС

атрибутом «Тип», имеющим соответствующий список значе-

ний.

В примере с АИС по делопроизводству на

основе

предва-

рительного формирования общего

представления

о предметной

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

СлДОУ (структура журналов регистрации и учета документов,

порядок ведения номенклатурных дел и т. д.) можно выделить

следующие понятия и категории — документ, реквизиты, ис-

полнитель, подготовка, согласование, руководитель, утверж-

дение, подписание, регистрация, доклад документа, резолюция,

мероприятия, подразделения, доведение до исполнителей, ис-

полнение документа, контроль исполнения,

хрстенис.

уничто-

эюение, выдача, дело в производстве, архивное дело. Часть этих

понятий и категорий прямо выражают объекты-сущности (до-

кумент), часть выражает атрибуты сущностей (реквизиты до-

кумента). Часть понятий (исполнитель,

руководитель)

можно

обобщить одной сущностью (сотрудник). Часть понятий (ис-

полнение, согласование, подписание, утверждение) выражает

отнощения между сущностями (между документом и сотруд-

ником).

В итоге перечень объектов сущностей

предметной

области

АИС делопроизводства и их атрибутов может быть следующим':

• Документ

(Рег. №, Дата, Название

вида.

Заголовок к тек-

сту, Гриф, Текст);

• Сотрудник (Таб. №, ФИО, Подразделение, Должность, Ка-

бинет, Телефон);

• Подразделение

(№, Наименование);

• Мероприятие (Наименование, Дата начала, Дата оконча-

ния, Завершенность);

• Дело (№№, Наименование, Дата начала, Дата окончания,

Гриф).

Отнощения, которыми охвачены

объекты-сущности,

мож-

но отобразить следующей таблицей:

'Данный вариант является

исключительно

нллюстратпвио-учебиым.

3. Основы создания информационных

систе м

Таблица 3.2

Отношения объектов-сущностей предметной области АИС

по делопроизводству

11и1мсн(,)1и)1ис

"Утвер/Кдеп"

"Исполнен"

"Подписан"

"Напечатан"

"Согласован"

'Зав1гзи1х>ван"

"Нтр;шлен"

"Подготовлен"

"Руководит"

"Работают"

"Отражает"

"Исполнение"

Ответственный

Проводит

Участвует

Прнобиси

Ведет

Мсж;1>'

к:ш1мн

Тк'рПМГ)

ОПЬСК !

Сотрудник

Сот|1удник

Сотрудник

СотруД1П1 К

Сотрудник

Документ

П1>др;|зделение

С0ТруД1И1К

П4>д[Х1зделение

Документ

Сотрудник

Подразделение

Дела

Сотрудник

Вк||>1И

14>1л:к 1

Документ

Подразделение

До1^мент

Под1\1зделенпе

Сотрулди1к

Мероприятие

Мероприят11е

Документы

Дела

'1ип

штщк'пт"!

"ОД1Н]-КО-МНОП1М "

"Один-ко-множм"

"Ми

огие-К1>

многим"

'ОДИН-КО-МНОП1М "

"МН0П1е-КО-МН0П1М "

"МнОП1е-кЧ.>МИОП1М "

"0ДИН-К1>МН0П1М "

"0ДНН-К0-.МН0П1М "

"Одии-к-одиому"

"0ДИН-К1>МН0П1М "

"Миоп1е-К1>мнотм"

"Многие-К1>многнм"

"Один-КО-многим"

"О дин-к1>

многим"

"Мноп1е-к1>многнм"

"Один-ко-мнотм"

"ОД1И|-КО-МНОП1М "

иГ|}Г):11е,11>Н1чг1ъ

|)ГН1>Ик'1ИИ 1

1111:ср[«ом

оОи-кк*

Иет

Пет

Нет

1-1ет

Да

Нет

Да

Нет

Е!Т01Х>М

1Х"11.еК1С

Пет

Да

Нет

Д1

Пет

Д1

д>

Пет

Л»

Да

Формализованное описание концептуальной схемы бан-

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

ких моделей данных. Семантические модели данных возникли

в противовес ограниченности средств и способов выражения

смысловой организации связей между таблицами-сущностями

в реляционной модели данных. При этом в большинстве случа-

ев семантические модели применяются на стадии концептуаль-

ного проектирования с последующим преобразованием концеп-

туальной схемы банка данных в структуру соответствующей

реляционной базы данных. В этом смысле разработку концеп-

туальной схемы банка данных называют

семантическиммо-

делированием данных.

Наиболее популярными являются разновидности уже упо-

минавшейся

ЕК-модели,

использующие для графического пред-

3.2.

Проектирование

банков

даниых

фактографических АИС

ставления структуры данных аппарат диаграмм Бахмана. Фор-

мализованное описание

ЕК-моделп

было предложено в

1976

году Петером Пин-Шен

Ченом^.

Основными компонента-

ми структурной составляющей семантической модели Чена яв-

ляются сущности, наборы сущностей,

сиприбуты

сущностей,

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

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

атрибуты

связей^.

Оригинальные предложения П. Чена по графическому обо-

значению в диаграммах Бахмана сущностей и связей претерпе-

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

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

именно — объекты-сущности изображать прямоугольниками,

при необходимости вставляя в них перечень их атрибутов, свя-

зи типа «Один-ко-многим» будем обозначать линиями с парой

символов (1

°о)

на концах соответствующих объектов, связи типа

«Многие-ко-многим» линиями с парой символов

(°о

°о)

и связи

типа «Один-к-одному» линиями с парой символов

(11).

Обяза-

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

на конце соответствующей связи, необязательный

характер—

пустым квадратиком.

В качестве примера на рис. 3.1 приведена концептуальная

схема банка данных АИС по делопроизводству.

Формализованное описание

копцептуалыюй

схемы бан-

ка данных в большинстве случаев осуществляется на бумаге и

служит основой эскизного проекта создания банка данных ин-

формационной системы. Следующим шагом в проектировании

является построение средствами СУБД схемы банка (базы) дан-

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

Иначе говоря, средствами СУБД, поддерживающей ту или иную

модель данных, скажем реляционную, создается структура бан-

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

'' Перевод

оригнннлыюй

статьи

П.Чеиа

«Модель

«Сущиость-Свячь»

— шаг к еди-

ному представлению данных» представлен в журнале

СУБД.

— №3.— 1995 г. С.

137-

157.

' Легко заметить, что семантическая модель Чена являе

1'ся

агрегацией

и обобще-

нием сетевой и реляционных моделей.

3. Основы создания информационных

систе м

р**

1от

Документы

Дата

^^ай

Название вида

,--

Заголовок к тексту

.'^ ^ Гриф

Подчиняется

Дела

Наименование

Дата начала

Дата окончания

Гриф

Завершенность

Подразделения

Рис.

3.1.

Пример концептуальной схемы банка данных А ИС но

делопроизводству

при переходе от концептуального к схемно-структурному про-

ектированию может иметься разрыв в семантических средствах

выражения сущностей, атрибутов, связей и т. д. Адекватность

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

ся, как уже отмечалось, эвристически и эмпирически в ходе

отладки и дальнейшей эксплуатации банка данных.

3.2.2. Проектирование схем реляционных баз

данных

В реляционных

СУБД

при проектировании схемы реля-

ционной

базы данных можно выделить следующую последо-

вательность процедур:

а) определение перечня таблиц и их связей;

3.2.

Проектирование

банков данных фактографических АИС

б)

определение перечня полей, типов полей, ключевых по-

лей каждой таблицы (разработка схем таблиц-отношений), ус-

тановление связей между таблицами через внешние ключи;

в) определение

и установление индексов (индексирования)

для полей в таблицах;

г) разработка списков (словарей) для полей с перечисли-

тельным характером значений данных;

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

лиц и связям;

е) нормализация таблиц, доработка перечня таблиц и их

связей.

Технологически процесс проектирования рс1зделяют на про-

цесс предварительного проектирования таблиц и связей меж-

ду ними:

а)

,б),в),г)ид)и последующую пормсшизацию таблиц е).

3.2.2.1. Проектирование и создание таблиц

В качестве первоначальной основы при определении пе-

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

перечень выделенных объектов-сущностей

отногнений

кон-

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

объекта-суи{ности в реляционных СУБД осуществляется про-

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

Поля таблиц определяются на основе первоначально от-

работанных атрибутов информационных объектов концепту-

альной схемы банка данных. При этом дополнительно к основ-

ным базисным характеристикам (домен, поле-атрибут, кортеж,

отношение, ключ, внешний ключ) в

СУБД

используется тип

поля. По своему смыслу тип поля совпадает с понятием типа

данных в языках программирования. Традиционные СУБД под-

держивают лишь ограниченный набор простых типов полей —

числовые, символьные, темпоральные (время, дата), булевы (ло-

гические). Современные СУБД оперируют также и со специа-

лизированными типами полей (денежные величины), а также

со сложными типами полей, заимствованными из языков про-

граммирования высокого уровня.

Домены полей таблиц в реляционных СУБД определяют

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

3. Основы создания

информацноппых

систем

являются тождественным понятием типу поля (данных). В не-

котором смысле домен можно трактовать как некоторое под-

множество базисного типа данных с определенной смысловой

нагрузкой, — например, множество всех имен из множества

всевозможных значений символьного типа данных.

Определение и установление ключевых полеГпабпиц в ре-

ляционных СУБД является следствием основополагающего тре-

бования

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

та

блиц-отнощений—

требования уникальности каждого кортежа-строки. Иначегово-

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

полей, в обязательном порядке должно быть определено как

ключ. Определение ключевого поля осуществляется на основе

смьюлового эвристического анализа тематики таблицы при со-

блюдении

принципамшшмсслыюй достаточности,т.

е. коли-

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

мальным.

Правильность определения ключа таблицы проверяется эм-

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

кортежей значений ключа. Во многих случаях выбор ключа яв-

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

ключевым для таблицы «Сотрудники»? Напрашивается состав-

ной ключ из полей «Фамилия», «Имя», «Отчество», однако в

конкретных жизненных ситуациях имеется вероятность их со-

впадения. Можно добавить в состав ключа еще поле «Год рож-

дения», но и при этом все равно сохранится, хотя и несколько

снизится, вероятность совпадения. Альтернативным вариантом

ключа может быть «№ паспорта», если ситуации с наличием у

одного лица нескольких паспортов полностью исключаются.

Если в банке данных ограничиться только сотрудниками дан-

ной организации, то отработанным вариантом ключа может

быть табельный номер сотрудника — «Таб.

№»*".

На практике

распространенным приемом при проектировании таблиц явля-

ется искусственное введение в качестве ключа параметра, яв-

'' Табельный номер как раз и является примером

уникшьного

параметра для каж-

дого сотрудника в платежных ведомостях (таблицах) для преодоления ситуаций с со-

впадением фамилий, имен и т. д. сотрудников.

3.2. Проектирование банков данных

фактографических

АИС

ляющегося аналогом табельного номера — внутреннего учет-

ного номера экземпляра (записи) соответствующего объекта.

В некоторых СУБД для создания полей с уникальными

идентификационными номерами кортежей-записей введен до-

полнительный тип поля, называемый «Счетчиком» или полем

типа

«АиТОШС».

В отличие от обычных числовых (или по-

рядкового типа) полей, значения счетчика генерируются СУБД

автоматически при образовании новой записи и только в возра-

стающем

порядке,

считая все ранее созданные, в том числе и

удаленные записи.

Как уже отмечалось, реляционная модель организации дан-

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

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

сущности предметной области, — «Одип-ко-лтогил!» и «Одип-

к-одномуь.

Связь типа

«Один-ко-многим»

реализует, вероятно, наибо-

лее распространенный тип отношений между таблицами, ког-

да одной записи в таблице на стороне «один» может соответ-

ствовать несколько записей в таблице на стороне «многие». Со-

здание связей происходит в два этапа. На первом этапе в схеме

таблицы, находящейся по создаваемой связи на стороне «мно-

гие», определяется поле с теми же параметрами (и, как прави-

ло,

тем же именем), что и ключевое поле таблицы на стороне

«один», т. е. создается поле внешнего ключа. На втором этапе

с помощью специальных средств СУБД собственно и опреде-

ляется связь между таблицами путем установления (через спе-

цисшьныс

внутренние системные таблицы) факта соответствия

ключевого поля таблицы на стороне «один» полю внешнего

ключа в таблице на стороне «многие».

В связях типа «Один-к-одному» каждой связанной записи

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

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

зуется путем связывания таблиц по одноименным и однотип-

ным ключевым полям, т. е.

когда.связываемые

табл1

щы имеют

одинаковые ключевые поля. Эта ситуация по сути соответству-

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

3. Основы создания информационных

систем

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

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

по определенным полям, либо целесообразностью выделения

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

пример, из исходной таблицы «Студенты» можно выделить все

записи по студентам, которые живут в общежитии, и образо-

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

Пример такой связи приведен на рис. 3.2.

567

568

569

570

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

ФИО

Ив

шов

И.И.

Петров П.П,

Сидор

се

С.С.

Егоров Е.Е.

"Студенты"

Группа

И-201

И-205

Ксынатав

общежитии

Прео6риава1шах

таблица "Студенты"

Связаннаятаблнца

"Студенты,

пронмвающие

общежитии"

Т»5_Л'|

студента

567

568

569

570

ФИО

ИвановИ.И.

Петров П.П.

Сидор

оеаС.С.

Егоров Е.Е.

Группа

И-201

И-205

стгампа

368

569

ФИО

Петров П.П.

СидороваС.С.

Комната в

общежш-ни

Рис. 3.2.

Пр1шер

реализации связи

«Одш1-к-од110л_1у»

в реляцион-

ных СУБД

Связи типа «Многие-ко-многим» в реляционных СУБД в

большинстве случаев реализуются через создание двух связей

«Один-ко-миогим», которые связывают исходные таблицы с

третьей общей (связной) таблицей. Ключ связной таблицы со-

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

ми внешнего ключа для связываемых отношением «Многие-

ко-многим» исходных таблиц. Пример реализации связи типа

«Многие-ко-многим», выражающей отношение «Согласование»

между таблицами «Документы» и «Сотрудники», приведен на

рис.

3.3.

Еще одним важным параметром при проектировании таб-

лиц является определение необходимости индексирования тех

или иных полей таблиц. Определение и установление индексов

100