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

Технологии баз данных
и знаний

ПРОЕКТИРОВАНИЕ БАЗЫ ДАННЫХ

Разработчик: доц. Оскерко В.С.

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

3. Модель «сущность–связь»

1. ТРЕБОВАНИЯ, ПРЕДЪЯВЛЯЕМЫЕ К БАЗЕ ДАННЫХ

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

1) целостность базы данных – требование полноты и непротиворечивости данных;

2) многократное использование данных;

3) быстрый поиск и получение информации по запросам пользователей;

4) простота обновления данных;

5) уменьшение излишней избыточности данных;

6) защита данных от несанкционированного доступа, искажения и уничтожения.

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

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

Модели базы данных базируются на современном подходе к обработке информации. Структура информации базы позволяет формировать логические записи их элементов и их взаимосвязи. Взаимосвязи могут быть: один к одному, один ко многои и многие ко многим.

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

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

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

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

Отношения обладают следующими свойствами:

  • каждый элемент – один элемент данных;
  • повторяющиеся группы отсутствуют;
  • элементы столбца имеют одинаковую природу;
  • в таблице не повторяются строки;
  • строки и столбцы можно просматривать в любом порядке.

Преимущество данной модели:

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

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

Основные функции СУБД:

1. Непосредственное управление данными во внешней памяти

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

2. Управление буферами оперативной памяти

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

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

3. Управление транзакциями

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

4. Журнализация

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

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

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

5. Поддержка языков БД

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

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

Классификация систем управления базами данных (самостоятельно).

Организация типичной СУБД и состав ее компонентов соответствует рассмотренному набору функций.

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

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

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

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

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

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

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

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

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

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

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

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

Основные понятия баз данных

Цель лекции: Уяснить разницу между базой данных и системой управления базой данных. Ознакомиться с основными требованиями, которые предъявляются к банку данных и основными определениями, относящимися к БД и СУБД.

Рассмотрим общий смысл понятий базы данных (БД) и системы управления базами данных (СУБД).

С самого начала развития вычислительной техники образовались два основных направления использования ее.

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

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

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

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

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

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

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

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

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

Определение основных терминов

Дадим определения основных терминов. В качестве составных частей схемы выделяются информация (входная и выходная) и правила ее преобразования.

Правила могут быть в виде алгоритмов, процедур и эвристических последовательностей.

4. Основные требования к субд

Средства управления базами данных называются системами управления базами данных (СУБД).

Основные требования к СУБД.

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

С требованием целостности данных связано понятие транзакции.

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

2. Актуальность хранимых данных. В любой момент времени ин­формация, содержащаяся в БД, должна быть современной.

3. Многоаспектное использование данных — поступление информации из различных источников в единую БД и возможность ее использования любым отделом предприятия в соответствии с пра­вами доступа и функциями.

4. Возможность модификации системы возможность ее расширения и модификации данных, а также дополнение новыми функциями без ущерба для системы в целом.

5. Надежность целостность БД не должна нарушаться при технических сбоях.

6. Скорость доступа обеспечение быстрого доступа к требуемой информации.

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

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

• непосредственное управление данными во внешней и оперативной памяти и обеспечение эффективного доступа к ним в процессе решения задач;

• поддержание целостности данных и управление транзакциями;

• ведение системного журнала изменений в БД для обеспечения восстановления БД после технического или программного сбоя;

• реализация поддержки языка описания данных и языка за­просов;

• обеспечение безопасности данных;

• обеспечение параллельного доступа к данным нескольких пользователей.

5. Проектирование бд

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

Смотрите так же:  Осаго калькулятор ргс

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

На следующем шаге принимается решение о том, в какой конкретно СУБД будет реализована БД.

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

• удобство и простота использования;

• качество средств разработки, защиты и контроля БД;

• уровень коммуникационных средств (в случае применения ее в сетях);

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

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

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

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

Преобразование данных из физической БД в представления логической модели осуществляет СУБД.

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

• разработка проекта БД (определение объектов и их свойств, разработка структуры и технологии работы с БД, выбор технических и программных средств);

• обследование программного обеспечения.

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

На этапе реализации производится создание БД и разработка программ (приложений) в выбранной СУБД.

Эксплуатация начинается с заполнения БД реальными данными. На этом этапе необходимо сопровождение БД, т.е. проведение контроля непротиворечивости, резервное копирование, архивирование и т.д.

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

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

Цели и задачи системы определяют заказчики. Они предоставляют разработчику все сведения о бизнес-процессах и характеристики моделируемых объектов.

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

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

• разработка и реализация мер по обеспечению защиты данных и разграничению доступа к данным;

