Logo GenDocs.ru

Поиск по сайту:  

Загрузка...

Гайдамакин Н. А. Автоматизированные информационные системы, базы и банки данных. Вводный курс - файл Гайдамакин_Автоматизированные информационные системы базы и банки данных Вводный курс_2002 .doc


Гайдамакин Н. А. Автоматизированные информационные системы, базы и банки данных. Вводный курс
скачать (3043.3 kb.)

Доступные файлы (1):

Гайдамакин_Автоматизированные информационные системы базы и банки данных Вводный курс_2002 .doc4199kb.30.12.2002 12:56скачать

содержание

Гайдамакин_Автоматизированные информационные системы базы и банки данных Вводный курс_2002 .doc

1   ...   4   5   6   7   8   9   10   11   ...   23
^

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

3.1. Общие положения по созданию автоматизированных систем


Создание автоматизированных информационных систем в нашей стране регламентируется «Комплексом стандартов и ру­ководящих документов на автоматизированные системы» (ГОСТ 34.201-89, ГОСТ 34.602-89, РД 50-682, РД 50-680-88, ГОСТ 34.601-90, ГОСТ 34.401-90, РД 50-34.698-90, ГОСТ 34.003-90, Р 50-34.119-90). В частности, ГОСТ 34.601-90 опре­деляет следующие стадии и этапы создания АС (см. табл. 3.1).

Таблица 3.1



Одним из центральных элементов всего процесса создания АС является разработка технического задания, структура ко­торого согласно ГОСТ 34.602-89 содержит следующие разде­лы:

1) общие сведения;

2) назначение и цели создания (развития) системы;

3) характеристика объектов автоматизации;

4) требования к системе;

5) состав и содержание работ по созданию системы;

6) порядок контроля и приемки системы;

7) требования к составу и содержанию работ по подготов­ке объекта автоматизации к вводу системы в действие;

8) требования к документированию;

9) источники разработки.

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

1) требования к системе в целом;

2) требования к функциям (задачам), выполняемым систе­мой;

3) требования к видам обеспечения.

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

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

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

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

• к составу, структуре и способам организации данных в системе (информационно-логическая схема)',

• к информационному обмену между компонентами систе­мы;

• к информационной совместимости со смежными систе­мами;

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

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

• к структуре процесса сбора, обработки, передачи данных в системе и представлению данных;

• к защите данных от разрушений при авариях и сбоях в электропитании системы;

• к контролю, хранению, обновлению и восстановлению данных;

• к процедуре придания юридической силы документам, продуцируемым техническими средствами АС.

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

В частности, на этапе 4.1 «Разработки предварительных проектных решений по системе и ее частям» определяются:

• функции АС;

• функции подсистем;

• концепция информационной базы и ее укрупненная струк­тура;

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

• состав вычислительной системы;

• функции и параметры основных программных средств.

На этапе 5.1 «Разработка проектных решений но системе и ее частям» осуществляется разработка общих решений по системе и ее частям:

• по функционально-алгоритмической структуре системы;

• по функциям персонала и организационной структуре;

• по структуре технических средств;

• по алгоритмам решения задач и применяемым языкам;

• по организации и ведению информационной базы (струк­тура базы данных);

• по системе классификации и кодирования информации (словарно-классификационная база);

• по программному обеспечению.

Разработка и документация программного обеспечения в процессе создания или комплектования автоматизированных систем (п. 6.2) регламентируются комплексом стандартов, объединенных в группу «Единая система программной документа­ции (ЕСПД)».

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

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


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

Проектирование банков данных фактографических информационных систем осуществляется на основе формализации структуры и процессов предметной области АИС, и, в соответ­ствии с уровнями представления информации в АИС (см. рис. 1.3), включает концептуальное (пп. 3.1 и 4.1) и схемно-структурное проектирование (п. 5.1).

