Банк данных

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

     2.1 Модели данных 

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

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

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

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

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

     Модели, основанные на языках разметки документов, связаны прежде всего со стандартным  общим языком разметки – SGML³, который был утвержден ISO в качестве стандарта еще в 80-х годах. Контроль за правильностью использования тегов осуществляется при помощи специального набора правил, называемых DTD-описаниями, которые используются программой клиента при разборе документа. Для каждого класса документов определяется свой набор правил, описывающих грамматику соответствующего языка разметки. С помощью SGML можно описывать структурированные данные, организовывать информацию, содержащуюся в документах, представлять эту информацию в некотором стандартизованном формате. Но ввиду некоторой своей сложности SGML использовался в основном для описания синтаксиса других языков (наиболее известным из которых является HTML), и немногие приложения работали с SGML-документами напрямую.

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

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

     XML (Extensible Markup Language) – это язык разметки, описывающий целый класс объектов данных, называемых XML-документами.(6) Он используется в качестве средства для описания грамматики других языков и контроля за правильностью составления документов. То есть сам по себе XML не содержит никаких тегов, предназначенных для разметки, он просто определяет порядок их создания.

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

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

     2.2 Автоматизированные банки данных 

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

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

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

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

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

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

         - решать вопросы, связанные с расширением БД в связи с изменением границ ПО;

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

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

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

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

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

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

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

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

     2.3 Архитектура БД 

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

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

     Рассмотрим  упрощенный вариант одной из возможных схем функционирования БД в составе АС. Основу СУБД составляют программы, реализующие все необходимые преобразования данных в соответствии с имеющимися в системе интерфейсами. Это преобразователи внутренней (Пр_ВнС), концептуальной (Пр_КС) и внешних (Пр_ВС) схем; преобразователи данных, реализующие отображения «внешний–концептуальный» (Пр_В-К), «концептуальный–внутренний» (Пр_К-Вн), «внутренний–память» (Пр_Вн-П). Таким образом, СУБД можно рассматривать как систему: 

     СУБД = {Пр_ВнС, Пр_КС, Пр_ВС, Пр_В-К, Пр_К-Вн, Пр_Вн-П}. 

     Словарь данных (СД) включает в свой состав в  минимальном варианте лишь описания схем данных по ПО: 

     СД = {ВнС, КС, {ВС_i, i = 1, n}}. 

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

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