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

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

..pdf
Скачиваний:
4
Добавлен:
12.11.2023
Размер:
14.79 Mб
Скачать

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

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

Определяет элементы данных и их взаимосвязи.

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

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

С помощью пользователей определяет синонимы элементов данных.

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

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

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

2, 3, 4. Материализация, конвертирование и интеграция.

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

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

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

5. Эксплуатация.

• Проверяет, отвечают ли прикладные программы требованиям соблю­ дения безопасности, секретности и разграничения доступа.

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

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

6. Развитие, совершенствование и сопровождение.

Оценивает влияние изменений на прикладные программы и их взаимо­ действие.

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

Контролирует ввод новых или измененных элементов данных в сло­ варь данных.

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

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

АБД с представителями этих групп также входит в функции библиотекаря. Кроме того, библиотекарь имеет следующие обязанности:

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

• Ведет запись изменений в системе словаря/справочника данных.

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

2, 3, 4, 5, 6. Материализация, конвертирование, интеграция, эксплуатация,, развитие, совершенствование и сопровождение.

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

Ведет запись результатов работы механизма ревизии.

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

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

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

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

Определяет уровни разграничения доступа для различных типов запросов.

Устанавливает форматы запросов.

Совместно с экспертами по системным вопросам разрабатывает запросы, отвечающие эксплуатационным требованиям.

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

2, 3, 4, 5, 6. Материализация, конвертирование, интеграция, эксплуата­ ция, развитие, совершенствование и сопровождение.

Отслеживает эксплуатационные характеристики запросов.

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

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

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

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

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

Л И Т Е Р А Т У Р А

1. Ь у о п ЛоЬп К. ТЬе Оа1аЪазе А(1ппшз1га1ог. А \УПеу-1п1;егзс1епсе РиЬНсаПоп, а Лшзюп о! ЛоЬп \УПеу & 5опз, Ые\у Уогк*

2.ТЬе Оа1а Вазе Ас1гшш51га1ог. РгерагеЛ Ьу 1Ье шешЬегз о! 1Ье Оа1а Вазе Аёгшшз^гаНоп Рго]ес1 о! 1Ье 1п1огта1юп Мападешеп! Огоир, о! 1Ье 1п1огта1юп

5уз1етз 01У1зюп, о! 1Ье (Ш Ш Е

1п1егпаИопа1 СогрогаНоп,

ЫоуетЪег 3, 1972.

3. О е г г й з е п

РоЪ,

М о г ^ а п

НоугагЛ

апЛ

2 1 з т а п

МюЬаеТ Оп зо те ,Ме1псз

1ог

Оа1аЬазез,

ог

ШЬа! 1з а

Уегу

Ьагде

Оа1аЬазе?.

АСМ 5ЮМСЮ Р Е С 0 1 Ф ,

Уо1.

9, N0. 1 (Липе

1977).

 

 

 

 

Г л а в а 3

СЛОВАРЬ ДАННЫХ

3.1. ЧТО ТАКОЕ СЛОВАРЬ ДАННЫХ?

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

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

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

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

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

3.1.1. Назначение

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

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

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

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

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

Рассмотрим следующий пример. В банковской системе одним из цент­ ральных элементов данных является «остаток». Каков остаток на данном счете? Для большинства неспециалистов ответ очевиден. Однако в главном файле счетов соответствующей системы в записи по одному счету может храниться до двадцати пяти полей, в именах которых присутствует термин «остаток». Поэтому важно, чтобы и пользователь и разработчик пред­ ставляли себе, какой именно остаток имеется в виду: «остаток на счете на начало дня», «остаток на счете на конец вчерашнего дня», «фактический остаток» или «остаток на сберегательной книжке». «Остаток на сберега­ тельной книжке» увеличивается сразу после того, как клиент делает вклад, но если вклад сделан с помощью чека, то «фактический остаток» увели­ чится только после оплаты чека. На самом деле существует гораздо больше различных полей «остаток». Словарь данных может использовать­ ся для централизованного накопления информации обо всех элементах* данных и для обеспечения эффективного взаимодействия между всеми участниками проекта.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Преимущества интегрированной системы словаря данных:

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

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

кбазе данных для сбора статистических данных с целью повышения производительности системы;

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

Преимущества независимого словаря данных:

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

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

файлов — как в независимом словаре.

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

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

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

3.1.3. Интерфейсы

Проанализируем интерфейсы словаря данных в системе с единствен­ ной СУБД (рис. 3.1).

Рис. 3.1. Интерфейсы словаря данных в «идеальной» системе с базой данных. Существуют два типа интерфейсов:

1)с людьми, вовлеченными в систему: АБД, системными программистами, прикладными программистами, руководителями, конечными пользователями и ревизорами;

2)с программными средствами: СУБД, компиляторами, операционной системой" и генера­ торами отчетов

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

Отчеты могут отражать следующие аспекты:

элементы данных и объекты;

взаимосвязи элементов данных и объектов;

ответственность пользователей за правильность данных;

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

правила разграничения доступа;

отчеты ревизии;

регламентированные сводные отчеты;

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

отчеты, содержащие таблицы соответствия;

отчеты об изменениях;

отчеты об ошибках.

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

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

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

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

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

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

3.1.4. Идеальный словарь данных. Требования и организация

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

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

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

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

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

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

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

Соседние файлы в папке книги