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

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

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

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

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

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

  • 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. Неограниченное число измерений и уровней обобщения.

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

 
< Пред   СОДЕРЖАНИЕ     След >