ТЕМА 1. Політологія як наука 2 страница

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

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

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

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

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

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

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

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

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

Функции администратора базы данных:

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

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

- решать вопросы, связанные с расширением базы данных в связи изменением границ предметной области;

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

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

- следить за тем, чтобы банк данных отвечал заданным требованиям по производительности, т.е. чтобы обработка запросов выполнялась за приемлемое время;

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

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

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

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

Рис. 1.6.

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

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

Архитектура банка данных.

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

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

"Модель<->физическая база данных".

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

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

"Модель<->внутренняя модель<->физическая база данных".

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

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

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

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

"Внешняя модель <-> концептуальная модель <-> внутренняя модель<->физическая база данных".

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

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

Пользователи

П1

П2

Пn

Рис. 1.8. Трехуровневая архитектура банка данных.

1) прикладная программа обращается к СУБД с запросом на чтение записи внешней модели данных;

2) СУБД, используя схемы внешней модели данных и концептуальной модели данных и описание отображения внешней модели данных на концептуальную модель данных, определяет, какие записи концептуальной модели необходимы для формирования записи внешней модели;

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

4) СУБД выдает операционной системе запрос на считывание в свою буферную область памяти необходимых записей из физической базы данных;

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

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

7) СУБД пересылает сформированную запись внешней модели данных в рабочую область ввода-вывода прикладной программы;

8) СУБД передает в прикладную программу свои сообщения и сообщения операционной системы о результатах выполнения запроса;

9) прикладная программа обрабатывает запись, поступившую в ее рабочую область ввода-вывода.

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

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

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

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

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

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

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

ЭТАПЫ ПРОЕКТИРОВАНИЯ БАЗЫ ДАННЫХ.

Процесс проектирования базы данных представляет собой сложный процесс проектирования отображения:

"Описание предметной области"<-->"схема внутренней модели базы данных".

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

инфологическое

Выбор СУБД

датологическое

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

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

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

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

ИНФОЛОГИЧЕСКИЙ ПОДХОД К ПРОЕКТИРОВАНИЮ ИНФОРМАЦИОННЫХ СИСТЕМ.

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

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

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

1) явления реального мира;

2) информацию об этих явлениях;

3) представление этой информации посредством данных.

4) В инфологическом подходе выделены следующие три сферы;

5) реальный мир или объектная система;

6) информационная сфера;

7) датологическая сфера.

Объектная система имеет следующие основные составляющие: объект, свойство, связь (или объектное отношение), время.

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

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

Свойства объекта могут не зависеть от его связей (объектных отношений) с другими, т.е. являются локальными. Если свойства объекта зависят от связей с другими объектами, то называются реляционными.

Связь между объектами в зависимости от числа входящих в нее объектов характеризуется степенью: п.=2,3,...,к (бинарная, тернарная,..., k-арная).

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

МОДЕЛЬ "СУЩНОСТЬ-СВЯЗЬ"

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

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

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

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