база данные управление информационный
Поле - это один элемент записи, в котором хранится конкретное значение атрибута.
Ключевым элементом данных (ключом) называется такой атрибут, по значению которого можно определить значения других атрибутов.
Первичный ключ - это атрибут или группа атрибутов, которые однозначно определяют каждую запись в таблице. Первичный ключ всегда должен быть уникальным, то есть его значения не должны повторяться.
Альтернативный ключ - это отличные от первичного ключа атрибут или группа атрибутов, которые также однозначно определяют каждую запись в таблице. Например: сущность «Служащий» имеет атрибуты: идентификатор служащего (табельный номер), фамилия, имя, отчество, должность, оклад. Первичным ключом назначим поле «Идентификатор служащего». Альтернативным ключом назначим группу полей «Фамилия», «Имя», «Отчество» (только в том случае, если нет тройных тезок)
Связь - это функциональная зависимость между сущностями. Если между некоторыми сущностями существует связь, то атрибуты из одной сущности ссылаются или некоторым образом связаны с атрибутами другой сущности. Связи описываются пятью основными характеристиками:
тип связи - это идентифицирующая характеристика, когда дочерняя сущность однозначно определяется через её связь с родительскою сущностью. Атрибуты первичного ключа родительской сущности входят как не ключевые атрибуты в дочернюю сущность;
родительская сущность;
дочерняя (зависимая) сущность;
мощность связи - это отношение количества родительских сущностей к соответствующему количеству дочерних сущностей.
Хранимая процедура - это приложение (программа), объединяющая запросы пользователя и процедурную логику и хранящаяся в базе данных.
Правило - это логическое условие, определяющее значение одного атрибута в зависимости от значения другого атрибута (или группы атрибутов).
С помощью правила контролируется достоверность вводимой информации.
Ограничение - это логическое условие, накладывающее ограничение (интервал допустимых значений) на значение атрибута.[10., стр. 400]
Триггер - это предварительное определённое действие или последовательность действий, автоматически осуществляемых при выполнении операций обновления, добавления или удаления данных. Триггер выполняется автоматически при выполнении указанных действий и не может быть отключён.
Триггер включается в себя:
правила или ограничения;
событие, которое требует проверки правил и ограничений;
предусмотренные действия, которые выполняются с помощью процедуры или последовательности процедур.
Ссылочная целостность - это обеспечение непротиворечивости функциональных взаимосвязей между сущностями. Непротиворечивость
выполняется путём соответствия значений первичного ключа родительской сущности значениям внешнего (любого не первичного) ключа дочерней сущности. Ссылочная целостность может контролироваться при всех операциях, изменяющих информацию в базе данных, при этом возможны следующие варианты обработки событий:
отсутствие проверки;
проверка допустимости;
запрет операции;
каскадное выполнение операций обновления или удаления данных одновременно в нескольких связанных таблицах;
установка пустого значения по умолчанию.
Нормализация отношений - это процесс построения оптимальной структуры таблиц и связей в реляционной БД. В процессе нормализации данные группируются в таблицы, представляющие объекты и их взаимосвязи.
Словарь данных - это централизованное хранилище сведений о сущностях, взаимосвязях между сущностями, их источниках, значениях, использовании и форматах представления.[1, стр.125]
.2 Свойства полей базы данных
Поля базы данных не просто определяют структуру базы - они ещё определяют групповые свойства данных, записываемых в ячейки, принадлежащие каждому из полей. Ниже перечислены основные свойства полей таблиц баз данных на примере СУБД Microsoft Access.
Имя поля - определяет, как следует обращаться к данным этого поля при автоматических операциях с базой (по умолчанию имена полей используются в качестве заголовков столбцов таблиц).
Тип поля - определяет тип данных, которые могут содержать в данном поле.
Размер поля - определяет предельную длину (в символах) данных, которые могут размещаться в данном поле.
Формат поля - определяет способ форматирования данных в ячейках, принадлежащих полю.
Маска ввода - определяет форму, в которой вводятся данные поля (средство автоматизации ввода данных).
Подпись - определяет заголовок столбца таблицы для данного поля (если подпись не указана, то в качестве заголовка столбца используется свойство Имя поля).
Значение по умолчанию - это значение, которое вводится в ячейки поля автоматически (средство автоматизации ввода данных).
Условие на значение - ограничение, используемое для проверки правильности ввода данных (средство автоматизации ввода, которое используется, как правило, для данных, имеющих числовой тип, денежный тип или тип даты).
Сообщение об ошибке - текстовое сообщение, которое выдается автоматически при попытке ввода в поле ошибочных данных.
Обязательное поле - свойство, определяющее обязательность заполнения данного поля при наполнении базы. Пустые строки - свойство, разрешающее ввод пустых строковых данных (от свойства Обязательное поле отличается тем, что относится не ко всем типам данных, а лишь к некоторым, например к текстовым).
Индексированное поле - если поле обладает этим свойством, все операции, связанные с поиском или сортировкой записей по значению, хранящемуся в данном поле, существенно ускоряются. Кроме того, для индексированных полей можно сделать так, что значение в записях будут проверяться по этому полю на наличие повторов, что позволяет автоматически исключить дублирование данных. Поскольку в разных полях могут содержаться данные разного типа, то и свойства у полей могут различаться в зависимости от типа данных. Так, например, список вышеуказанных свойств полей относится в основном к полям текстового типа. Поля других типов могут иметь или не иметь эти свойства, но могут добавлять к ним и свои. Например, для данных, представляющих действительные числа, важным свойством является количество знаков после десятичной запятой. С другой стороны, для полей, используемых для хранения рисунков, звукозаписей, видео клипов и других объектов OLE, большинство вышеуказанных свойств не имеют смысла.[7., стр. 52]
1.3 Типы данных
Таблицы баз данных, как правило, допускают работу с гораздо большим количеством разных типов данных. Так, например, базы данных Microsoft Access работают со следующими типами данных.
Текстовый - тип данных, используемый для хранения обычного неформатированного текста ограниченного размера (до 255 символов).
Числовой - тип данных для хранения действительных чисел.
Дата/время - тип данных для хранения календарных дат и текущего времени.
Денежный - тип данных для хранения денежных сумм. Теоретически, для их записи можно было бы пользоваться и полями числового типа, но для денежных сумм есть некоторые особенности (например, связанные с правилами округления), которые делают более удобным использование специального типа данных, а не настройку числового типа.
Счетчик - специальный тип данных для уникальных (не повторяющихся в поле) натуральных чисел с автоматическим наращиванием. Естественное использование - для порядковой нумерации записей.
Логический - тип для хранения логических данных (могут принимать только два значения, например Да или Нет).
Гиперссылка - специальное поле для хранения адресов URL Web-объектов Интернета. При щелчке на ссылке автоматически происходит запуск браузера и воспроизведение объекта в его окне.
Мастер подстановок - это не специальный тип данных. Это объект, настройкой которого можно автоматизировать ввод данных в поле так, чтобы не вводить их вручную, а выбирать их из раскрывающегося списка.
1.4 Безопасность баз данных
Базы данных - это тоже файлы, но работа с ними отличается от работы с файлами других типов, создаваемых прочими приложениями. Выше мы видели, что всю работу по обслуживанию файловой структуры берет на себя операционная система. Для базы данных предъявляются особые требования с точки зрения безопасности, поэтому в них реализован другой подход к сохранению данных.
Базы данных - это особые структуры. Информация, которая в них содержится, очень часто имеет общественную ценность. Нередко с одной и той же базой работают тысячи людей по всей стране. От информации, которая содержится в некоторых базах, может зависеть благополучие множества людей. Поэтому целостность содержимого базы не может и не должна зависеть ни от конкретных действий некоего пользователя, забывшего сохранить файлы перед выключением компьютера, ни от перебоев в электросети.
Проблема безопасности баз данных решается тем, что в СУБД для сохранения информации используется двойной подход. В части операций, как обычно, участвует операционная система компьютера, но некоторые операции сохранения происходят в обход операционной системы.[12., стр. 12]
Глава 2. Системы управления базами данных
.1 Классификация СУБД
Системой управления БД называют программную систему предназначенной для создания на ЭВМ общей БД, используемой для решения множества задач.
Подобные системы служат для поддержания баз данных в актуальном состоянии и обеспечивают эффективный доступ пользователей к содержащимся в ней данным в рамках предоставленных пользователем полномочий. СУБД предназначена для централизованного управления базой данных в интересах всех работающих в этой системе.
По степени универсальности различают две степени СУБД:
− системы общего назначения;
− специализированные системы.
СУБД общего назначения не ориентированные на какую-либо предметную область или на информационную потребности какой-либо группы пользователей. СУБД общего назначения это сложные программные комплексы предназначены для выполнения всей совокупности функций, связанных с созданием и эксплуатацией БД.
Специализированные СУБД создаются редких случаях при невозможности или нецелесообразности использования СУБД общего назначения.
Основные характеристики СУБД:
Основными характеристиками СУБД являются:
) Производительность;
) Обеспечение целостности данных на уровне БД;
) Обеспечение безопасности;
) Работа в многопользовательских средах;
) Импорт, экспорт;
) Доступ к данным посредством языка SQL;
) Возможности запросов и инструментальные средства разработки прикладных программ.
Производительность СУБД оценивается:
− временем выполнения запроса;
− скоростью поиска информации в неиндексированных полях;
− временем выполнения операций импортирования базы данных из других форматов;
− скоростью создания индексов и выполнения таких массовых операций как обновление, вставка, удаление данных;
− максимальным числом параллельных обращений к данным в многопользовательском режиме;
− временем генерации отчетов.
На производительность СУБД оказывают влияние два фактора:
СУБД, которые следят за соблюдением целостности данных, несут дополнительную нагрузку, которую не испытывают другие программы;
производительность приложений сильно зависит от правильного проектирования и построения базы данных.
Обеспечение целостности данных на уровне БД:
Эта характеристика подразумевает наличие средств позволяющих удостовериться, что информация в БД всегда остается корректной и полной.
Должны быть установлены правила целостности, и они должны храниться вместе с базой данных и соблюдаться на глобальном уровне. Целостность данных должна обеспечивать независимо от того, каким образом данные заполняются в память.
К средствам обеспечения целостности данных на уровне СУБД относятся:
− встроенные средства для назначения первичного ключа, в том числе средства для работы с типом полей с автоматическими приращением, когда СУБД самостоятельно присваивает новые уникальные значения;
− средства поддержания ссылочной целостности, которые обеспечивают запись информации о связях таблиц и автоматически пресекают любую операцию приводящую к нарушению ссылочной целостности.
Работа в многопользовательских средах:
Практически все рассматриваемые СУБД предназначены для работы в многопользовательских средах, но обладают для этого различными возможностями. Обработка данных в многопользовательских средах предполагает выполнение программным продуктом следующих функций:
− блокировку БД, файла, записи, поля;
− идентификацию станции, установившей блокировку;
− обновление информации после модификации;
− контроль за временем и повторение обращений;
− обработка транзакций;
− работу с сетевыми системами.
Импорт, экспорт:
Эта характеристика отражает:
− возможность обработки СУБД информации, подготовленной другими программными средствами;
− возможность использования другими программами данных сформулированные средствами рассматриваемые СУБД.
Доступ к данным посредством языка SQL:
Язык запросов SQL реализован в целом ряде популярных СУБД для различных типов ЭВМ типа как базовой, либо как альтернативной. В силу своего широкого использования является международным стандартом языка запроса. Язык SQL предоставляет развитые возможности как конечным пользователям, так и специалистам в области обработки данных.
СУБД имеет доступ к данным SQL в следующих случаях:
− БД совместима с ОDВС (Open Database Connectivity - открытое соединение БД);
− реализована естественной поддержкой SQL-баз данных;
− возможна реализация SQL запросов локальных данных.[13., стр. 98]
Многие СУБД могут «прозрачно» подключаться к входным SQL-подсистемам с помощью ODBC или драйверов, являющихся их частью, поэтому существует возможность создания прикладных программ для них.
Некоторые программные продукты совместимы также с SQL при обработке интерактивных запросов на получение данных, находящихся на сервере или на рабочем месте.2.0 и Paradox for Windows работают с источниками SQL-данных, совместимых с системой ODBC.Pro (for Dos и for Windows) поставляются с дополнительными библиотеками, которые обеспечивают доступ к SQL-базам данных, способным работать совместно с системой ODBC, но эта возможность менее интегрирована, чем средства первичного ввода информации в Access и Paradox for Windows. Можно напрямую управлять базами данных Access с помощью языка SQL и передавать сквозные SQL-запросы совместимым со спецификацией ODBC SQL-базам данных, таким, как MS SQL Server и Oracle, так что Access способна служить средством разработки масштабируемых систем клиент-сервер.
Возможности запросов и инструментальные средства разработки прикладных программ:
СУБД ориентированные на разработчика обладает развитыми средствами для создания приложения. К элементам инструментария разработки приложения можно отнести :
− мощные языки программирования;
− средства реализации меню, экранных форм, ввода вывода данных и генерации отчетов;
− средства генерации приложений (прикладных программ);
− генерацию исполнимых файлов;
Языковые средства используются для выполнения двух основных функций:
− описание представления базы данных;
− выполнение операций манипулирования данными.
Первая из этих функций используется языком описания данных (ЯОД).
Описание БД средствами языка описание данных называется схемой базы данных. Оно включает описание структуры БД и налагаемых на нее ограничений целостности в рамках тех правил, которые регламентированы моделью данных используемой СУБД. ЯОД не всегда синтаксически оформляется в виде самостоятельного языка. Он может быть составной частью единого языка данных, сочетающего возможности определения данных и манипулирования данными. Язык манипулирования данными (ЯМД) позволяет запрашивать предусмотренные в системе операции над данными из базы данных. Обзор современных систем управления базами данных:
СУБД Ассеss проста в изучении и эксплуатации и поэтому доступна для пользователей с низкой квалификацией, снабжена обширными средствами по созданию отчетов различной степени сложности, создаваемых на основе таблиц различных форматов. Как правило, Ассеss используется для создания личных баз данных (справочники, записные книжки и т. д.), не имеющих коммерческого распространения. СУБД SQL-Server обеспечивает высокую степень защиты данных, как от случайных потерь, так и от несанкционированного доступа, обладает развитыми средствами обработки данных и хорошим быстродействием. SQL-Server предназначен для хранения большого объема данных. Visual Basic не требовательна к техническим характеристикам персонального компьютера. Так как Visual Basic является продуктом фирмы Мicrosoft, то легко интегрируется со всеми приложениями Мicrosoft Оffiсе и многими приложениями, интегрированными в WINDOWS. Предназначен Visual Basic для создания небольших приложений, в которых не требуются большие вычисления и серьезная обработка данных. Visual С++ самая скоростная среда программирования, обеспечивающая выполнение расчетов и обработку данных любой сложности, совместима практически со всеми известными приложениями. СУБД Visual Fox Pro предназначена для создания приложений базданных объема предприятия, обладает хорошим быстродействием и устанавливается на различные платформы.[5., стр. 56]
.2 Постреляционные базы данных
Рассмотрим основные направления в области исследований и разработок систем управления - так называемых постреляционных баз данных.
Первое направление связано с максимальным использованием существующих технологий управления и организации реляционных СУБД с дальнейшим совершенствованием систем управления внешней памятью.
Второе направление связано с созданием генераторов системы управления в виде наборов модулей со стандартизованными интерфейсами.
Третье направление развития СУБД по сути является синтезом первых двух направлений. СУБД проектируется как некоторый интерпретатор системы правил и набор модулей-действий, вызываемых в соответствии с этими правилами. Для таких систем разрабатываются специальные языки формирования правил. Можно сказать, что СУБД следующего поколения - это прямые наследники реляционных систем. Однако реляционные СУБД стали применять не только в сфере бизнеса для управленческих задач, но и в сфере промышленного производства (CALS-технологии). Применение реляционных баз данных оказалось весьма эффективным для разработки систематизированного проектирования технологических процессов (САПРТП), разработке экспертных систем и других задачах управления и технической подготовки производства. Такие системы обычно оперируют сложно структурированными объектами - некоторым комплексом логически связанных таблиц, для анализа информации которых, а тем более для выбора рациональных технических решений приходится выполнять сложные запросы. В соответствии с такими задачами применения реляционных БД появилось новое направление их развития. Суть этого направления сводится к тому, что в системах управления базами данных формируются сложные объекты, объединяющие в себе не только расходные таблицы БД, но и соответствующие запросы. Это очень обширная область исследований, в которой затрагиваются вопросы разработки моделей данных, структур данных, языков запросов, управления транзакциями, журнализации и т.д. Это новое направление в разработке СУБД хотя и основывается на реляционной модели, но в ней не обязательно поддерживается требование полной нормализации отношений.
С расширением области применения реляционного подхода для решения задач, особенно в направлении CALS-технологий, стало очевидным, что применение принципа нормализации таблиц БД и создание отдельных транзакций и процедур при выполнении различных запросов «сводит на нет» все преимущества нормализованной схемы организации базы данных.
В ненормализованных реляционных моделях данных допускается создание и хранение в качестве объекта (исходного элемента системы) кортежей (записей), массивов (регулярных индексированных множеств данных), регулярных множеств элементарных данных, а также отношений. При этом такая вложенность может быть неограниченной.
Системы управления базами данных, в которых формируются такие сложные объекты, называют объектно-ориентированными базами данных (ООБД).
Генерация систем баз данных, ориентированных на приложения - это направление в развитии СУБД определяется тем, что невозможно создать универсальную систему управления базами данных, которая будет достаточна и не избыточна для применения в любом приложении. Например, если посмотреть на использование существующих СУБД для решения практических задач в производстве и бизнесе, то можно утверждать, что в большинстве случаев применяется не более чем 30 % возможностей системы. Тем не менее приложение несет всю тяжесть поддерживающей его СУБД, рассчитанной на использование в наиболее общих случаях.
Поэтому очень заманчиво производить не законченные универсальные СУБД, а нечто вроде компиляторов (compiler compiler), позволяющих собрать систему баз данных, ориентированную на конкретное приложение (или класс приложений).
Поэтому желательно уметь генерировать систему баз данных, возможности которой в достаточной степени соответствуют потребностям приложения. На сегодняшний день на коммерческом рынке такие генерационные системы отсутствуют (например, при выборе сервера системы Oracle при разработке конкретного приложения нельзя отказаться от каких-либо свойств системы).
Под оптимизацией запросов в реляционных СУБД обычно подразумевают такой способ обработки запросов, при котором по начальному представлению запроса путем его преобразований вырабатывается оптимальный процедурный план его выполнения.
Соответствующие преобразования начального представления запроса выполняются специальным компонентом СУБД - оптимизатором, и оптимальность производимого им плана выполнения запроса носит субъективный характер, поскольку критерий оптимальности заложен разработчиком в оптимизатор.
Такие инструментальные средства, обеспечивающие автоматизацию построения компиляторов имеются, например, в системах DB2, Oracle, Informix.
Общие понятия объектно-ориентированного подхода:
Направление объектно-ориентированных баз данных появлялось в середине 1980-х гг. Наиболее активно это направление развивается в последние годы.
Возникновение направления ООБД определяется прежде всего потребностями практики - необходимостью разработки сложных информационных прикладных систем, для которых технология предшествующих систем БД не была вполне удовлетворительной.
Конечно, ООБД возникли не на пустом месте. Соответствующий базис обеспечивают как предыдущие работы в области БД, так и давно развивающиеся направления языков программирования с абстрактными типами данных и объектно-ориентированных языков программирования.
Что касается связи с предыдущими работами в области БД, то, на наш взгляд, наиболее сильное влияние на работы в области ООБД оказывают проработки реляционных СУБД и следующее (хронологически) за ними семейство БД, в которых поддерживается управление сложными объектами.
Кроме того, исключительное влияние на идеи и концепции ООБД и всего объектно-ориентированного подхода оказал подход к семантическому моделированию данных. Достаточное влияние оказывают также развивающиеся параллельно с ООБД направления дедуктивных и активных БД.
В наиболее общей постановке объектно-ориентированный подход базируется на концепциях:
− объекта и идентификатора объекта;
− атрибутов и методов;
− классов;
− иерархии и наследования классов.
Любая сущность реального мира в объектно-ориентированных языках и системах моделируется в виде объекта. Любой объект при своем создании получает генерируемый системой уникальный идентификатор, который связан с объектом все время его существования и не меняется при изменении состояния объекта.
Каждый объект имеет состояние и поведение. Состояние объекта - набор значений его атрибутов. Поведение объекта - набор методов (программный код), оперирующих над состоянием объекта. Значение атрибута объекта - это тоже некоторый объект или множество объектов. Состояние и поведение объекта инкапсулированы в объекте; взаимодействуют объекты на основе передачи сообщений и выполнения соответствующих методов.
Множество объектов с одним и тем же набором атрибутов и методов образует класс объектов. Объект должен принадлежать только одному классу (если не учитывать возможности наследования). Допускается наличие примитивных предопределенных классов, объекты-экземпляры которых не имеют атрибутов: целые, строки и т.д. Класс, объекты которого могут служить значениями атрибута объектов другого класса, называется доменом этого атрибута.[9., стр. 230-240]
Допускается порождение нового класса на основе уже существующего класса - наследование. В этом случае новый класс, называемый подклассом существующего класса (суперкласса), наследует все атрибуты и методы суперкласса. В подклассе, кроме того, могут быть определены дополнительные атрибуты и методы. Различаются случаи простого и множественного наследования. В первом случае подкласс может определяться только на основе одного суперкласса, во втором случае суперклассов может быть несколько.
Если в языке или системе поддерживается единичное наследование классов, то набор классов образует древовидную иерархию. При поддержании множественного наследования классы связаны в ориентированный граф с корнем, называемый решеткой классов. Объект подкласса считается принадлежащим любому суперклассу этого класса.
Одной из более поздних идей объектно-ориентированного подхода является идея возможного переопределения атрибутов и методов суперкласса в подклассе (перегрузки методов). Эта возможность увеличивает гибкость, но порождает дополнительную проблему: при компиляции объектно-ориентированной программы могут быть неизвестны структура и программный код методов объекта, хотя его класс (в общем случае - суперкласс) известен.
Для разрешения этой проблемы применяется так называемый метод позднего связывания, означающий интерпретационный режим выполнения программы с распознаванием деталей реализации объекта во время выполнения посылки сообщения к нему. Введение некоторых ограничений на способ определения подклассов позволяет добиться эффективной реализации без потребностей в интерпретации.
При таком наборе базовых понятий, если не принимать во внимание возможности наследования классов и соответствующие проблемы, объектно-ориентированный подход очень близок к подходу языков программирования с абстрактными (или произвольными) типами данных.
С другой стороны, если абстрагироваться от поведенческого аспекта объектов, объектно-ориентированный подход весьма близок к подходу семантического моделирования данных (даже по терминологии).
Фундаментальные абстракции, лежащие в основе семантических моделей, неявно используются и в объектно-ориентированном подходе. На абстракции агрегации основывается построение сложных объектов, значениями атрибутов которых могут быть другие объекты. Абстракция группирования - основа формирования классов объектов. На абстракциях специализации (обобщения) основано построение иерархии или решетки классов.
Наиболее важным новым качеством ООБД, которое позволяет достичь объектно-ориентированного подхода, является поведенческий аспект объектов. В прикладных информационных системах, основывавшихся на БД с традиционной организацией (вплоть до тех, которые базировались на семантических моделях данных), существовал принципиальный разрыв между структурной и поведенческой частями. Структурная часть системы поддерживалась всем аппаратом БД, ее можно было моделировать, верифицировать, а поведенческая часть создавалась изолированно. В частности, отсутствовали формальный аппарат и системная поддержка совместного моделирования и гарантирования согласованности этих структурной (статической) и поведенческой (динамической) частей. В среде ООБД проектирование, разработка и сопровождение прикладной системы становятся процессом, в котором интегрируются структурный и поведенческий аспекты.
Конечно, для этого нужны специальные языки, позволяющие определять объекты и создавать на их основе прикладную систему.
Специфика применения объектно-ориентированного подхода для организации и управления БД потребовала уточненного толкования классических концепций и некоторого их расширения. Это определилось потребностями долговременного хранения объектов во внешней памяти, ассоциативного доступа к объектам, обеспечения согласованного состояния ООБД в условиях мультидоступа и тому подобных возможностей, свойственных базам данных.
Выделяют три аспекта, отсутствующих в традиционной парадигме, но требующихся в ООБД. Первый аспект касается потребности в средствах спецификации знаний при определении класса (ограничений целостности, травил дедукции и т.п.).
Второй аспект - потребность в механизме определения разного рода семантических связей между объектами разных классов. Фактически это означает требование полного распространения на ООБД средств семантического моделирования данных. Потребность в использовании абстракции ассоциирования отмечается и в связи с использованием ООБД в сфере автоматизированного проектирования и инженерии.[4., стр.230]
Третий аспект связан с пересмотром понятия класса. В контексте ООБД оказывается более удобным рассматривать класс как множество объектов данного типа, т.е. одновременно поддерживать понятия и типа, и класса объектов.
Объектно-ориентированные модели данных:
Первой формализованной и общепризнанной моделью данных была реляционная модель Кодда. В этой модели, как и во всех следующих, выделялись три аспекта: структурный, целостный и манипуляционный.
Структуры данных в реляционной модели основываются на плоских нормализованных отношениях, ограничения целостности выражаются с помощью средств логики первого порядка, манипулирование данными осуществляется на основе реляционной алгебры или равносильного ей реляционного исчисления. Своим успехом реляционная модель данных во многом обязана тому, что она опирается на строгий математический аппарат реляционной алгебры и теории множеств.
Основные трудности объектно-ориентированного моделирования данных связаны с тем, что не существует конкретного математического аппарата, на который могла бы опираться общая объектно-ориентированная модель данных. Разработка методов управления данными внутри объектов, как и любой процесс программирования нетрадиционных задач, остается «искусством программирования».Скачать Методы могут быть публичными (доступными из объектов других классов) или приватными (доступными только внутри данного класса). Итак, объектно-ориентированная система управления базами данных представляет собой объединение системы программирования и СУБД и основана на объектно-ориентированной модели данных. Основное назначение ООБД связано с потребностью создания единого информационного пространства.
В этой среде должны отсутствовать противоречия между структурной и поведенческой частями проекта и должно поддерживаться эффективное управление сложными структурами данных во внешней памяти.
В отличие от традиционных реляционных систем, в которых при создании приложения приходится одновременно использовать процедурный язык программирования, ориентированный на работу со скалярными значениями, и декларативный язык запросов, ориентированный на работу с множествами, языковая среда ООБД - это объектно-ориентированная система программирования, естественно включающая в себя средства работы с долговременными объектами. Естественность включения средств работы с БД в язык программирования означает, что работа с долговременными (хранимыми во внешней БД) объектами должна происходить на основе тех же синтаксических конструкций (и с той же семантикой), что и работа с временными объектами, существующими только во время работы программы.
Эта сторона ООБД наиболее близка родственному направлению языков программирования баз данных. Языки программирования ООБД и БД во многих своих чертах различаются только терминологически; существенным отличием является лишь поддержание в языках ООБД подхода к наследованию классов. Другим аспектом языкового окружения ООБД является потребность в языках запросов, которые можно было бы использовать в интерактивном режиме. Если доступ к объектам внешней БД в языках программирования ООБД носит в основном навигационный характер, то для языков запросов более удобен декларативный стиль. Как известно, декларативные языки запросов менее развиты, чем языки программирования.[11., стр. 42 - 125]
Глава 3. Анализ качества баз данных и тенденции в мире систем управления ими
.1 Функциональная пригодность баз данных
Для анализа свойств баз данных предлагается выделять характеристики качества системы управления базой данных и содержащейся в ней информации. Состав этих характеристик рекомендуется систематизировать на основе требований международного стандарта ISO 9126.
Современные базы данных - один из тех объектов в сфере информатизации, от которых иногда требуется особенно высокое качество и наличие возможности его оценки. Но что означает качество баз данных, какие требования следует предъявлять к их качеству, какими характеристиками можно описывать качество, как их оценивать и измерять? Для этого могут быть полезны методы и стандарты, разработанные для анализа сложных программных средств. При комплексном анализе качества баз данных не всегда удается четко разделить требования и значения характеристик качества для каждого из этих объектов. Одна СУБД может обрабатывать различные по структуре, составу и содержанию данные, а одни и те же данные могут управляться различными СУБД. При анализе качества баз данных целесообразно рассматривать два компонента: систему программ управления данными и совокупность данных, упорядоченных по некоторым правилам. Хотя эти компоненты тесно взаимодействуют при реализации конкретной базы данных, первоначально они создаются независимо и могут рассматриваться в своем жизненном цикле как два объекта, которые различаются:
номенклатурой и содержанием показателей качества, определяющих их назначение, функции и потребительские свойства;
технологией и средствами автоматизации разработки и обеспечения всего жизненного цикла объекта;
категориями специалистов, обеспечивающих создание, эксплуатацию или применение баз данных;
комплектами эксплуатационной и технологической документации, поддерживающими жизненный цикл объекта.
Практически весь набор характеристик и атрибутов из стандарта ISO 9126 «Качество программных средств» в той или иной степени может использоваться в составе требований к СУБД. Особенности состоят в изменении акцентов при их выборе и упорядочении. Во всех случаях важнейшими характеристиками качества СУБД являются требования к функциональной пригодности процессов формирования и изменения информационного наполнения баз данных администраторами, а также доступа к данным и представления результатов пользователям.
Различия требований к характеристикам качества привели к созданию широкого спектра локальных, специализированных и распределенных СУБД. В зависимости от области применения, приоритет при оценке качества может отдаваться различным конструктивным характеристикам: надежности и защищенности применения (финансовая сфера), удобству использования малоквалифицированными пользователями (социальная сфера), эффективности использования ресурсов (сфера материально-технического снабжения). Однако практически во всех случаях сохраняется некоторая роль других конструктивных показателей качества - для каждого из них необходимо оценивать его приоритет для конкретной сферы применения, меры и шкалы необходимых и допустимых характеристик качества. В системах баз данных доминирующее значение приобретают сами данные, их хранение и обработка. Для оценивания качества информации может применяться общий методический подход к выделению адекватной номенклатуры стандартизированных в ISO 9126 базовых характеристик и субхарактеристик. Однако их содержание для применения к качеству баз данных требуется уточнить. Выделяемые показатели качества должны иметь практический интерес для пользователей и быть упорядочены в соответствии с приоритетами практического применения.[8., стр. 87] Кроме того, каждый выделяемый показатель качества должен быть пригоден для достоверного экспертного оценивания или измерения, а также для сравнения с требуемым значением.
При разработке базы данных в техническом задании и спецификации на нее должен формализоваться представительный набор функциональных требований к качеству базы данных, адекватный ее назначению и области применения, а также требованиям заказчика и потенциальных пользователей. Так же как для программных систем, характеристики качества информации можно разделить на функциональные и конструктивные. Их номенклатура, содержание и субхарактеристики базируются на ISO 9126. Может быть заложена основа для стандартизированного формирования требований к качеству баз данных и при изложении содержания характеристик качества использованы номенклатура и описания характеристик, в которых объекты для анализа качества - «программы», заменены термином и содержанием - «информация баз данных». Однако номенклатура показателей качества не всегда может ограничиваться только характеристиками информации в базе данных, а должна включать ряд уточнений, отражающих комплексную эффективность и функциональную пригодность ее применения в реальных условиях. Функциональная пригодность информации базы данных может представлять сложную проблему для измерения и оценки соответствия требованиям реальных значений атрибутов качества. Особенно это актуально для больших распределенных баз данных, в которых циркулирует разнообразная и сложная информация об анализируемых объектах. Мерой качества функциональной пригодности может быть степень покрытия целей, назначения и функций баз данных доступной пользователям информацией. Как и для программных систем, для баз данных целесообразно использовать группу субхарактеристик, определяющих функциональные, структурные и эксплуатационные требования. На содержательном уровне функциональную пригодность многих баз данных отражают:
Полнота накопленных описаний объектов - относительное число объектов или документов, имеющихся в базе данных, к общему числу объектов по данной тематике или по отношению к числу объектов в аналогичных базах данных.
Идентичность - относительное число описаний объектов, не содержащих дефекты и ошибки, к общему числу документов об объектах в базах данных.
Актуальность - относительное число устаревших данных об объектах в базах данных, к общему числу накопленных и обрабатываемых данных.
Разнообразие функций баз данных ограничивает возможность стандартизации требований к ним только общими правилами их организации, структурирования и документирования. Меры и шкалы качества функциональной пригодности столь же разнообразны, насколько различаются назначения и специфика функций информации баз данных, однако конструктивные характеристики могут быть в значительной степени стандартизированы. К конструктивным характеристикам качества информации можно отнести практически все стандартизированные показатели качества, представленные в ISO 9126. Требования к информации баз данных также должны содержать особенности обеспечения ее надежности, эффективности использования ресурсов компьютера, практичности, применимости, сопровождаемости и мобильности. Содержание и атрибуты этих характеристик несколько отличаются от тех, которые применяются для программ, однако их сущность целесообразно использовать. Меры и шкалы для оценивания конструктивных характеристик, в значительной степени, могут применяться те же, что при анализе качества программных средств.[6., стр. 18]
Корректность или достоверность данных - это степень соответствия данных об объектах в базах данных реальным объектам в данный момент времени, определяющаяся изменениями самих объектов, некорректностями записей об их состоянии или некорректностями расчетов их характеристик. Выбор и установку требований к корректности данных можно оценивать по степени покрытия накопленными, актуальными и достоверными данными состояния и изменения внешних объектов, которые они отражают. Сюда же можно отнести и некоторые объемно-временные характеристики сохраняемых и обрабатываемых данных:
Оперативность - степень соответствия динамики изменения данных состояниям реальных объектов.
Глубина ретроспективы - интервал времени от даты выпуска и/или записи в базу данных самого раннего документа до настоящего времени.
Динамичность - относительное число изменяемых описаний объектов к общему числу записей в базе данных за некоторый интервал времени, определяемый периодичностью издания версий базы.
Защищенность информации реализуется средствами СУБД в сочетании с поддерживающими их средствами защиты данных. Цели, назначение и функции защиты тесно связаны с особенностями функциональной пригодности каждой базы данных. В распределенных базах данных показатели защищенности тесно связаны с характеристиками целостности и отражают степень тождественности одинаковых данных в памяти удаленных компонентов. На практике способности защищать информацию баз данных от негативных воздействий описываются обычно составом средств, используемых для защиты от внешних и внутренних угроз. Однако есть попытки измерять и описывать качество защищенности информации обобщенно, трудоемкостью и временем, необходимыми для преодоления злоумышленниками системы защиты. Косвенным показателем ее качества может служить относительная доля вычислительных ресурсов, используемых непосредственно средствами защиты информации. На практике основное внимание сосредоточено на защите от злоумышленных разрушений, искажений и хищений информации баз данных. Основой такой защиты является аудит санкционирования доступа, а также контроль организации и эффективности ограничений доступа. В реальных базах данных возможны и не всегда учитываются катастрофические последствия и аномалии информации, отражающиеся на безопасности применения, при которых их источниками являются случайные, непредсказуемые дестабилизирующие факторы. Качество защиты можно характеризовать величиной предотвращенного ущерба, возможного при проявлении дестабилизирующих факторов и реализации конкретных угроз безопасности, а также средним временем между возможными проявлениями угроз, преодолевающих защиту данных. Надежность информации баз данных может основываться на применении понятий и методов теории надежности, которая позволяет получить ряд четких, хорошо измеряемых интегральных показателей. Надежная база данных, прежде всего, должна обеспечивать низкую вероятность потери работоспособности. Быстрое реагирование на потерю или искажение данных и восстановление их достоверности и работоспособности за время меньшее, чем порог между сбоем и отказом, обеспечивают высокую надежность. Классификация сбоев и отказов по длительности восстановления приводит к необходимости анализа динамических характеристик абонентов, являющихся источниками и/или потребителями данных. Для любого потребителя информации существует допустимое время отсутствия данных от базы данных, при котором их значения, изменяясь по инерции, достигают предельного отклонения от того, которое должно было быть рассчитано. Это допустимое отклонение результатов после перерыва функционирования базы данных зависит, в основном, от динамических характеристик источников и потребителей информации. Используемость ресурсов (или ресурсная экономичность) в стандартах отражается занятостью ресурсов центрального процессора, оперативной, внешней и виртуальной памяти, каналов ввода-вывода, терминалов и каналов связи. В зависимости от конкретных задач и особенностей базы данных при выборе атрибутов качества может доминировать либо величина абсолютной занятости ресурсов различных видов, либо относительная величина использования ресурсов каждого вида при нормальном функционировании базы данных. Задача оценки и эффективного использования вычислительных ресурсов сохраняет свою актуальность.
Практичность (применимость) - трудно формализуемое понятие, однако, в итоге, значительно определяющее функциональную пригодность и полезность применения базы данных для определенных пользователей. В эту группу показателей входят субхарактеристики, с различных сторон отражающие функциональную понятность, удобство освоения, системную эффективность и простоту использования данных. Некоторые субхарактеристики можно оценивать экономическими показателями - затратами труда и времени специалистов на реализацию определенных функций взаимодействия с данными. В стандарте ISO 9126 для этой характеристики качества предлагается наибольшее число атрибутов, подробно описывающих свойства программных средств, которые так же могут быть полезны для оценки баз данных заказчиками при их практическом выборе, освоении и применении. Оценки практичности зависят не только от собственных характеристик баз данных, но также от организации и адекватности документирования процессов их эксплуатации.
Понятность зависит от качества документации и субъективных впечатлений потенциальных пользователей. Ее можно описать качественно четкостью функциональной концепции, широтой демонстрационных возможностей, полнотой, комплектностью и наглядностью представления в эксплуатационной документации возможных функций и особенностей реализации данных. Она должна обеспечиваться корректностью и полнотой описания исходной и результирующей информации, а также всех деталей применения базы данных для пользователей.
Простота использования - возможность удобно и комфортно эксплуатировать базу данных и манипулировать данными. Она соответствует управляемости, устойчивости к дефектам данных и согласованности с ожиданиями и навыками пользователей. Некоторые атрибуты этой субхарактеристики можно оценить количественно путем измерения трудоемкости и длительности соответствующих процессов подготовки и обучения квалифицированных пользователей. Изучаемость может определяться трудоемкостью и длительностью подготовки пользователя. Качество изучаемости зависит от внутренних свойств и сложности структуры информации базы данных, а также от субъективных характеристик квалификации конкретных пользователей.
Изучаемость может также характеризоваться объемом эксплуатационной документации или объемом и качеством электронных учебников.
Сопровождаемость информации может отражаться удобством и эффективностью исправления, усовершенствования или адаптации структуры и содержания описаний данных в зависимости от изменений во внешней среде применения, а также в требованиях и функциональных спецификациях заказчика. Обобщенно качество сопровождаемости базы данных можно оценивать потребностью ресурсов для ее обеспечения и для реализации. Возможные затраты ресурсов на развитие и совершенствование качества базы данных зависят не только от внутренних свойств данных, но также от запросов и потребностей пользователей и от готовности заказчика и разработчика удовлетворить эти потребности. По объему предполагаемых изменений, а также вновь вводимых в очередную версию данных с учетом сложности и новизны их разработки могут быть оценены затраты на их создание. Такой анализ может дать ориентиры для прогнозирования общих затрат на сопровождение и для оценивания этой характеристики качества в конкретных проектах. Совокупность субхарактеристик сопровождаемости программной системы, представленная в стандарте ISO 9126, вполне применима для описания этого качества баз данных, в основном, теми же организационно-технологическими субхарактеристиками. Анализируемость базы данных зависит от стройности архитектуры, унифицированности интерфейсов, полноты и корректности технологической и эксплуатационной документации. Изменяемость состоит в приспособленности структуры и содержания данных к реализации специфицированных изменений и к управлению конфигурацией данных. Изменяемость зависит не только от внутренних свойств базы данных, но также от организации и инструментальной оснащенности процессов сопровождения и конфигурационного управления, на которые ориентирована архитектура, внешние и внутренние интерфейсы данных. Тестируемость зависит от величины области влияния изменений, которые необходимо тестировать при модификациях структуры и содержания данных, от сложности тестов для проверки их характеристик. Ее атрибуты зависят от четкости правил структурного построения компонентов и базы данных в целом, от унификации межмодульных и внешних интерфейсов, от полноты и корректности технологической документации. Субхарактеристики изменяемости и тестируемости данных доступны для количественных оценок по величине трудоемкости и длительности реализации этих функций при типовых операциях с данными при применении различных методов и средств автоматизации. Эти экономические шкалы по существу (хотя и не явно) могут отражать также анализируемость и стабильность, и применяться для интегрального оценивания сопровождаемости в целом. Мобильность баз данных, как и программ, можно характеризовать в основном длительностью и трудоемкостью их инсталляции, адаптации и замещаемости при переносе на иные аппаратные и операционные платформы. Информация о процессах, происходящих во внешней среде, может иметь большие объемы и трудоемкость первичного накопления и актуализации, что определяет необходимость ее тщательного хранения и регламентированного изменения. Возможны ситуации, когда подобные данные являются уникальными и невосстанавливаемыми. Однако первичные аппаратная или операционная платформы, в которых они накапливались и обрабатывались, может требовать расширения и замены. Формирование и заполнение информацией баз данных достаточно сложный и трудоемкий процесс, технико-экономические показатели которого сильно зависят от структуры, состава, объема, связности и других характеристик исходной информации. Однако часто возможность переноса при первичном формировании и наполнении базы данных не предусматривается и проявляется после длительной эксплуатации. Сложность, трудоемкость и длительность переноса в этом случае значительно возрастают и требуют тщательного планирования и организации работ, приближающихся к созданию новой базы данных. Одновременно должно быть обеспечено сохранение или повышение качества ее функционирования на новой платформе. Для оценки качества и определения требований к мобильности базы данных следует решать задачу сравнения достигаемого эффекта и затрат для методов переноса или повторной разработки компонентов и наполнения базы данных в конкретных условиях с учетом всех перечисленных факторов и затрат. Эти задачи значительно упрощаются при одновременном сокращении затрат при применении идеологии и концепции открытых компьютерных систем, поддержанных комплексом международных стандартов POSIX, а также современных версий ОС и СУБД, как стандартов де-факто. Формализация характеристик качества информации баз данных, на основе стандартов, разработанных для оценивания программных средств, открывает путь для применения апробированных на комплексах программ методов систематизации, определения и повышения их качества. Использование стандартизированных характеристик качества информации баз данных позволяет упорядочить выбор требований к ним и оценивание достигнутого качества. Это должно способствовать повышению качества баз данных в целом, с учетом их программных и информационных компонентов, возможности достоверного определения их реальных характеристик при разработке, испытаниях и сертификации.[3]
3.2 Тенденции в мире систем управления базами данных
Системы управления базами данных (СУБД) играют исключительную роль в организации современных промышленных, инструментальных и исследовательских информационных систем. Тематика СУБД поистине безгранична. В этой главе описываются наиболее интересные направления исследований и разработок.
Реляционные системы
Хотя многие полагают, что реляционные СУБД, являясь наиболее распространенным современным аппаратом построения информационных систем, не представляют уже интереса в научном отношении, остается еще много нерешенных или решенных не полностью проблем. Об этом свидетельствует поток статей, посвященных тематике чисто реляционных систем, а также активная деятельность компаний-производителей коммерческих реляционных систем, стремящихся улучшать свои продукты и придавать им новые качества. Продолжающаяся работа исследователей затрагивают вопросы оптимизации запросов, новых алгоритмов выполнения реляционных операций, оптимизации структур хранения данных и другие аспекты, непосредственно определяющие эффективность СУБД. Те же самые вопросы занимают и разработчиков коммерческих СУБД, которые, кроме того озабочены и более прикладными проблемами. Рассмотрим немного более подробно (но без технических деталей) существо некоторых из этих вопросов и то, каким образом они решаются в наиболее развитых коммерческих продуктах.
Использование мультипроцессорных организаций
Уже довольно давно развитые коммерческие СУБД основываются на архитектуре "клиент-сервер". При этой организации наиболее трудоемкие операции над базами данных выполняются на выделенном компьютере-сервере, который должен быть достаточно мощным и обладать соответствующим набором ресурсов основной и внешней памяти. До поры серверная часть СУБД обладала простой организацией: запросы, поступающие из клиентских частей системы, обрабатывались последовательно с небольшой оптимизацией для совмещения процессорной работы с работой устройств внешней памяти. Однако с появлением на рынке мультипроцессорных симметричных аппаратных архитектур, производители СУБД были вынуждены пересмотреть организацию своих серверов, допустив в них внутреннюю параллельность. Естественно, это требует очень основательного перепроектирования системы с ее существенным усложнением. Заметим, что в большинстве случаев компании пошли на это после появления в ОС UNIX механизма "легковесных" процессов (threads).
О серьезности этой работы говорит тот факт, что, например, в компании Informix было образовано новое подразделение, занимающееся исключительно вопросами распараллеливания работы серверов.
Интеграция
Чтобы убедить новых потенциальных пользователей использовать новые продукты, компании- производители должны обеспечить решение проблемы использования старых баз данных. В принципе эта проблема является частным видом проблемы включения в открытые системы компонентов, которые не были на это рассчитаны с самого начала. В большинстве случаев предлагаемые решения основываются на использовании индустриальных стандартов распределенных объектных систем (например, стандарта CORBA, разработанного OMG). Тем не менее, производители СУБД вынуждены решать многочисленные проблемы для вхождения их систем в новые интегрированные среды.
Базы сложных объектов, реляционная модель с отказом от первой нормальной формы
Одним из основных положений реляционной модели данных является требование нормализации отношений: поля кортежей могут содержать лишь атомарные значения. Для традиционных приложений реляционных СУБД - банковских систем, систем резервирования и т.д. - это вовсе не ограничение, а даже преимущество, позволяющее проектировать экономные по памяти БД с предельно понятной структурой. Запросы с соединениями в таких системах сравнительно редки, для динамической поддержки целостности используются соответствующие средства SQL. Однако с появлением эффективных реляционных СУБД их стали пытаться использовать и в менее традиционных прикладных системах - САПР, системы искусственного интеллекта и т.д. Такие системы обычно оперируют со сложно структурированными объектами, для реконструкции которых из плоских таблиц реляционной БД приходится выполнять запросы, почти всегда требующие соединения отношений. В соответствии с требованиями разработчиков нетрадиционных приложений появилось направление исследований баз сложных объектов. Это очень обширная область исследований, в которой затрагиваются вопросы моделей данных, структур данных, языков запросов, управления транзакциями, журнализации и т.д. Во многом эта область соприкасается с областью объектно-ориентированных БД.
Активные базы данных
По определению БД называется активной, если СУБД по отношению к ней выполняет не только те действия, которые явно указывает пользователь, но и дополнительные действия в соответствии с правилами, заложенными в саму БД. Легко видеть, что основа этой идеи содержалась в языке SQL времени System R. На самом деле, что есть определение триггера или условного воздействия как не введение в БД правила, в соответствии с которым СУБД должна производить дополнительные действия? Плохо лишь то, что на самом деле триггеры не были полностью реализованы ни в одной из известных систем, даже и в System R. И это не случайно, потому что реализация такого аппарата в СУБД очень сложна, накладна и не полностью понятна.
Дедуктивные базы данных
По определению, дедуктивная БД состоит из двух частей: экстенсиональной, содержащей факты, и интенсиональной, содержащей правила для логического вывода новых фактов на основе экстенсиональной части и запроса пользователя.
Легко видеть, что при таком общем определении SQL-ориентированную реляционную СУБД можно отнести к дедуктивным системам. Действительно, что есть определенные в схеме реляционной БД представления как не интенсиональная часть БД.
Основным отличием реальной дедуктивной СУБД от реляционной является то, что и правила интенсиональной части БД, и запросы пользователей могут содержать рекурсию. Именно возможность рекурсии делает реализацию дедуктивной СУБД очень сложной и во многих случаях эффективно неразрешимой проблемой. Обычно языки запросов и определения интенсиональной части БД являются логическими (поэтому дедуктивные БД часто называют логическими). Имеется прямая связь дедуктивных БД с базами знаний (интенсиональную часть БД можно рассматривать как БЗ). Более того, трудно провести грань между этими двумя сущностями; по крайней мере, общего мнения по этому поводу не существует. Какова же связь дедуктивных БД с реляционными СУБД, кроме того, что реляционная БД является вырожденным частным случаем дедуктивной? Основным является то, что для реализации дедуктивной СУБД обычно применяется реляционная система. Такая система выступает в роли хранителя фактов и исполнителя запросов, поступающих с уровня дедуктивной СУБД. Между прочим, такое использование реляционных СУБД резко актуализирует задачу глобальной оптимизации запросов.
При обычном применении реляционной СУБД запросы обычно поступают на обработку по одному, поэтому нет повода для их глобальной (межзапросной) оптимизации. Дедуктивная же СУБД при выполнении одного запроса пользователя в общем случае генерирует пакет запросов к реляционной СУБД, которые могут оптимизироваться совместно. Конечно, в случае, когда набор правил дедуктивной БД становится велик, и их невозможно разместить в оперативной памяти, возникает проблема управления их хранением и доступом к ним во внешней памяти. Здесь опять же может быть применена реляционная система, но уже не слишком эффективно. Требуются более сложные структуры данных и другие условия выборки. Известны частные попытки решить эту проблему, но общего решения пока нет.
Темпоральные базы данных
Обычные БД хранят мгновенный снимок модели предметной области. Любое изменение в момент времени t некоторого объекта приводит к недоступности состояния этого объекта в предыдущий момент времени. Самое интересное, что на самом деле в большинстве развитых СУБД предыдущее состояние объекта сохраняется в журнале изменений, но возможности доступа со стороны пользователя нет.
Распределенные СУБД
В теоретическом плане распределенные СУБД составляют еще одно измерение в пространстве исследований и разработок систем управления базами данных. В этих системах приходится решать все задачи, свойственные централизованным СУБД, но, как правило, в более сложных постановках. Кроме того, в распределенных системах возникают и специфические проблемы, от решения которых во многом зависит эффективность, надежность и доступность систем БД. В настоящее время большинство распределенных СУБД базируется на реляционной модели данных и рассчитано на использование в локальных сетях ЭВМ. Многие проблемы распространяются и на распределенные СУБД в территориально разнесенных сетях, и почти все проблемы сохраняются для распределенных СУБД, основанных на других моделях данных.
Алгоритмы выполнения реляционных операций
Даже если говорить только про реляционные распределенные СУБД, которые наиболее развиты в теоретическом и практическом отношении, до сих пор проводится масса исследований в области оптимизации алгоритмов выполнения реляционных операций (главным образом, соединения удаленных отношений). Таким образом, даже рассмотрев только небольшую часть проблем распределенных систем, можно убедиться, что они нуждаются в большом количестве исследований и экспериментов. Начавшийся в России переход к использованию локальных сетей дает практическую возможность проведения таких работ.[2., стр. 520]
Заключение
Эффективное развитие государства немыслимо без систем управления. Современные системы управления базируются на комплексных системах обработки информации, на современных информационных технологиях.
Современные системы компьютерного управления обеспечивают:
Определение тенденций изменения важных показателей.
Получение информации во времени без задержек.
Выполнение точного и полного анализа данных.
Базы данных - важнейшая составная часть информационных систем. Информационные системы предназначены для хранения и обработки больших объемов информации. Изначально такие системы существовали в письменном виде. Для этого использовались различные картотеки, папки, журналы, библиотечные каталоги и т.д. Любая информационная система должна выполнять три основные функции: ввод данных, запросы по данным, составление отчетов. При комплексном анализе качества баз данных не всегда удается четко разделить требования и значения характеристик качества для каждого из этих объектов. Одна СУБД может обрабатывать различные по структуре, составу и содержанию данные, а одни и те же данные могут управляться различными СУБД. При анализе качества баз данных целесообразно рассматривать два компонента: систему программ управления данными и совокупность данных, упорядоченных по некоторым правилам. Из вышеизложенного можно сделать вывод о том, что из себя представляют базы данных, а также системы управления ими. В современном мире базы данных просто необходимы, исходя из количества информации, с которым приходится иметь дело. Итак, использование концепции бах данных позволяет:
повысить надежность, целостность и сохранность данных;
сохранить затраты интеллектуального труда;
обеспечить простоту и легкость использования данных;
обеспечить независимость прикладных программ от данных (изменений их описаний и способов хранения);
обеспечить достоверность данных;
обеспечить требуемую скорость доступа к данным;
стандартизовать данные в пределах одной предметной области;
автоматизировать реорганизацию данных;
обеспечить защиту от искажения и уничтожения данных;
сократить дублирование информации за счет структурирования данных;
обеспечить обработку незапланированных запросов к хранимой информации;
создать предпосылки для создания распределенной обработки дaнныx.
Следовательно, СУБД - это программная оболочка, расширяющая функции операционной системы (OC), которая управляет доступом к базам данных и обеспечивает сервисные функции для пользователя.
Список использованной литературы
1. Симонович С.В. Информатика. СПб.: Питер, 2010.-640с.
. К.Дж. Дейт Введение в системы баз данных = Introduction to Database Systems. - 8-е изд. - М.: «Вильямс», 2006. - С. 1328.
. Сергей Кузнецов «Тенденции в мире систем управления базами данных»
. Леонтьев В.П. Новейшая энциклопедия персонального компьютера 2003г. - 5 изд., перераб. и доп. - М.: ОЛМА-ПРЕСС, 2003г.
. Роланд Фред. Основные концепции баз данных. Вильямс. 2002
. Ульман Дж., Уидом Дж. Введение в системы баз данных. М. Лори. 2000.
. Федоров Д., Елманова Н. Базы данных для всех. М. Компьютер-пресс, 2001.
. Хомоненко А. Базы данных. Учебник для вузов. 2 издание. СПб., 2000.
. Информатика: Учебник для вузов (Гриф МО РФ) / Острейковский В.А., М: Высшая школа, 2001. - 511 с.
. Информатика: Учебник для вузов / Козырев А.А. - СПб: издательство Михайлова В.А., 2002. - 511 с.
. Илюшечкин В.М. Основы использования и проектирования баз данных. М.: Юрайт, 2010.-213с.
. Кузин А.В. Базы данных. М.: Академия, 2008.-320с.
. Гольцман В.И. Библиотека программиста. СПб.: Питер, 2008.-256с.