В организационном плане в группе разработчиков банка данных выделяют специалистов по формализации предметной области, специалистов по программному обеспечению СУБД, а также технических дизайнеров и специалистов по эргономи­ке. Специалисты no формализации предметной области (их еще называют формализаторами или постановщиками задач), как правило, возглавляют весь проект создания АИС и обеспечива­ют (функции взaимодейcтвия с заказчиком. К данной категории специалистов предъявляются наиболее сложные профессио­нальные требования. С одной стороны, такие работники долж­ны быть специалистами в севере программного обеспечения АИС (операционные системы, СУБД и т. д.), а с другой сторо­ны, они должны хорошо представлять (или освоить) конкрет­ную предметную область АИС, т. е. быть (временно стать) бухгалтерами, экономистами, делопроизводителями и т.п. Спе­циалисты по программному обеспечению СУБД относятся к категории профессиональных программистов, определяют вы­бор СУБД и обеспечивают построение ее средствами автома­тизированного банка данных по разработанной постановщиком задачи (формализатором) концептуальной схеме. Технические дизайнеры и cneциaлисты по эргономике обеспечивают эсте­тичную и эргономичную сторону интерфейса с пользователем в АИС при вводе, обработке и поиске данных.
^

3.2.1. Концептуальное проектирование


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

В процедуре концептуального проектирования можно вы­делить следующие этапы:

• обзор и изучение области использования АИС для фор­мирования общего представления о предметной области;

• формирование и анализ круга функций и задач АИС;

• определение основных объектов-сущностей предметной области и отношений между ними;

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

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

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

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

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

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

* В данном случае:

Типовая инструкция по делопроизводству в министерствах и ведомствах Россий­ской Федерации. — М.: Изд-е Комитета по делам архивов при Правительстве Россий­ской Федерации, 1992;

Примерное положение о службе документационного обеспечения управления» (приложение к «Типовой инструкции по делопроизводству...»). — М.: Изд-е Комитета по делам архивов при Правительстве Российской Федерации, 1992;

ГОСТ Р 6.30-97 «Унифицированная Система Организационно-Распорядительной Документации. Требования к оформлению документов».
В результате такого знакомства можно выделить следую­щие фрагменты предметной области:

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

• служба документационного обеспечения управления; его руководители и работники, ведущие регистрацию, учет, обра­ботку и хранение документов.

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

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

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

После формирования общего представления о предметной области производится определение круга функций и задач, ре­шение которых предполагается обеспечивать с помощью АИС. Круг функций и задач АИС определяется на основе декомпози­ции основной цели создания АИС так называемого «лозунга») путем формирования последовательно детализируемых спо­собов их решения с учетом существующей технологии накоп­ления и обработки информации и преодоления ее узких мест с помощью АИС. При этом определяется предварительный пе­речень пользователей системы и уточняются их информацион­ные потребности.

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

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

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

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

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

* «Не умножай число сущностей без необходимости». См., например, с. 317 в работе: Философский словарь / Под ред. М.Т.Тимофеева, 6-е изд., перераб. и доп.— М.: Политиздат, 1991.
Во втором подходе на основе анализа служебной и техно­логической документации выделяются все необходимые для решения частных задач АИС сведения, их характеристики и параметры, и на этой основе формируется общий перечень ат­рибутов предметной области. Далее на основе эвристическо­го анализа производится агрегация (группирование) атрибутов в отдельные группы, образующие объекты-сущности предмет­ной области.

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

Чаще всего выделение объектов-сущностей, их атрибутов и отношений-связей осуществляется комбинированным спосо­бом на итерационной основе, с многократным уточнением ис­ходного списка объектов, агрегацией атрибутов в группы и т. д. Распространенным приемом в этом случае является «обобще­ние» некоторых понятий и атрибутов. Суть обобщения заклю­чается в объединении в одну сущность близких или однотип­ных понятий, категорий, атрибутов на основе анализа их част­ных проявлений и вариантов. К примеру, совокупность понятий «холодильник», «стиральная машина», «телевизор», «пылесос» и т. п. обобщается сущностью «Бытовые электроприборы» с атрибутом «Тип», имеющим соответствующий список значе­ний.

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

