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

должны обладать широкими возможностями выборки данных и подготовки отчетов. При этом должна гарантироваться обработка как регламентных, так и произвольных запросов. Отчеты могут содержать:

•перечни элементов в алфавитном или любом другом порядке;

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

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

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

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

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

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

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

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

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

тирования, внесения изменений, реструктуризации баз данных, генерации отчетов и т. д.

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

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

Идеальный словарь данных должен:

1) поддерживать концептуальную, логическую, внутреннюю и внеш­ ние модели;

2)быть интегрирован с СУБД;

3)поддерживать различные версии хранимых описаний (тестовые, рабочие);

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

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

рирован с СУБД.

3.2.СТРАТЕГИЯ РЕАЛИЗАЦИИ СЛОВАРЯ ДАННЫХ

Внастоящее время распространены системы словаря данных двух ти­

пов. К системам первого типа относятся независимые словари данных,, предназначенные для использования с различными СУБД. Системы второ­

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

3;2.1. Экономическая целесообразность

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

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

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

базы данных словаря в худшем случае будет равна затратам на ее ведение в отсутствие системы словаря данных.

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

Рассмотрим теперь выгоды, которые может принести введение словаря данных.

Выгоды.

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

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

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

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

2)появляется возможность накапливать более полную информацию

оданных и лучше ее систематизировать;

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

4)с помощью таблиц соответствия быстрее реализуются изменения базы данных;

5)расширяются возможности регистрации доступа к данным;

6)упрощается контроль доступа к данным, так как информация о ба­

зе данных и ее использовании хранится централизованно.

Стоимость реализации систем с базой данных и словарем •данных, в которую входит стоимость накопления и хранения информации об элементах данных, их взаимосвязях и т. д., превышает стоимость создания систем с базой данных без словаря. Однако, если'в системах со словарем стоимость внесения изменений со временем уменьшается, то в системах

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

3.2.2. Условия применения

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

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

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

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

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

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

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

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

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

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

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

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

3.2.3. Рекомендации по определению данных

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

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

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

•Выводимый элемент данных — элемент, значение которого получается в результате вычислений с участием значений других элементов дан­

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

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

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

•Описание концептуальной модели. Модель описывает объекты пред­

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

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

•Описание внешних моделей. Внешняя модель описывает представле­ ние, используемое прикладной программой, т. е. ее объекты и взаимо­ связи.

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

Кроме приведенных выше основных элементов, в базе данных должны содержаться следующие описания взаимосвязей между ними:

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

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

1. Использовать точные и недвусмысленные определения.

Избегать таких фраз, как «ряд сотрудников», «отдельные изделия». Употреблять конкретные фразы, например «уволенные сотрудники», «бумажные изделия».

2.Применять сокращения только при необходимости, причем по воз­ можности стандартные.

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

4.Указывать единицы измерений (тыс. дол., м, см и т. п.) или перио­ дичность изменения (раз в год, раз в день и т. п.) по возможности для всех числовых значений.

5.Ссылаться на источники данных. В описании должны также указы­

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

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

ЛИ Т Е Р А Т У Р А

ЫаВопа1 Вигеаи о! 31апс1агс15, 5рес1а1 РиЬНсаПоп 500—3, 11.5. Оераг1теп1 о! Соттегсе, ШазЫп^1оп, О.С. 20234.

Ч АСТ Ь 2

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

Г л а в а 4

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

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

ных систем.

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

вчасти 3 этой книги в контексте с соответствующей СУБД.

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

4.1.ЧТО ТАКОЕ МОДЕЛЬ ДАННЫХ?

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

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

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

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

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

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

4.2. ВЗАИМОСВЯЗИ В МОДЕЛИ ДАННЫХ

Взаимосвязь выражает отображение или связь между двумя множест­ вами данных. Различают взаимосвязи типа «один к одному», «один ко многим» и «многие ко многим». Ниже приводятся примеры, иллюстри­ рующие эти взаимосвязи.

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

и его адрес. Таким образом, атрибутами объекта ПАЦИЕНТ являются «номер пациента», «имя пациента» и «адрес пациента».

Следующий представляющий для нас интерес объект — ХИРУРГ. Этот объект имеет атрибуты «номер патента хирурга» и «имя хирурга».

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

Третий рассматриваемый объект — КОЙКА. Его атрибутами являют­ ся «номер палаты» и «номер койки».

4.2.1. Взаимосвязь «один к одно'му» (между двумя типами объектов)

В определенный момент времени одному пациенту выделяется одна кой­ ка. Между объектами ПАЦИЕНТ и КОЙКА устанавливается взаимосвязь «один к одному», обозначаемая одинарными стрелками (рис. 4.1).

4.2.2. Взаимосвязь «один ко многим» (между двумя типами объектов)

В данный момент времени в одну палату можно поместить нуль, одного или нескольких пациентов, причем каждый пациент помещается только в одну палату. Взаимосвязь «один ко многим» можно обозначить с помощью одинарной стрелки в направлении к «одному» и двойной стрелки в направлении ко «многим» (рис. 4.1).

4.2.3. Взаимосвязь «многие ко многим» (между двумя типами объектов)

В нашем примере каждый хирург может оперировать нескольких пациентов. С другой стороны, находясь в госпитале в различное время, каждый пациент может быть прооперирован несколькими хирургами. Между объектами ПАЦИЕНТ и ХИРУРГ существует взаимосвязь «многие ко многим». Мы обозначаем такую взаимосвязь двойными стрелками (рис. 4.1).

один или несколько пациентов, но любой пациент может быть приписан только к одной палате; 3) «многие ко многим» — хирург может прооперировать нескольких пациентов или пациент,

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

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

Наряду с этим существуют взаимосвязи между атрибутами объекта. Здесь также различают взаимосвязи типа «один к одному», «один ко многим» и «многие ко многим».