Организация Баз Данных

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

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

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

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

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

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

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

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

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

Базы и банки данных являются одними из основных компонентов автоматизированных систем различных уровней и типов (АСУП – автоматизированных систем управления предприятиями, АСУ ТП –автоматизированных систем управления технологическими процессами, ОАСУ – отраслевых автоматизированных систем управления, АСНИ – автоматизированных систем управления научными исследованиями, САПР – систем автоматизации проектирования и т.п.). Они создаются для многих сфер и отраслей народного хозяйства: планирования, учета, управлениями предприятиями, статистики, здравоохранения и др.

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

Информация и данные.

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

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

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

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

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

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

На этапе инфологического проектирования информационной системы должны быть решены вопросы:

1) о каких объектах или явлениях реального мира требуется накапливать и обрабатывать информацию о системе;

2) какие их основные характеристики и взаимосвязи между собой будут учитываться;

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

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

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

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

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

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

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

Предпосылки создания банков данных.

Создание банков данных вызвано следующими основными предпосылками:

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

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

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

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

Роль и место банков данных в автоматизированных системах.

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

Банк данных выступает в роли специальной обеспечивающей подсистемы в составе автоматизированных систем (АС). Приведенное опреде-

ДРУГИЕ ИСТОЧНИКИ ИНФОРМАЦИИ

БАНК ДАННЫХ

Рис. Банк данных в составе АС

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сформулируем требования к банку данных. Банк должен:

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

2) обеспечивать заданный уровень достоверности хранимой информации и ее непротиворечивость;

3) обеспечивать доступ к данным только пользователей с соответствующими полномочиями;

4) обеспечивать возможность поиска информации по произвольной группе признаков;

5) удовлетворять заданным требованиям производительности при обработке запросов;

6) иметь возможность реорганизации и расширения при изменении границ предметной области;

7) обеспечивать выдачу информации пользователям в различной форме;

8) обеспечивать простоту и удобство обращения внешних пользователей за информацией;

9) обеспечивать возможность одновременного обслуживания большого числа внешних пользователей и т.д.

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

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

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

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

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

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

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

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

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

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

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

Банк данных как автоматизированная система.

Банк данных включает следующие основные компоненты: базу данных (БД); систему управления базой данных (СУБД); администратора базы данных (АБД); словарь данных; вычислительную систему; обслуживающий персонал (два последних компонента здесь не рассматриваются).

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

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

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

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

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

1) произвести выборку из базы данных конкретного данного, значение которого удовлетворяет заданным условиям;

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

3) найти в базе позицию данного и поместить туда его новое значение либо удалить данное и т.д.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 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 тыс. Каждый рассматриваемый в модели тип сущности должен быть поименован.

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

Атрибут - это поименованная характеристика сущности, которая принимает значения от некоторого множества значений. В модели атрибут выступает в качестве средства, с помощью которого моделируются свойства сущностей. Например, для описания свойств сущности КНИГА можно использовать атрибуты НАЗВАНИЕ, ФАМИЛИЯ-АВТОРА, ГОД-ИЗДАНИЯ. Чтобы задать атрибут в модели, необходимо присвоить ему наименование, привести смысловое описание атрибута, определить множество его допустимых значений и указать, для чего он используется. Если сущность - сотрудник, то его атрибуты - Ф.И.О., должность, оклад, стаж работы, телефон.

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

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

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

Тип А Тип В

Рис. 2.1. Отношение 1:1.

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

Отображение 1:М (связь один-ко-многим). С помощью отображения 1:М (рис. 2.2) определяется тип связи

Тип А Тип В

Рис. 2.2. Отображение 1:М.

между типами сущностей А и В, когда одному экземпляру сущности А может соответствовать 0,1 или несколько экземпляров сущности В, однако каждому экземпляру сущности В соответствует только один экземпляр сущности А. Это означает, что с одним экземпляром сущности А может быть связано либо несколько экземпляров сущности В, либо один, либо ни одного (например: торговый агент обслуживает более одного покупателя, но каждый покупатель обслуживается только одним торговым агентом). Но при этом каждый экземпляр сущности В связан только с одним экземпляром сущности А, т.е. идентификация экземпляров при отображении 1:М уникальна только в направлении от В к А.

Отображение М:1 (связь многие-к-одному). Это отображение является обратным отображению 1:М (рис. 2.3).

Рис. 2.3. Отображение М:1.