В итоге перечень объектов сущностей предметной области АИС делопроизводства и их атрибутов может быть следующим:*

• Документ (Peг. №, Дата, Название вида, Заголовок к тек­сту, Гриф, Текст);

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

• Подразделение (№, Наименование);

• Мероприятие (Наименование, Дата начала, Дата оконча­ния, Завершенность);

• Дело (№№, Наименование, Дата начала, Дата окончания, Гриф).

* Данный вариант является исключительно иллюстративно-учебным.
Отношения, которыми охвачены объекты-сущности, мож­но отобразить следующей таблицей:

Таблица 3.2

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



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

Наиболее популярными являются разновидности уже упо­минавшейся ER-модели, использующие для графического пред­ставления структуры данных аппарат диаграмм Бахмана. Фор­мализованное описание ER-модели было предложено в 1976 году Петером Пин-Шен Ченом.* Основными компонента­ми структурной составляющей семантической модели Чена яв­ляются сущности, наборы сущностей, атрибуты сущностей, наборы значений атрибутов, ключевые атрибуты сущностей. связи, виды связей, атрибуты связей, наборы связей, ключевые атрибуты связей.**

* Перевод оригинальной статьи П. Чена «Модель «Сущность-Связь» — шаг к еди­ному представлению данных» представлен в журнале СУБД.—№3 — 1995 г. С. 137-157.

** Легко заметить, что семантическая модель Чена является агрегацией и обобще­нием сетевой и реляционных моделей.
Оригинальные предложения П. Чена по графическому обо­значению в диаграммах Бахмана сущностей и связей претерпе­ли изменения, и далее мы будем придерживаться современных вариантов графического изображения концептуальных схем, а именно — объекты-сущности изображать прямоугольниками, при необходимости вставляя в них перечень их атрибутов, свя­зи типа «Один-ко-многим» будем обозначать линиями с парой символов (1 ) на концах соответствующих объектов, связи типа «Миогие-ко-многим» линиями с парой символов ( ) и связи типа «Один-к-одному» линиями с парой символов (1 1). Обяза­тельный характер связи будем обозначать черным квадратиком на конце соответствующей связи, необязательный характер — пустым квадратиком.

В качестве примера на рис. 3.1 приведена концептуальная схема банка данных АИС по делопроизводству.

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



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

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


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

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

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

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

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

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

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

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

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


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

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

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

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

Правильность определения ключа таблицы проверяется эм­пирически по возможным ситуациям совпадения у различных кортежей значений ключа. Во многих случаях выбор ключа яв­ляется нетривиальной задачей. Какое поле, к примеру, выбрать ключевым для таблицы «Сотрудники»? Напрашивается состав­ной ключ из полей «Фамилия», «Имя», «Отчество», однако в конкретных жизненных ситуациях имеется вероятность их со­впадения. Можно добавить в состав ключа еще поле «Год рож­дения», но и при этом все равно сохранится, хотя и несколько снизится, вероятность совпадения. Альтернативным вариантом ключа может быть «№ паспорта», если ситуации с наличием у одного лица нескольких паспортов полностью исключаются. Если в банке данных ограничиться только сотрудниками дан­ной организации, то отработанным вариантом ключа может быть табельный номер сотрудника — «Таб.№».* На практике распространенным приемом при проектировании таблиц явля­ется искусственное введение в качестве ключа параметра, являющегося аналогом табельного номера — внутреннего учет­ного номера экземпляра (записи) соответствующего объекта.

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

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

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

