Базы данных и система управления базами данных

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

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

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

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

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

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

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

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

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

3.2 Тенденции в мире систем управления базами данных

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

• Реляционные системы

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

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

• Использование мультипроцессорных организаций

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

Однако с появлением на рынке мультипроцессорных симметричных аппаратных архитектур, производители  СУБД были вынуждены пересмотреть организацию своих серверов, допустив в них внутреннюю параллельность. Естественно, это требует очень основательного перепроектирования системы с ее существенным усложнением. Заметим, что в большинстве случаев компании пошли на это после появления в ОС UNIX механизма "легковесных" процессов (threads).

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

• Интеграция

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

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

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

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

• Активные базы данных
• По определению БД называется активной, если СУБД по отношению к ней выполняет не только те действия, которые явно указывает пользователь, но и дополнительные действия в соответствии с правилами, заложенными в саму БД.
• Легко видеть, что основа этой идеи содержалась в языке SQL времени System R. На самом деле, что есть определение триггера или условного воздействия как не введение в БД правила, в соответствии с которым СУБД должна производить дополнительные действия? Плохо лишь то, что на самом деле триггеры не были полностью реализованы ни в одной из известных систем, даже и в System R. И это не случайно, потому что реализация такого аппарата в СУБД очень сложна, накладна и не полностью понятна.
• Дедуктивные базы данных

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

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

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

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

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

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

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

• Темпоральные базы данных

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