• контроль за непротиворечивостью и достоверностью данных;

• анализ эффективности использования ресурсов ИС;

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

• координация работы прикладных программистов, разрабатывающих новые приложения для работы с БД.

Достоинства реляционной модели:

• простота и доступность для понимания конечным пользователем. Единственной информационной конструкцией является таблица;

• при проектировании реляционных БД применяются строгие правила, базирующиеся на математическом аппарате;

• полная независимость данных. При изменении структуры ре­ляционной БД изменения, которые требуется произвести в прикладных программах, минимальны.

• для построения запросов и написания прикладных программ нет необходимости знания конкретной организации БД во внешней памяти.

Недостатки реляционной модели:

• по сравнению с другими моделями реляционная модель имеет более низкую скорость доступа и требует большего объема внешней памяти;

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

• не всегда предметную область можно представить в виде совокупности таблиц.

Для преодоления недостатков, присущих реляционной модели, в настоящее время развиваются постреляционная, многомерная и объектно-ориентированная модели. Эти модели в той или иной степени опираются на реляционную модель. Но реляционная модель и коммерческие продукты, основанные на этой модели, доминируют при построении ИС.

Московский государственный университет печати

Базы и банки данных

Учебное пособие

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

Составными частями концепции являются совокупность принципов и методология.

Методология — совокупность методов решения проблемы.

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

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

Высокое быстродействие (малое время отклика на запрос).

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

Простота обновления данных.

Совместное использование данных многими пользователями.

Безопасность данных — защита данных от преднамеренного или непреднамеренного нарушения секретности, искажения или разрушения.

Стандартизация построения и эксплуатации БД (фактически СУБД).

Адекватность отображения данных соответствующей предметной области.

Дружелюбный интерфейс пользователя.

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

Независимость данных — возможность изменения логической и физической структуры БД без изменения представлений пользователей.

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

Безопасность данных включает их целостность и защиту.

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

1) отсутствие неточно введенных данных или двух одинаковых записей об одном и том же факте;

2) защиту от ошибок при обновлении БД;

3) невозможность удаления (или каскадное удаление) связанных данных разных таблиц;

4) неискажение данных при работе в многопользовательском режиме и в распределенных базах данных;

5) сохранность данных при сбоях техники (восстановление данных).

Целостность обеспечивается триггерами целостности — специальными приложениями-программами, работающими при определенных условиях. Защита данных от несанкционированного доступа предполагает ограничение доступа к конфиденциальным данным и может достигаться:

1) введением системы паролей;

2) получением разрешений от администратора базы данных (АБД);

3) запретом от АБД на доступ к данным;

4) формирование видов — таблиц, производных от исходных и предназначенных конкретным пользователям.

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

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

Представляет интерес эволюция концепции баз данных .

Первоначально (начало 60-х годов) использовалась файловая система хранения. Для решения преимущественно инженерных задач, характеризующихся небольшим количеством данных и значительным объемом вычислений, данные хранились непосредственно в программе. Применялся последовательный способ организации данных, имелась их высокая избыточность, идентичность логической и физической структур и полная зависимость данных. С появлением экономико-управленческих задач (информационная система руководства — MIS), отличающихся большими объемами данных и малой долей вычислений, указанная организация данных оказалась неэффективной. Требовалось упорядочение данных, которое, как выяснилось, возможно было проводить по двум критериям: использование (информационные массивы); хранение (базы данных). Первоначально применяли информационные массивы, но вскоре стало ясно превосходство баз данных. Использование файлов для хранения только данных (рис. 2.1, а) было предложено Мак Гри в 1959 году. Были разработаны методы доступа (в том числе произвольного) к таким файлам, при этом физическая и логическая структуры уже различались, а физическое расположение данных можно было менять без изменения логического представления.

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

Фактически начала использоваться (рис. 2.1, б) современная архитектура базы данных. Под архитектурой понимается разновидность (обобщение) структуры, в которой какой-либо элемент может быть заменен на другой элемент, характеристики входов и выходов которого идентичны первому элементу. Существенный скачок в развитии технологии баз данных дала предложенная М. Коддом в 1970 году парадигма реляционной модели данных. Под парадигмой понимается научная теория, воплощенная в систему понятий, отражающих существенные черты действительности. Теперь логические структуры могли быть получены из одних и тех же физических данных, т.е. доступ к одним и тем же физическим данным мог осуществляться различными приложениями по разным путям. Стало возможным обеспечение целостности и независимости данных.

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

Смотрите так же:  Последнее завещание каддафи

Прежде чем рассматривать процедуры работы с базой данных, дадим набор характеристик БД (рис. 2.2) и пояснения к нему.