В связях типа «Один-к-одному» каждой связанной записи одной таблицы соответствует в точности одна связанная запись в другой таблице. Как уже отмечалось, данный тип связи обра­зуется путем связывания таблиц по одноименным и однотип­ным ключевым полям, т. е. когда связываемые таблицы имеют одинаковые ключевые поля. Эта ситуация по сути соответству­ет разбиению одной большой по количеству столбцов таблицы на две таблицы. Необходимость такого разбиения может быть обусловлена соображениями разграничения доступа к данным по определенным полям, либо целесообразностью выделения некоторого подмножества записей в исходной таблице. Так, на­пример, из исходной таблицы «Студенты» можно выделить все записи по студентам, которые живут в общежитии, и образо­вать две таблицы, связанные отношением «Один-к-одному». Пример такой связи приведен на рис. 3.2.



Рис. 3.2. Пример реализации связи «Один-к-одному» в реляцион­ных СУБД

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

Еще одним важным параметром при проектировании таб­лиц является определение необходимости индексирования тех или иных полей таблиц. Определение и установление индексов полей таблиц базы данных является, как уже отмечалось, важ­ным средством создания условий эффективной обработки дан­ных. Индексирование полей (создание индексных массивов) существенно повышает скорость поиска и доступа к записям базы данных. Однако при этом соответственно замедляется ввод и добавление данных из-за необходимости переупорядочения индексных массивов при любом обновлении, удалении или до­бавлении записей. Поэтому при проектировании таблиц следу­ет тщательно проанализировать, насколько часто при последу­ющей эксплуатации банка данных потребуется поиск или вы­борка строк-записей таблицы по значениям тех или иных полей, исходя из функций и задач АИС. На основе такого анализа и определяются те поля таблицы, для которых необходимо со­здать индексы. К примеру, в таблице «Сотрудники» базы дан­ных по документообороту поле «ФИО» целесообразно опреде­лить индексируемым, так как, очевидно, довольно часто будет требоваться доступ к записям таблицы именно по значению этого поля. А вот поле «№ кабинета» вряд ли целесообразно индексировать, так как исходя из задач и функций АИС по документообороту, можно прогнозировать, что задачи отбора, группирования и прочей обработки записей сточки зрения раз­мещения сотрудников по кабинетам будут достаточно редки­ми.


Рис. 3.3. Реализация связей «Многие-ко-многим» в реляционных СУБД

Анализ практики использования индексов в базах данных позволяет сделать вывод, что если в одной таблице установле­но более 10 индексов, то либо недостаточно продумана струк­тура базы данных (таблицы), либо не совсем обоснованно оп­ределены вопросы обработки данных исходя из задач АИС.

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

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

* Так называемый уникальный индекс. Автоматически устанавливается для клю­чевых полей.

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

Установление списков значений или, иначе говоря, слова­рей позволяет упростить в дальнейшем ввод данных в записях по таким полям путем выбора соответствующего значения из словаря и, кроме того, унифицировать ввод одинаковых значе­ний в различных записях. К примеру, при ручном наборе значе­ния «Среднее» помимо различий из-за возможных орфографи­ческих ошибок, могут быть также и регистровые различия («Среднее», «среднее», «СРЕДНЕЕ»), что в дальнейшем при­ведет к ошибкам поиска, фильтрации и выборки записей.

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

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

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

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

Вместе с тем современные СУБД могут предоставлять и более развитые возможности установления ограничений цело­стности данных. Можно определять допустимые диапазоны зна­чений полей (например, значение поля «Оклад» не может быть меньше величины минимального размера оплаты труда), а так­же относительные соотношения значений по определенным по­лям таблицы (например, значение поля «Количество» в табли­це «Товары» не может быть меньшим значения поля «Мин_за-пас», значение поля «Дата_исполнения» в таблице «Заказы» не может быть позднее поля «Дата_размещения» плюс определен­ное количество дней, скажем 7 дней, исходя из того требова­ния, что любой заказ клиента должен быть исполнен в течение максимум 7 дней). Такие ограничения целостности данных от­ражают ту часть правил и особенностей предметной области АИС, которая не формализуется в рамках реляционной модели данных.*

