книги / Структурный подход к организации баз данных

( камней из [ Желчного пузыря

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

Запись ХИРУРГ называется владельцем, а запись ОПЕРАЦИЯ — членом

этого набора.

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

На рис. 4.23 показаны примеры экземпляров наборов ПАЦИЕНТ- ПЕРЕНЕС-ОПЕРАЦИЮ и ОПЕРАЦИЯ-ПАЦИЕНТА.

4.5.2. Три дополнительных класса типов наборов

На рис. 4.24 показаны типы наборов, образованные типами запи­ сей ПАЦИЕНТ и ОПЕРАЦИЯ (первый класс).

Второй класс включает наборы, состоящие из трех или более записей (рис. 4.25). Такой набор называется многочленным. Записью-владельцем здесь является ПАЦИЕНТ, а записями-членами — ОПЕРАЦИЯ и ЗАБО­ ЛЕВАНИЕ.

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

4.5.3. Операции включения и удаления в сетевой модели данных

Включение. Допускается добавление новой записи ХИРУРГ в каче­

стве экземпляра владельца в экземпляр набора ОПЕРАЦИЯ-ПАЦИЕН­ ТА, в котором экземпляр ОПЕРАЦИЯ отсутствует. При этом вводятся сведения о хирурге, не прооперировавшем ни одного пациента. Аналогич­ ным образом можно вводить сведения о пациенте вне зависимости от сведений о хирурге.

Удаление. При удалении экземпляра владельца ХИРУРГ удаляются

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

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

4.5.4. Достоинства модели

Главными достоинствами сетевой модели данных являются:

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

•простота реализации часто встречающихся в реальном мире взаимо­ связей «многие ко многим».

Сетевая модель данных широко пропагандируется Рабочей группой

по базам данных Ассоциации КОДАСИЛ. Отчеты РГБД 1971 и 1978 гг. несомненно окажут Влияние на будущие национальные и международные стандарты баз данных.

4.5.5. Недостатки модели

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

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

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

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

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

5уз1ешз. Асаёепис-Ргезз.— А зиЬз1сПагу о! Нагсоиг! Вгасе ЛоуапоуюН РиЪНзНегз, 1977.

3.У е Н е г М. Рппар1ез о! Оа1а Вазе 5уз1ешз. Рарег ргезеп!её а! 1Не 1п1егпа1юпа1 СошриПпд Зутрозшт, Ье1де, Ве1&шт, АргП 1977.

4. С о ё ё Е. Р. А Не1аПопа1 Моёе1 о! Оа1а 1ог Ьагде ЗНагеё Па1а Вапкз. С оттитсаПопз о! 1Не АСМ, Уо1. 13 (Липе 6, 1970).

5.С о ё ё Е. Р. Риг1Нег ЫогшаНгаПоп о! 1Не Ре1аНопа1 Моёе1. Оа1а Вазе Зуз1ешз, Соигап! Сошри1ег Заепсе Зушроз1а 6, РгепНсе-НаИ, 1972.

6.В а с Ь г п а п С. \У. ТНе Рго^гашшег аз Ыау1&а1ог. Сошшипюа1юпз о! 1Не АСМ, Уо1. 16, N0. И (ЫоуешЬег 1973).

14.ТНе №Нопа1 Зутрозшт оп СотрагаНуе Ва{а Вазе Мапа^етеп! 5уз1етз, Уо1 I,

Аёуапсеё Мапа&етеп! НезеагсН 1п1егпаНопа1, 1пс., (Липе 26—28, 1978).

Г л а в а 5

ПРОЕКТИРОВАНИЕ БАЗЫ ДАННЫХ (КОНЦЕПТУАЛЬНАЯ МОДЕЛЬ ПРЕДМЕТНОЙ ОБЛАСТИ)

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

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

Проектирование концептуальной модели предметной области

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

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

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

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

5.1. АНАЛИЗ ДАННЫХ

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

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

и эксплуатационного). Причем на различных уровнях данные могут об­ рабатываться или накапливаться. Затем АБД предстоит проанализиро­ вать все направления использования данных на предприятии.

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

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

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

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

Содержание анкет

1. И м я и описание объекта данны х. Указываются основное имя и

синонимы. Примеры: «Счета», «Журнал регистрации продукции», «Форма учета счетов». Дается вербальное описание смыслового содержания имени, даже если его смысл представляется очевидным. В общих чертах описывается функциональное назначение и использование объекта в функ­

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

2. Элементы данны х. Для каждого элементарного данного, входя­ щего в конкретный объект, указывается:

а) его имя и описание. Перечисляются имена, акронимы и дается их расшифровка. Приводится полное вербальное описание элемента; б) источник. Перечисляются источники элемента в структуре пред­

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

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

Опись

товаров

Рис. 5.1. АБД должен разработать графическую схему объектов и элементов данных, содержащую:

1)функциональные источники данных;

2)функции получения или применения данных

данных на предприятии.

После этого АБД может приступить к разработке модели данных (концептуальной модели базы данных).

5.1.2. Сбор информации о данных для перспективных приложений

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