Существует два подхода к построению БД, базирующихся на двух подходах к созданию автоматизированной системы управления (АСУ).

Первый из них, широко использовавшийся в 80-е годы и потому получивший название классического (традиционного), связан с автоматизацией документооборота (совокупность документов, движущихся в процессе работы предприятия). Исходными и выходными координатами являлись документы, как это видно из примера 2.1.

Пример 2.1. Задача ставится следующим образом. Имеется система ручных документов, форма одного из которых показана в табл. 2.1.

Данные о поставках

Отчет о поставках за квартал

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

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

К 90-м годам сформировался второй, современный подход, связанный с автоматизацией управления. Он предполагает первоначальное выявление стандартных алгоритмов приложений (алгоритмов бизнеса в зарубежной терминологии), под которые определяются данные, а стало быть, и база данных. Объектно-ориентированное программирование только усилило значимость этого подхода. Состав БД для различных подходов представлен на рис. 2.3.

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

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

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

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

Существует много разновидностей методологии рассмотрения баз данных в классическом подходе , однако чаще всего придерживаются методологии ANSI/SPARC, схема которой представлена на рис. 2.5.

На рис. 2.5 показана совокупность процедур проектирования централизованной БД, которые можно объединить в четыре этапа.

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

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

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

В процессе логического проектирования высокоуровневое представление данных преобразуется в структуру используемой СУБД. Основной целью этапа является устранение избыточности данных с использованием специальных правил нормализации (рис. 2.4). Цель нормализации — минимизировать повторения данных и возможные структурные изменения БД при процедурах обновления. Это достигается разделением (декомпозицией) одной таблицы в две или несколько с последующим использованием при запросах операции навигации. Заметим, что навигационный поиск снижает быстродействие БД, т.е. увеличивает время отклика на запрос. Полученная логическая структура БД может быть оценена количественно с помощью различных характеристик (число обращений к логическим записям, объем данных в каждом приложении, общий объем данных). На основе этих оценок логическая структура может быть усовершенствована с целью достижения большей эффективности.

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

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

На этапе физического проектирования решаются вопросы, связанные с производительностью системы, определяются структуры хранения данных и методы доступа.

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

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

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

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

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

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

Основными причинами низкой эффективности проектируемых БД могут быть:

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

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

В этих условиях важное значение приобретают вопросы автоматизации разработки.

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

В БД имеется три уровня представления данных (рис. 2.4): концептуальная, логическая и физическая базы данных.

В процедуре использования чаще всего имеют дело с логической и — значительно реже — с концептуальной и физической моделью.

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

В логическом представлении применяются следующие виды моделей данных: иерархические, сетевые, реляционные, объектно-ориентированные (объектно-реляционные).

Иерархическая модель является разновидностью сетевой, являющейся совокупностью деревьев (лесом).

Сетевая модель является моделью объектов-связей, допускающей только бинарные связи «многие к одному», и использует для описания модель ориентированных графов.

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

В объектно-ориентированной модели используются понятия класса, объекта, метода.

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

В общем случае процесс запроса состоит из ряда этапов (И1 — И2 на рис. 2.4). Пользователь должен знать структуру БД или обратиться к АБД.

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

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

При эксплуатации БД используют и две специфические операции: навигацию и спецификацию.

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

Спецификация — операция, результатом которой является новая структура (таблица), построенная на основе структур таблиц базы данных. Эта таблица получила название «вид».

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

Существует два основных направления реализации СУБД: программное и аппаратное.

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

Аппаратная реализация предусматривает использование и так называемых машин баз данных (МБД). Их появление вызвано возросшими объемами информации и требованиями к скорости доступа.

Таким образом, в соответствии с рис. 2.4, 2.5 теоретические вопросы можно скомпоновать в две группы (рис. 2.6).

Общая теория баз данных. Сюда относятся вопросы, не зависящие от моделей данных:

а) математический аппарат баз данных (глава 3);

б) описание структуры БД, в том числе различных МД с их сравнительными характеристиками, выбор МД, структурные преобразования БД.

Теория реляционных БД (глава 4). Для них наиболее продвинута прикладная математическая теория БД. Она включает три фактически автономных раздела (рис. 2.6):

а) организация структур таблиц БД (прежде всего нормирование), их заполнение и обеспечение составляющих целостности — при проектировании БД;

б) обеспечение целостности данных и их восстановление за счет соответствующих характеристик СУБД — в процессе работы СУБД;

в) организация запросов и обновления данных — при эксплуатации БД.

В дальнейшем изложении материала будем руководствоваться рис. 2.6.