* Ввиду данного обстоятельства в некоторых англоязычных источниках такие ог­раничения целостности называют «правилами бизнеса».
Другая часть ограничений целостности данных касается уже упоминавшегося требования целостности ссылок.

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

На практике в реляционных СУБД существует три подхо­да реализации требования целостности по ссылкам. В первом подходе запрещается удалять кортеж-запись какой-либо табли­цы, если на него существуют ссылки из связанных таблиц. Ина­че говоря, запись по отделу № 710 можно удалить лишь в том случае, если перед этим удалены (или переадресованы по ссыл­кам на другие записи) все сотрудники со значением «710» внеш­него ключа «№ отдела». Во втором подходе при удалении за­писи отдела № 710 значения внешних ключей всех связанных кортежей таблицы «Сотрудники» автоматически становятся неопределенными.* При третьем подходе осуществляется кас­кадное удаление всех кортежей, связанных с удаляемым корте­жем, т. е. при удалении записи по отделу № 710 автоматически удаляются записи из таблицы «Сотрудники» с соответствую­щим значением внешнего ключа «№ отдела». Выбор того или иного режима целостности ссылок определяется на основе эв­ристического анализа правил и возможных ситуаций в пред­метной области АИС.

* Соответственно в этом случае СУБД различает «пустые» (NULL) и «неопреде­ленные» значения полей.
В заключение отметим, что разделение процесса проекти­рования таблиц на этапы а, б, в, г и д является условным, а сам процесс предварительного проектирования (создания) таблиц, как будет показано в параграфе 4.1, реализуется специальными инструкциями языка SQL.
^

3.2.2.2. Нормализация таблиц


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

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

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

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



Рис. 3.4. Пример приведения таблицы к первой нормальной форме

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

Из приведенного примера видно, что таблицы в первой нормальной форме могут содержать многочисленные ситуации дуб­лирования данных (в приведенном примере по полям «Фами­лия», «Звание», «Кабинет», «Сл.тел.»). Кроме того, в таблице, находящейся в первой нормальной форме, могут встречаться и другие аномалии схемы таблиц-отношений. В частности, в при­веденном примере нельзя образовать запись для сотрудника, не участвовавшего ни в одной операции. Удаляя запись об учас­тии определенного сотрудника в определенной операции, мож­но удалить информацию о том, что он вообще работает в опре­деленном подразделении. При переводе сотрудника в другое подразделение или при его перемещении в другой кабинет при­ходится изменять все записи-кортежи с данным сотрудником по различным операциям. Поэтому Е. Коддом был разработан специальный механизм разбиения таблиц для приведения к более совершенным нормальным формам. Этот механизм ос­нован на понятии функциональной зависимости полей-ат­рибутов.

Поле-атрибут Y функционально зависит от поля-атрибута X, если любому значению Х всегда соответствует в точности одно значение Y. К примеру, атрибут «ФИО» функционально зависит от атрибута «Таб.№», т. е. каждому значению атрибута «Таб.№» соответствует только одно значение атрибута «ФИО». Другим примером является функциональная зависимость поля «Кабинет» от поля «Фамилия», так как обычно один сотрудник имеет рабочее место только в одном кабинете. Легко убедить­ся, что в таблице, находящейся в первой нормальной форме, все неключевые атрибуты функционально зависят от ключа таб­лицы.

Вторая нормальная форма основывается на понятии пол­ной функциональной зависимости. Функциональная зависи­мость неключевого атрибута от составного ключа таблицы называется полной, если он функционально зависит в целом от составного ключа, но не зависит отдельно от любой части со­ставного ключа. В примере, приведенном на рис. 3.4, значение поля-атрибута «Фамилия» определяется только значением поля «Лич.№ сотр.», которое является частью составного ключа таб­лицы, и, следовательно, функционально полной зависимости неключевого поля-атрибута «Фамилия» от составного ключа нет. В полной функциональной зависимости от составного клю­ча находится поле-атрибут «Награда», так как только комбина­ция значений полей «Лич.№ сотр.» и «Условное наименование мероприятий...» определяет конкретное значение поля «Награ­да».

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

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

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

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



