Концепция баз данных

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

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

Требования, предъявляемые к базам данных

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

Первоначально перечислим основные требования, которые предъявляются к операционным базам данных, а следовательно, и к СУБД, на которых они строятся.

• 1. Простота обновления данных. Подоперацией обновления понимают добавления, удаления и изменения данных.
• 2. Высокое быстродействие (малое время отклика на запрос). Время отклика — промежуток времени от момента запроса к БД и фактическим получением данных. Похожим является термин время доступа — промежуток времени между выдачей команды записи (считывания) и фактическим получением данных. Под доступом понимается операция поиска, чтения данных или записи их.
• 3. Независимость данных.
• 4. Совместное использование данных многими пользователями.
• 5. Безопасность данных — защита данных от преднамеренного или непреднамеренного нарушения секретности, искажения или разрушения.
• 6. Стандартизация построения и эксплуатации БД (фактически СУБД).
• 7. Адекватность отображения данных соответствующей предметной области.
• 8. Дружелюбный интерфейс пользователя.

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

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

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

Она предполагает:

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

Целостность обеспечивается триггерами целостности — специальными приложениями-программами, работающими при определенных условиях. Для некоторых СУБД (например, Access, Paradox) триггеры являются встроенными.

Защита данных от несанкционированного доступа предполагает ограничение доступа к конфиденциальным данным и может достигаться:

• • введением системы паролей;
• • получением разрешений от администратора базы данных (АБД);
• • запретом от АБД на доступ к данным;
• • формированием видов — таблиц, производных от исходных и предназначенных конкретным пользователям.

Три последние процедуры легко выполняются в рамках языка структурированных запросов Structured Query Language — SQL, часто называемом SQL2.

Стандартизация обеспечивает преемственность поколений СУБД, упрощает взаимодействие БД одного поколения СУБД с одинаковыми и различными моделями данных. Стандартизация (ANSI/SPARC) осуществлена в значительной степени в части интерфейса пользователя СУБД и языка SQL. Это позволило успешно решить задачу взаимодействия различных реляционных СУБД как с помощью языка SQL, так и с применением приложения Open DataBase Connection (ODBC). При этом может быть осуществлен как локальный, так и удаленный доступ к данным (технология клиент-сервер или сетевой вариант).

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

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

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

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

К хранилищам данных предъявляются следующие дополнительные требования [2]:

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

Поддержка анализа данных соответствующими методами (инструментами).

Как отмечено в [2] Э. Ф. Кодд на основе своего опыта предъявил следующие требования к системе OLAP.

• 1. Многомерное концептуальное представление данных.
• 2. Прозрачность технологии и источников данных.
• 3. Доступность к источникам данных при использовании различных моделей данных.
• 4. Неизменная производительность подготовки отчетов при росте объема, количества измерений, процедур обобщения данных.
• 5. Использование гибкой, адаптивной, масштабируемой архитектуры клиент-сервер.
• 6. Универсальность измерений (формулы и средства создания отчетов не должны быть привязаны к конкретным видам размерностей).
• 7. Динамическое управление разреженностью матриц (пустые значения NULL должны храниться эффективным образом).
• 8. Многопользовательская поддержка.
• 9. Неограниченные операционные связи между размерностями.
• 10. Поддержка интуитивно понятных манипуляций с данными.
• 11. Гибкость средств формирования отчетов.
• 12. Неограниченное число измерений и уровней обобщения.

Перечисленные требования отличны от требований к операционным БД, что вызнало появление специализированных БД — хранилищ данных.