Рчс. 3.5. Пример приведения таблицы из первой во вторую нор­мальную форму

В таблицах, находящихся во второй нормальной форме, большинство аномалий, присущих первой скорме, устранено. Вместе с тем по определенным атрибутам также могут сохра­няться многочисленные ситуации дублирования данных. Так, например, в приведенном на рис. 3.5 примере происходит нео­правданное дублирование информации о служебном телефоне «11 22 33», так как атрибут «Сл. тел.» фактически зависит не от атрибута «Лич.№ сотр.»», а от атрибута «Кабинет».* Иначе говоря, наблюдается цепочка функциональной зависимости атрибутов «Лич. № сотр.» — «Кабинет» — «Сл. тел.», а функцио­нальная зависимость атрибута «Сл.тел.» от атрибута «Лич. № сотр.» является лишь логическим следствием такой це­почки зависимостей. В таких ситуациях говорят о транзитив­ной зависимости атрибута «Сл. тел.» от атрибута «Лич. № сотр.».

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

Для преобразования из второй в третью нормальную фор­му таблицу-отношение разделяют на две или более проекции так, чтобы конечные поля-атрибуты в цепочках транзитивной зависимости вынести в отдельные таблицы, связав разделив­шиеся части таблицы внешними ключами по полям-атрибутам, находящимся внутри цепочек транзитивной зависимости. На рис. 3.6 проиллюстрирован процесс приведения таблицы из вто­рой в третью нормальную форму путем разделения цепочки транзитивной зависимости «Лич.№ сотр.» — «Кабинет» — «Сл. тел.». Внутреннее в этой цепочке поле-атрибут «Кабинет» стало соответственно внешним ключом в первой таблице и пер­вичным ключом во второй таблице.



Рис. 3.6. Пример приведения таблицы в третью нормальную форму

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

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



Рис. 3.7. Пример приведения таблицы из третьей нормальной формы в форму Бойса-Кодда

В данной таблице имеются два детерминанта — («Лич. № сотр.», «Операция») и («Фамилия», «Операция»), от каждого из которых функционально полно зависит поле-атри­бут «Мероприятие».

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

* Поэтому иногда нормальную форму Бойса-Кодда считают частным случаем третьей нормальной формы.
Таблица, приведенная на рис. 3.7, не удовлетворяет требо­ванию нормальной формы Бойса-Кодда, так как если устано­вить ключом детерминант («Лич.№ сотр.», «Операция»), то поле-атрибут «Фамилия» будет функционально зависеть от ча­сти составного ключа (от поля «Лич.№ сотр.») и нарушатся тре­бования второй нормальной формы. Следствием та кой ситуа­ции является дублирование данных по полям-атрибутам «Лич. № сотр.» и «Фамилия».

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

Встречаются также случаи, требующие «улучшения» и нор­мальной формы Бойса—Кодда. Такие ситуации связаны с многозначной зависимостью атрибутов. В таблице-отношении с полями-атрибутами X, Y, Z существует многозначная зависи­мость атрибута Y от атрибута Х тогда и только тогда, когда любое значение из множества Y, соответствующее паре значе­ний атрибутов Х и Z, зависит только от значения Y. Для приме­ра рассмотрим таблицу на рис. 3.8. При этом будем считать, что каждый сотрудник, привлеченный к какой-либо операции, в обязательном порядке участвует во всех проводимых в рам­ках данной операции мероприятиях. В этом случае единствен­но возможным ключом является совокупность всех трех полей атрибутов (каждый сотрудник может участвовать в разных опе­рациях, в одной операции может участвовать несколько сотруд­ников).



^ Рис. 3.8. Пример декомпозиции таблицы из нормальной формы Бойса-Кодда в четвертую нормальную форму

Так как имеется единственный возможный составной ключ, то данная таблица автоматически находится в нормальной фор­ме Бойса—Кодда. При этом имеется многозначная зависимость поля-атрибута «Фамилия» от поля-атрибута «Операция» (для любой пары значений атрибутов «Операция»—«Мероприятие» значение атрибута «Фамилия» фактически определяется толь­ко значением атрибута «Операция» при сформулированном выше условии участия каждого сотрудника автоматически во всех мероприятиях данной операции). Аналогично имеется мно­гозначная зависимость поля-атрибута «Мероприятия» от поля-атрибута «Операция». В такой ситуации для внесения инфор­мации о новом сотруднике, вовлекаемом в какую-либо опера­цию, придется добавить столько строк-кортежей, сколько мероприятий проводится в рамках данной операции.

Подобные аномалии устраняет четвертая нормальная фор­ма. Таблица-отношение находится в четвертой нормальной форме тогда и только тогда, когда в случае существования мно­гозначной зависимости атрибута Y от атрибута Х все осталь­ные атрибуты функционально зависят от атрибута X.

Приведение таблицы в четвертую нормальную форму ос­новывается на теореме Фейджина, в которой доказывается воз­можность проецирования без потерь* таблицы с атрибутами X, Y, Z в две таблицы с атрибутами X, Y и X, Z, когда существу­ет многозначная зависимость атрибута Y от атрибута X. Про­цесс декомпозиции проиллюстрирован на рис. 3.8.

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

Таблица-отношение может находиться в четвертой нор­мальной форме, но когда в ней имеется зависимость соединения, могут возникать аномалии при операциях добавления/уда­ления строк-кортежей. Для примера рассмотрим таблицу, при­веденную на рис. 3.9. Ключом таблицы является совокупность всех трех полей-атрибутов, так как сотрудник может входить в состав разных групп и участвовать в разных мероприятиях, каж­дое из которых может проводиться разными группами. В таб­лице нет детерминантов, отсутствуют функциональные и мно­гозначные зависимости, т. е. таблица находится в четвертой нор­мальной форме. Тем не менее в данной таблице нельзя удалить информацию по участию Бонда в мероприятии «Контакт», не удалив при этом вообще информацию о мистере Бонде в таб­лице. Нельзя также добавить строку-запись о вхождении мис­тера Бонда еще и в группу «F», если при этом он не участвовал ни в одном мероприятии.



^ Рис. 3.9 Пример декомпозиции таблицы из четвертой в пятую нормальную форму

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

Приведение таблицы в пятую нормальную форму осуще­ствляется путем ее декомпозиции сразу на несколько таблиц отношений. Если предположить, что в таблице, представлен­ной на рис. 3.9. имеется зависимость соединения по составным атрибутам «Фамилия»-«Группа», «Фамилия»-«Мероприятие», «Группа»-«Мероприятие»,* то, разбив таблицу на три проекции по соответствующим полям-атрибутам, можно удовлетво­рить требованиям пятой нормальной формы и устранить отме­ченные аномалии.

* Наличие зависимости соединения является нетривиальным предположением, основывающимся в большинстве случаев на эвристических соображениях, т.е. в дан­ном случае на уверенности, что при соединении трех таблиц «Фамилия»-«Группа», «Фамилия»-«Мероприятие» и «Группа»-«Мероприятие» не произойдет каких-либо потерь пли появления лишних данных относительно исходной таблицы.
Из-за нетривиальности зависимости соединения пятая нор­мальная форма практически не используется.

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

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

* В некоторых СУБД, как уже указывалось, каталог базы данных именуют системными таблицами.
Для повышения эффективности схемно-структурного про­ектирования банков данных на рынке программных средств СУБД появился специальный класс программ, называемых CASE-cucmeмами.* Наиболее известными из них являются Designer 2000 компании «Оrасlе», ErWin компании «LogicWorks», PowerBulder компании «PowerSoft». Такие системы предостав­ляют проектировщику банка данных средства концептуально­го проектирования баз данных на основе техники семантичес­кого моделирования. При этом широко используются средства визуализации определения и описания информационных объек­тов, связей и их атрибутов, что делает процесс проектирования максимально наглядным и позволяет проектировщику сосре­доточиваться на смысловом аспекте структуры банка данных. Разработанная таким образом концептуальная схема банка дан­ных транслируется CASE-системой в схему соответствующе­го реляционного банка, избавляя проектировщика от утомитель­ных процедур «ручного» перевода концептуальной (семанти­ческой) схемы в реляционную.

* Computer Aided Software Engineering—системы автоматизированного проек­тирования.
Тенденция расширения средств описания схем реляцион­ных банков данных в сторону оснащения их элементами се­мантического моделирования наблюдается и в самих СУБД. В некоторых СУБД имеются специальные инструменты визуаль­ного графического определения связей между таблицами и ог­раничений целостности по ним. Кроме того, появляются также специальные анализаторы структуры таблиц базы данных с точки зрения рациональности и дублирования данных, которые позволяют в некоторой степени автоматизировать рассмотрен­ные выше процессы нормализации таблиц.
^

Вопросы и упражнения


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

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

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

4. При концептуальном проектировании банка данных АИС, авто­матизирующей ведение Табеля рабочего времени сотрудников организации, выделены следующие объекты-сущности:



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

5. При проектировании таблицы «Преподаватели» выделены следу­ющие атрибуты — ФИО, Кафедра (Истории, Математики, Инфор­матики), Должность (Зав. кафедры, Профессор, Преподаватель, Ассистент), Ученая степень (Кандидат наук. Доктор наук). Уче­ное звание (Старший научный сотрудник, Доцент, Профессор, Ака­демик), Пед. стаж. Определите и обоснуйте для каждого атрибу­та тип поля и другие параметры (обязательность заполнения, словарно-списочный характер и тип словаря, индексируемость и тип индекса, возможные ограничения целостности данных). Вы­берите из имеющихся атрибутов или предложите дополнительно ключ таблицы.

6. При проектировании таблицы «Автомобили» базы данных «За­пасные части» выделены следующие атрибуты — Модель, Про­изводитель (ВАЗ, АЗЛК, ГАЗ, ИЖМаш, УАЗ), Категория (Легко­вой, Грузовой, Специальный), Грузоподъемность, Год начала производства, Год прекращения производства, Фото. Определите и обоснуйте для каждого атрибута тип поля и другие параметры (обязательность заполнения, словарно-списочный характер и тип словаря, индексируемость и тип индекса, возможные ограниче­ния целостности данных). Выберите из имеющихся атрибутов или предложите дополнительно ключ таблицы.

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

• «Сотрудник»— ^ Taб_№, ФИО, Должность, Подразделение;

• «Подразделение»—№№, Наименование, Руководитель;

• «Пропуск»— Ta6_№_comp., №_пропуска, Дни, Время, Кто подписал.

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

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

• «Подразделения» — №№, Наименование, Профиль (Произ­водственно-технологический, Сбытовой, Снабженческий, Организационно-управленческий);

• «Операции»—^ Код, Наименование, Описание;

• «Комплектующие» — Код, Наименование, Тип (Крепеж, Электрооборудование, Резинотехнические изделия), Количе­ство, Минимально необходимое количество на складе.

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

9. Приведите к первой нормальной форме следующую ненормали­зованную таблицу (в жирной рамке ключ таблицы):



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



11. Приведите к третьей нормальной форме следующие таблицы, на­ходящиеся во второй нормальной форме (в жирной рамке ключ таблицы):


1   ...   4   5   6   7   8   9   10   11   ...   23



Скачать файл (3043.3 kb.)

Поиск по сайту:  

© gendocs.ru
При копировании укажите ссылку.
обратиться к администрации