Основные понятия баз данных | Определение основных терминов Дадим определения основных терминов. В качестве составных частей схемы выделяются информация (входная и выходная) и правила ее преобразования. Правила могут быть в виде алгоритмов, процедур и эвристических последовательностей. - последовательность правил перехода от исходных данных к результату. Правила могут выполняться компьютером или человеком. - совокупность объективных сведений. Данные Информация- сведения, неизвестные ранее получателю информации, пополняющие его знания, подтверждающие или опровергающие положения и соответствующие убеждения. Информация носит субъективный характер и определяется уровнем знаний субъекта и степенью его восприятия. Информация извлекается субъектом из соответствующих данных. - совокупность фактов, закономерностей и эвристических правил, с помощью Знания которых решается поставленная задача. Алгоритм КОДАСИЛ (CODASYL) Кортеж Объект Сущность - набор стандартов для сетевых БД. - совокупность полей или запись. - термин, обозначающий факт, лицо, событие, предмет, о котором могут быть собраны данные. - примитивный объект данных, отображающий элемент предметной области (человек, место, вещь и т.д.). Под базой данных (БД) понимают совокупность хранящихся вместе данных при наличии такой минимальной избыточности, которая допускает их использование оптимальным образом для одного или нескольких приложений. Целью создания баз данных, как разновидности информационной технологии и формы хранения данных, является построение системы данных, не зависящих от принятых алгоритмов (программного обеспечения), применяемых технических средств и физического расположения данных в ЭВМ; обеспечивающих непротиворечивую и целостную информацию при нерегламентируемых запросах. БД предполагает многоцелевое ее использование (несколько пользователей, множество форм документов и запросов одного пользователя). База знаний (БЗ) представляет собой совокупность БД и используемых правил, полученных от лиц, принимающих решения (ЛПР). Базы данных (БД) - это именованная совокупность данных, отображающая состояние объектов и их отношения в рассматриваемой предметной области. Характерной чертой баз данных является постоянство: данные постоянно накапливаются и используются; состав и структура данных, необходимы для решения тех или иных прикладных задач, обычно постоянны и стабильны во времени; отдельные или даже все элементы данных могут меняться - но и это есть проявления постоянства - постоянная актуальность. - это совокупность языковых и программных средств, предназначенных для Система создания, ведения и совместного использования БД многими управления пользователями. базами данных (СУБД) Иногда в составе банка данных выделяют архивы. Основанием для этого является особый режим использования данных, когда только часть данных находится под оперативным управлением СУБД. Все остальные данные обычно располагаются на носителях, оперативно не управляемых СУБД. Одни и те же данные в разные моменты времени могут входить как в базы данных, так и в архивы. Банки данных могут не иметь архивов, но если они есть, то в состав банка данных может входить и система управления архивами. Эффективное управление внешней памятью являются основной функцией СУБД. Эти обычно специализированные средства настолько важны с точки зрения эффективности, что при их отсутствии система просто не сможет выполнять некоторые задачи уже по тому, что их выполнение будет занимать слишком много времени. При этом ни одна из таких специализированных функций не является видимой для пользователя. Они обеспечивают независимость между логическим и физическим уровнями системы: прикладной программист не должен писать программы индексирования, распределять память на диске и т. д. Основные требования, предъявляемые к банкам данных Основные требования, предъявляемые к банкам данных, можно сформулировать так: Многократное использование данных: пользователи должны иметь возможность использовать данные различным образом. Простота: пользователи должны иметь возможность легко узнать и понять, какие данные имеются в их распоряжении. Легкость использования: пользователи должны иметь возможность осуществлять (процедурно) простой доступ к данным, при этом все сложности доступа к данным должны быть скрыты в самой системе управления базами данных. Гибкость использования: обращение к данным или их поиск должны осуществляться с помощью различных методов доступа. Быстрая обработка запросов на данные: запросы на данные, должны обрабатываться с помощью высокоуровневого языка запросов, а не только прикладными программами, написанными с целью обработки конкретных запросов. Язык взаимодействия конечных пользователей с системой должен обеспечивать конечным пользователям возможность получения данных без использования прикладных программ. База данных - это основа для будущего наращивания прикладных программ: базы данных должны обеспечивать возможность быстрой и дешевой разработки новых приложений. Сохранение затрат умственного труда: существующие программы и логические структуры данных не должны переделываться при внесении изменений в базу данных. Наличие интерфейса прикладного программирования: прикладные программы должны иметь возможность просто и эффективно выполнять запросы на данные; программы должны быть изолированными от расположения файлов и способов адресации данных. Распределенная обработка данных: система должна функционировать в условиях вычислительных сетей и обеспечивать эффективный доступ пользователей к любым данным распределенной БД, размещенным в любой точке сети. Адаптивность и расширяемость: база данных должна быть настраиваемой, причем настройка не должна вызывать перезаписи прикладных программ. Кроме того, поставляемый с СУБД набор предопределенных типов данных должен быть расширяемым - в системе должны иметься средства для определения новых типов и не должно быть различий в использовании системных и определенных пользователем типов. Контроль целостности данных: система должна осуществлять контроль ошибок в данных и выполнять проверку взаимного логического соответствия данных. Восстановление данных после сбоев: автоматическое восстановление без потери данных транзакции. В случае аппаратных или программных сбоев система должна возвращаться к некоторому согласованному состоянию данных. Вспомогательные средства должны позволять разработчику или администратору базы данных предсказать и оптимизировать производительность системы. Автоматическая реорганизация и перемещение: система должна обеспечивать возможность перемещения данных или автоматическую реорганизацию физической структуры. Компоненты банка данных Определение банка данных предполагает, что с функционально-организационной точки зрения банк данных является сложной человеко-машинной системой, включающей в себя все подсистемы, необходимые для надежного, эффективного и продолжительного во времени функционирования. В структуре банка данных выделяют следующие компоненты: Информационная база; Лингвистические средства; Программные средства; Технические средства; Организационно-административные подсистемы и нормативно-методическое обеспечение. Организационно-методические средства - это совокупность инструкций, методических и регламентирующих материалов, описаний структуры и процедуры работы пользователя с СУБД и БД. Пользователи БД и СУБД Пользователей (СУБД) можно разделить на две основные категории: конечные пользователи; администраторы баз данных. В обязанности АБД входит: 1. анализ предметной области, статуса информации и пользователей; 2. проектирование структуры и модификация данных; 3. задание и обеспечение целостности; 4. загрузка и ведение БД; 5. защита данных; 6. обеспечение восстановления БД; 7. сбор и статистическая обработка обращений к БД, анализ эффективности функционирования БД; 8. работа с пользователем. Классификация БД и СУБД Классификация - разделение множества на подмножества по неформально предложенному признаку. В силу многогранности баз данных и СУБД (комплекса технических и программных средств, для хранения, поиска, защиты и использования данных) имеется множество классификационных признаков. Классификация БД по основным признакам приведена на рис. 2.1. Рис. 2.1. Классификация баз данных Базы данных могут классифицироваться и с точки зрения экономической: по условиям предоставления услуг - бесплатные и платные (бесприбыльные, коммерческие); по форме собственности - государственные, негосударственные; по степени доступности - общедоступные, с ограниченным кругом пользователей. По технологии обработки данных БД делятся на централизованные БД и распределённые БД. Централизованная БД хранится в памяти одной вычислительной системы (применяется в локальных сетях ПК). Централизованные БД могут быть с сетевым доступом. Архитектуры систем централизованных БД с сетевым доступом подразделяются на файлсервер и клиент-сервер. Рис. 2.2. БД с сетевым доступом (Файл-сервер) Архитектура систем БД с сетевым доступом (Файл-сервер) как показано на рис. 2.2 предполагает выделение одной из машин сети в качестве центральной (сервер файлов). На ней хранится совместно используемая централизованная БД. Все другие машины сети являются рабочими станциями. Файлы БД в соответствии с пользовательскими запросами передаются на рабочие станции, где и производится обработка. При большой интенсивности доступа к одним и тем же данным производительность системы падает. Рис. 2.3. БД с сетевым доступом Клиент - сервер В архитектуре Клиент-сервер ( рис. 2.3) подразумевается, что помимо хранения централизованной БД центральная машина (сервер базы данных) должна обеспечивать выполнение основного объёма обработки данных. Запрос на данные клиента, порождает поиск и извлечение данных на сервере. Извлечённые данные (но не файлы) транспортируются по сети от сервера к клиенту. Распределённая БД состоит из нескольких частей, хранимых в различных ЭВМ вычислительной сети (работа с такой БДпроисходит с помощью СУБД). По способу доступа к данным БД разделяются на БД с локальным и удаленным доступом. БД с локальным доступом называется, если эта вычислительная система является компонентом сети ЭВМ, возможен распределённый доступ к такой базе. Такой способ использования БД часто применяют в локальных сетях ПК. БД с удалённым (сетевым) доступом называется когда, части БД могут пересекаться или даже дублироваться, но хранятся в различных ЭВМ вычислительной сети. Классификация СУБД Система управления базами данных (СУБД) - это совокупность языковых и программных средств, предназначенных для создания, ведения и совместного использования БД многими пользователями. Системы управления базами данных следует классифицировать отдельно ( рис. 2.4). Рис. 2.4. Классификация СУБД Состав СУБД и работа БД СУБД представляет собой оболочку, с помощью которой при организации структуры таблиц и заполнения их данными получается та или иная база данных. В связи с этим полезно поговорить о системе программно-технических, организационных и "человеческих" составляющих ( рис. 2.5). Программные средства включают систему управления, обеспечивающую ввод-вывод, обработку и хранение информации, создание, модификацию и тестирование БД, трансляторы. Рис. 2.5. Состав СУБД Базовыми внутренними языками программирования являются языки четвертого поколения. В качестве базовых языков могут использоваться C, C++, Pascal, Object Pascal. Следует отметить, что исторически для системы управления базой данных сложились три языка: 1. язык описания данных (ЯОД), называемый также языком описания схем, - для построения структуры ("шапки") таблиц БД; 2. язык манипулирования данными (ЯМД) - для заполнения БД данными и операций обновления (запись, удаление, модификация); 3. язык запросов - язык поиска наборов величин в файле в соответствии с заданной совокупностью критериев поиска и выдачи затребованных данных без изменения содержимого файлов и БД (язык преобразования критериев в систему команд). В настоящее время функции всех трех языков выполняет язык SQL, относящийся к классу языков, базирующихся на исчислении кортежей ) Основные функции СУБД 1. Непосредственное управление данными во внешней памяти Эта функция включает обеспечение необходимых структур внешней памяти как для хранения данных, непосредственно входящих в БД, так и для служебных целей, например, для ускорения доступа к данным в некоторых случаях. 2. Управление буферами оперативной памяти СУБД обычно работают с БД значительного размера; по крайней мере, этот размер обычно существенно больше доступного объема оперативной памяти. Понятно, что если при обращении к любому элементу данных будет производиться обмен с внешней памятью, то вся система будет работать со скоростью устройства внешней памяти. Практически единственным способом реального увеличения этой скорости является буферизация данных в оперативной памяти. При этом, даже если операционная система производит общесистемную буферизацию (как в случае ОС UNIX), этого недостаточно для целей СУБД, которая располагает гораздо большей информацией о полезности буферизации той или иной части БД. Поэтому в развитых СУБДподдерживается собственный набор буферов оперативной памяти с собственной дисциплиной замены буферов. 3. Управление транзакциями Транзакция - это последовательность операций над БД, рассматриваемых СУБД как единое целое. Либо транзакция успешно выполняется, и СУБД фиксирует изменения БД, произведенные этой транзакцией, во внешней памяти, либо ни одно из этих изменений никак не отражается на состоянии БД. 4. Журнализация Одним из основных требований к СУБД является надежность хранения данных во внешней памяти. Под надежностью хранения понимается то, что СУБД должна быть в состоянии восстановить последнее согласованное состояние БД после любого аппаратного или программного сбоя. Обычно рассматриваются два возможных вида аппаратных сбоев: так называемые мягкие сбои, которые можно трактовать как внезапную остановку работы компьютера (например, аварийное выключение питания), и жесткие сбои, характеризуемые потерей информации на носителях внешней памяти. В любом случае для восстановления БД нужно располагать некоторой дополнительной информацией. Другими словами, поддержание надежности хранения данных в БД требует избыточности хранения данных, причем та часть данных, которая используется для восстановления, должна храниться особо надежно. Наиболее распространенным методом поддержания такой избыточной информации является ведение журнала изменений БД. Журнал - это особая часть БД, недоступная пользователям СУБД и поддерживаемая с особой тщательностью (иногда поддерживаются две копии журнала, располагаемые на разных физических дисках), в которую поступают записи обо всех изменениях основной части БД 5. Поддержка языков БД В современных СУБД обычно поддерживается единый интегрированный язык, содержащий все необходимые средства для работы с БД, начиная от ее создания, и обеспечивающий базовый пользовательский интерфейс с базами данных. Стандартным языком наиболее распространенных в настоящее время реляционных СУБД является язык запросов SQL (Structured Query Language). Язык SQL содержит специальные средства определения ограничений целостности БД. Опять же, ограничения целостностихранятся в специальных таблицах-каталогах, и обеспечение контроля целостности БД производится на языковом уровне, т.е. при компиляции операторов модификации БД компилятор SQL на основании имеющихся в БД ограничений целостности генерирует соответствующий программный код. Специальные операторы языка SQL позволяют определять так называемые представления БД, фактически являющиеся хранимыми в БД запросами (результатом любого запроса к реляционной БД является таблица) с именованными столбцами. Для пользователяпредставление является такой же таблицей, как любая базовая таблица, хранимая в БД, но с помощью представлений можно ограничить или наоборот расширить видимость БД для конкретного пользователя. Поддержание представлений производится также на языковом уровне. Наконец, авторизация доступа к объектам БД производится также на основе специального набора операторов SQL. Идея состоит в том, что для выполнения операторов SQL разного вида пользователь должен обладать различными полномочиями. Пользователь, создавший таблицу БД, обладает полным набором полномочий для работы с этой таблицей. В число этих полномочий входит полномочие на передачу всех или части полномочий другим пользователям, включая полномочие на передачу полномочий. Полномочия пользователей описываются в специальных таблицах-каталогах, контроль полномочий поддерживается на языковом уровне. Функциональные возможности СУБД По степени универсальности различают два класса СУБД: системы общего назначения - реализованные как программный продукт, способный функционировать на ЭВМ в определённой операционной системе и поставляемый пользователям как коммерческое изделие; специализированные системы - создаваемые в случаях невозможности или не целесообразности использования СУБД общего назначения. СУБД общего назначения - это сложные программные комплексы, предназначенные для выполнения всей совокупности функций, связанных с созданием и эксплуатацией БД информационной системы. Рынок программного обеспечения ПК располагает большим числом разнообразных по своим функциональным возможностям коммерческих систем СУБД общего назначения. Производительность СУБД оценивается: временем выполнения запросов; скоростью поиска информации; временем выполнения операций импортирования данных из других форматов; скоростью выполнения таких операций как обновления, вставка, удаление данных; максимальным числом параллельных обращений к данным в многопользовательском режиме; временем генерации отчёта. На производительность СУБД оказывают влияния 2 фактора: правильное проектирование построения БД. СУБД, которые следят за соблюдением целостности данных, несут дополнительную нагрузку, которую не испытывают другие программы; Целостность данных подразумевает наличие средств, позволяющих удостовериться, что информация в БД всегда остаётся корректной и полной. Операции, обеспечивающие безопасность: шифрование прикладных программ; шифрование данных; защита паролем; ограничение уровня доступа Для сохранения информации используется двойной подход. Некоторые операции сохранения происходят в обход операционной системы Целостность должна обеспечиваться независимо от того, каким образом данные заносятся в память, не конкретных действий пользователей, пробоев сети и т.п. Он предусматривает назначение паролей для индивидуальных пользователей или групп пользователей и присвоение различных прав доступа отдельно таблицам, запросам, отчётам на уровне пользователя или группы. Проектирование баз данных Подходы к проектированию В конце 70-х годов появились современные СУБД, обеспечивающие физическую и логическую независимость, безопасность данных, обладающие развитыми языками БД. Последнее десятилетие характеризуется появлением распределенных и объектно-ориентированных баз данных, характеристики которых определяются приложениями средств автоматизации проектирования иинтеллектуализации БД ( рис. 3.1). Существует два подхода к построению БД, базирующихся на двух подходах к созданию автоматизированной системы управления(АСУ). Первый из них, широко использовался в 80-е годы и потому получил название классического (традиционного), связано это с автоматизацией документооборота (совокупность документов, движущихся в процессе работы предприятия). Исходными и выходными координатами являлись документы. Рис. 3.1. Характеристики БД К 90-м годам сформировался второй, современный подход, связанный с автоматизацией управления. Он предполагает первоначальное выявление стандартных алгоритмов приложений (алгоритмов бизнеса в зарубежной терминологии), под которые определяются данные, а стало быть, и база данных. Объектно-ориентированное программирование только усилило значимостьэтого подхода. Состав БД для различных подходов представлен на рис. 3.2. Рис. 3.2. Схемы (а) классического и (б) современного подходов при построении БД В работе БД возможен одно- и многопользовательский (несколько пользователей подключаются к одному компьютеру через разные порты) режимы. Используют восходящее и нисходящее проектирование БД. Первое применяют в распределенных БД при интеграции спроектированных локальных баз данных, которые могут быть выполнены с использованием различных моделей данных. Более характерным для централизованных БД является нисходящее проектирование. Работа с базами данных может быть представлена в виде схемы, показанной на рис. 3.3. Из нее видно, что следует выделять методологию создания и методологию использования БД. Методология БД определяется в процедуре проектирования, но проявляется и в процедуре использования. Рис. 3.3. Схема создания использования БД Архитектура СУБД СУБД имеет многоуровневую структуру, в которой реализуется принцип относительной независимости логической и физическойорганизации данных ( рис. 3.4). Рис. 3.4. Структура СУБД Различают концептуальный, внутренний и внешний уровни представления данных БД, которым соответствуют модели аналогичного назначения. Концептуальная модель состоит из множества экземпляров различных типов данных, имеющих структуру в соответствии с требованиями СУБД к логической структуре БД. СУБД имеет два режима работы: проектировочный - предназначен для создания или изменения структуры базы и создания её объектов; пользовательский - использование ранее подготовленных объектов для наполнения базы или получения данных из нее. Проектирование БД состоит в построении комплекса взаимосвязанных моделей данных. Методология проектирования баз данных Существует много разновидностей методологии рассмотрения баз данных в классическом подходе, однако чаще всего придерживаются методологии ANSI/SPARC, схема которой представлена на рис. 3.5. На рис. 3.5 показана совокупность процедур проектирования централизованной БД, которые можно объединить в четыре этапа. Рис. 3.5. Схема этапов проектирования БД На этапе формулирования и анализа требований устанавливаются цели организации, определяются требования к БД. Они состоят из общих требований, определенных выше, и специфических требований. Этап концептуального проектирования заключается в описании и синтезе информационных требований пользователей в первоначальный проект БД. Исходными данными могут быть совокупность документов пользователя ( рис. 3.3) при классическом подходе или алгоритмы приложений (алгоритмы бизнеса) при современном подходе. Результатом этого этапа является высокоуровневое представление (в виде системы таблиц БД) информационных требований пользователей на основе различных подходов. Сначала выбирается модель БД. Затем с помощью ЯОД создается структура БД, которая заполняется данными с помощью команд ЯМД, систем меню, экранных форм или в режиме просмотра таблиц БД. Здесь же обеспечивается защита и целостность (в том числе ссылочная) данных с помощью СУБД или путем построения триггеров. В процессе логического проектирования высокоуровневое представление данных преобразуется в структуру используемой СУБД. Основной целью этапа является устранение избыточности данных с использованием специальных правил нормализации. Цель нормализации - минимизировать повторения данных и возможные структурные изменения БД при процедурах обновления. Это достигается разделением (декомпозицией) одной таблицы в две или несколько с последующим использованием при запросахоперации навигации. Полученная логическая структура БД может быть оценена количественно с помощью различных характеристик (число обращений к логическим записям, объем данных в каждом приложении, общий объем данных). На основе этих оценок логическая структура может быть усовершенствована с целью достижения большей эффективности. Специального обсуждения заслуживает процедура управления БД. Она наиболее проста в однопользовательском режиме. В многопользовательском режиме и в распределенных БД процедура сильно усложняется. При одновременном доступе нескольких пользователей без принятия специальных мер, возможно, нарушение целостности. Для устранения этого явления используют систему транзакций и режим блокировки таблиц или отдельных записей. Транзакция - процесс изменения файла, записи или базы данных, вызванный передачей одного входного сообщения. На этапе физического проектирования решаются вопросы, связанные с производительностью системы, определяются структуры хранения данных и методы доступа. Взаимодействие между этапами проектирования и словарной системой необходимо рассматривать отдельно. Процедуры проектирования могут использоваться независимо в случае отсутствия словарной системы. Сама словарная система может рассматриваться как элемент автоматизации проектирования. Существует много критериев оптимальности, являющихся неизмеримыми свойствами, трудно выразимыми в количественном представлении или в виде целевой функции. К качественным критериям могут относиться гибкость, адаптивность, доступность для новых пользователей, совместимость с другими системами, возможность конвертирования в другую вычислительную среду, возможность восстановления, возможность распределения и расширения. Основные этапы разработки БД Этап 1. Уточнение задач На первом этапе составляется список всех основных задач, которые в принципе должны решаться этим приложением, - включая и те, которые не нужны сегодня, но могут появиться в будущем. Под "основными" задачами понимаются функции, которые должны быть представлены в формах или отчетах приложения. Этап 2. Последовательность выполнения задач Для того, чтобы приложение работало логично и удобно, лучше всего объединить основные задачи в тематические группы и затем упорядочить задачи каждой группы так, чтобы они располагались в порядке их выполнения. Может получиться так, что некоторые задачи будут связаны с разными группами или, что выполнение некоторой задачи должно предшествовать выполнению другой, принадлежащей к иной группе. Этап 3. Анализ данных После формирования списка задач, наиболее важным этапом является составление подробного перечня всех данных, необходимых для решения каждой задачи. Некоторые данные понадобятся в качестве исходных и меняться не будут. Другие данные будут проверяться и изменяться в ходе выполнения задачи. Некоторые элементы данных могут быть удалены или добавлены. И наконец, некоторые данные будут получены с помощью вычислений: их вывод будет частью задачи, но в базу данных вноситься они не будут. Этап 4. Определение структуры данных После предварительного анализа всех необходимых элементов данных нужно упорядочить их по объектам и соотнести объекты с таблицами и запросами базы данных. Для реляционных баз данных типа Access используется процесс, называемый нормализацией, в результате которого вырабатывается наиболее эффективный и гибкий способ хранения данных. Этап 5. Разработка макета приложения и пользовательского интерфейса После задания структуры таблиц приложения, в Microsoft Access легко создать его макет с помощью форм и связать их между собой, используя несложные макросы или процедуры обработки событий. Этап 6. Создание приложения В случае очень простых задач созданный макет является практически законченным приложением. Однако довольно часто приходится писать процедуры, позволяющие полностью автоматизировать решение всех намеченных в проекте задач. Поэтому, понадобится создать специальные связующие формы, которые обеспечивают переход от одной задачи к другой. Этап 7. Тестирование и усовершенствование После завершения работ по отдельным компонентам приложения необходимо проверить функционирование приложения в каждом из возможных режимов. Необходимо проверить работу макросов, для этого использовав пошаговый режим отладки, при котором будет выполняться одна конкретная макрокоманда. Модели организации баз данных Различают три основные модели базы данных - это иерархическая, сетевая и реляционная. Эти модели отличаются между собой по способу установления связей между данными. 1. Иерархический подход к организации баз данных. Иерархические базы данных имеют форму деревьев с дугами-связями и узлами-элементами данных. Иерархическая структура предполагала неравноправие между данными - одни жестко подчинены другим. Подобные структуры, безусловно, четко удовлетворяют требованиям многих, но далеко не всех реальных задач. 2. Сетевая модель данных. В сетевых БД наряду с вертикальными реализованы и горизонтальные связи. Однако унаследованы многие недостатки иерархической и главный из них, необходимость четко определять на физическом уровне связи данных и столь же четко следовать этой структуре связей при запросах к базе. 3. Реляционная модель. Реляционная модель появилась вследствие стремления сделать базу данных как можно более гибкой. Данная модель предоставила простой и эффективный механизм поддержания связей данных. Во-первых, все данные в модели представляются в виде таблиц и только таблиц. Реляционная модель - единственная из всех обеспечивает единообразие представления данных. И сущности, и связи этих самых сущностей представляются в модели совершенно одинаково - таблицами. Правда, такой подход усложняет понимание смысла хранящейся в базе данных информации, и, как следствие, манипулирование этой информацией. Избежать трудностей манипулирования позволяет второй элемент модели - реляционно-полный язык .Полнота языка в приложении к реляционной модели означает, что он должен выполнять любую операцию реляционной алгебры или реляционного исчисления. Более того, язык должен описывать любой запрос в виде операций с таблицами, а не с их строками. Одним из таких языков является SQL. Третий элемент реляционной модели требует от реляционной модели поддержания некоторых ограничений целостности. Одно из таких ограничений утверждает, что каждая строка в таблице должна иметь некий уникальный идентификатор, называемый первичным ключом. Второе ограничение накладывается на целостность ссылок между таблицами. Оно утверждает, что атрибуты таблицы, ссылающиеся на первичные ключи других таблиц, должны иметь одно из значений этих первичных ключей. 4. Объектно-ориентированная модель. Новые области использования вычислительной техники, такие как научные исследования, автоматизированное проектирование и автоматизация учреждений, потребовали от баз данных способности хранить и обрабатывать новые объекты - текст, аудио- и видеоинформацию, а также документы. Основные трудности объектно-ориентированного моделирования данных проистекают из того, что такого развитого математического аппарата, на который могла бы опираться общая объектноориентированная модель данных, не существует. В большой степени, поэтому до сих пор нет базовой объектно-ориентированной модели. Рассмотрим более подробно эти модели данных далее. Иерархическая модель базы данных Иерархические базы данных - самая ранняя модель представления сложной структуры данных. Информация в иерархической базе организована по принципу древовидной структуры, в виде отношений "предок-потомок". Каждая запись может иметь не более одной родительской записи и несколько подчиненных. Связи записей реализуются в виде физических указателей с одной записи на другую. Основной недостаток иерархической структуры базы данных невозможность реализовать отношения "многие-ко-многим", а также ситуации, когда запись имеет несколько предков. Иерархические базы данных. Иерархические базы данных графически могут быть представлены как перевернутое дерево, состоящее из объектов различных уровней. Верхний уровень (корень дерева) занимает один объект, второй - объекты второго уровня и так далее. Между объектами существуют связи, каждый объект может включать в себя несколько объектов более низкого уровня. Такие объекты находятся в отношении предка (объект, более близкий к корню) к потомку (объект более низкого уровня), при этомобъект-предок может не иметь потомков или иметь их несколько, тогда как объект-потомок обязательно имеет только одного предка. Объекты, имеющие общего предка, называются близнецами. Корневая запись каждого дерева обязательно должна содержать ключ с уникальным значением. Ключи некорневых записей должны иметь уникальное значение только в рамках группового отношения. Каждая запись идентифицируется полным сцепленным ключом, под которым понимается совокупность ключей всех записей от корневой, по иерархическому пути. При графическом изображении групповые отношения изображают дугами ориентированного графа, а типы записей - вершинами (диаграмма Бахмана). Для групповых отношений в иерархической модели обеспечивается автоматический режим включения и фиксированное членство. Это означает, что для запоминания любой некорневой записи в БД должна существовать ее родительская запись. Операции над данными, определенные в иерархической модели: Добавить в базу данных новую запись. Для корневой записи обязательно формирование значения ключа. Изменить значение данных предварительно извлеченной записи. Ключевые данные не должны подвергаться изменениям. Удалить некоторую запись и все подчиненные ей записи. Извлечь корневую запись по ключевому значению, допускается также последовательный просмотр корневых записей. Извлечь следующую запись (следующая запись извлекается в порядке левостороннего обхода дерева). В операции ИЗВЛЕЧЬ допускается задание условий выборки (например, извлечь сотрудников с окладом более 10 тысяч руб.) Как видим, все операции изменения применяются только к одной "текущей" записи (которая предварительно извлечена из базы данных). Такой подход к манипулированию данных получил название "навигационного". Ограничения целостности Поддерживается только целостность связей между владельцами и членами группового отношения (никакой потомок не может существовать без предка). Как уже отмечалось, не обеспечивается автоматическое поддержание соответствия парных записей, входящих в разные иерархии. Сетевая модель базы данных Сетевая модель данных определяется в тех же терминах, что и иерархическая. Она состоит из множества записей, которые могут быть владельцами или членами групповых отношений. Связь между записью-владельцем и записью-членом также имеет вид 1:N. Основное различие этих моделей состоит в том, что в сетевой модели запись может быть членом более чем одного группового отношения. Согласно этой модели каждое групповое отношение именуется и проводится различие между его типом и экземпляром. Тип группового отношения задается его именем и определяет свойства общие для всех экземпляров данного типа. Экземпляр группового отношения представляется записью-владельцем и множеством (возможно пустым) подчиненных записей. При этом имеется следующее ограничение: экземпляр записи не может быть членом двух экземпляров групповых отношений одного типа (т.е. сотрудник из примера в п..1, например, не может работать в двух отделах). Иерархическая структура рис. 4.2 преобразовывается в сетевую модель, следующим образом (см. рис. 4.3): деревья (a) и (b), показанные на рис. 4.2, заменяются одной сетевой структурой, в которой запись СОТРУДНИК входит в два групповых отношения; для отображения типа M:N вводится запись СОТРУДНИК_КОНТРАКТ, которая не имеет полей и служит только для связи записей КОНТРАКТ и СОТРУДНИК, (см. рис. 4.3). Отметим, что в этой записи может храниться и полезная информация, например, доля данного сотрудника в общем вознаграждении по данному контракту. Рис. 4.3. Сетевая модель базы данных Каждый экземпляр группового отношения характеризуется следующими признаками: Способ упорядочения подчиненных записей: произвольный, хронологический /очередь/, обратный хронологический /стек/, сортированный. Если запись объявлена подчиненной в нескольких групповых отношениях, то в каждом из них может быть назначен свой способ упорядочивания. Режим включения подчиненных записей: автоматический - невозможно занести в БД запись без того, чтобы она была сразу же закреплена за неким владельцем; ручной - позволяет запомнить в БД подчиненную запись и не включать ее немедленно в экземпляр группового отношения. Эта операция позже инициируется пользователем. Режим исключения. Принято выделять три класса членства подчиненных записей в групповых отношениях: Фиксированное. Подчиненная запись жестко связана с записью владельцем и ее можно исключить из группового отношения только удалив. При удалении записи-владельца все подчиненные записи автоматически тоже удаляются. Обязательное. Допускается переключение подчиненной записи на другого владельца, но невозможно ее существование без владельца. Для удаления записи-владельца необходимо, чтобы она не имела подчиненных записей с обязательным членством. Необязательное. Можно исключить запись из группового отношения, но сохранить ее в базе данных не прикрепляя к другому владельцу. При удалении записи-владельца ее подчиненные записи - необязательные члены сохраняются в базе, не участвуя более в групповом отношении такого типа. Операции над данными в сетевой модели БД Добавить - внести запись в БД и, в зависимости от режима включения, либо включить ее в групповое отношение, где она объявлена подчиненной, либо не включать ни в какое групповое отношение. Включить в групповое отношение - связать существующую подчиненную запись с записью-владельцем. Переключить - связать существующую подчиненную запись с другой записью-владельцем в том же групповом отношении. Обновить - изменить значение элементов предварительно извлеченной записи. Извлечь - извлечь записи последовательно по значению ключа, а также используя групповые отношения - от владельца можно перейти к записям - членам, а от подчиненной записи к владельцу набора. Удалить - убрать из БД запись. Если эта запись является владельцем группового отношения, то анализируется класс членства подчиненных записей. Обязательные члены должны быть предварительно исключены из группового отношения, фиксированные удалены вместе с владельцем, необязательные останутся в БД. Исключить из группового отношения - разорвать связь между записью-владельцем и записью-членом. Ограничения целостности Как и в иерархической модели обеспечивается только поддержание целостности по ссылкам (владелец отношения - член отношения). Достоинства и недостатки ранних СУБД Достоинства ранних СУБД: развитые средства управления данными во внешней памяти на низком уровне; возможность построения вручную эффективных прикладных систем; возможность экономии памяти за счет разделения подобъектов (в сетевых системах) Недостатки ранних СУБД: сложность использования; высокий уровень требований к знаниям о физической организации БД; зависимость прикладных систем от физической организации БД; перегруженность логики прикладных систем деталями организации доступа к БД. Как иерархическая, так и сетевая модель данных предполагает наличие высококвалифицированных программистов. И даже в таких случаях реализация пользовательских запросов часто затягивается на длительный срок. Объектно-ориентированные СУБД любая модель данных должна включать три аспекта: структурный, целостный и манипуляционный. Посмотрим, как они реализуются на основе объектноориентированная парадигмы программирования. Структура Структура объектной модели описывается с помощью трех ключевых понятий: инкапсуляция- каждый объект обладает некоторым внутренним состоянием (хранит внутри себя запись данных), а также набором методов - процедур, с помощью которых (и только таким образом) можно получить доступ к данным, определяющим внутреннее состояние объекта, или изменить их. Таким образом, объекты можно рассматривать как самостоятельные сущности, отделенные от внешнего мира; наследование - подразумевает возможность создавать из классов объектов новые классы объекты, которые наследуют структуру и методы своих предков, добавляя к ним черты, отражающие их собственную индивидуальность. Наследование может быть простым (один предок) и множественным (несколько предков); полиморфизм - различные объекты могут по разному реагировать на одинаковые внешние события в зависимости от того, как реализованы их методы. Целостность данных Для поддержания целостности объектно-ориентированный подход предлагает использовать следующие средства: автоматическое поддержание отношений наследования возможность объявить некоторые поля данных и методы объекта как "скрытые", не видимые для других объектов; такие поля и методы используются только методами самого объекта создание процедур контроля целостности внутри объекта Средства манипулирования данными К сожалению, в объектно-ориентированном программировании отсутствуют общие средства манипулирования данными, такие как реляционная алгебра или реляционное счисление. Работа с данными ведется с помощью одного из объектно-ориентированных языков программирования общего назначения. Подведем теперь некоторые итоги В объектно-ориентированных базах данных, в отличие от реляционных, хранятся не записи, а объекты. ОО-подход представляет более совершенные средства для отображения реального мира, чем реляционная модель, естественное представление данных. В реляционной модели все отношения принадлежат одному уровню, именно это осложняет преобразование иерархических связей модели "сущность-связь" в реляционную модель. ОО - модель можно рассматривать послойно, на разных уровнях абстракции. Имеется возможность определения новых типов данных и операций с ними. В то же время, ОО - модели присущ и ряд недостатков: отсутствуют мощные непроцедурные средства извлечения объектов из базы. Все запросы приходится писать на процедурных языках, проблема их оптимизации возлагается на программиста; вместо чисто декларативных ограничений целостности (типа явного объявления первичных и внешних ключей реляционных таблиц с помощью ключевых слов PRIMARY KEY и REFERENCES) или полудекларативных триггеров для обеспечения внутренней целостности приходится писать процедурный код. Очевидно, что оба эти недостатка связаны с отсутствием развитых средств манипулирования данными. Эта задача решается двумя способами - расширение ОО-языков в сторону управления данными (стандарт ODMG), либо добавление объектных свойств в реляционные СУБД (SQL-3, а также так называемые объектно-реляционных СУБД). Объектно-реляционные СУБД Разница между объектно-реляционными и объектными СУБД: первые являют собой надстройку над реляционной схемой, вторые же изначально объектно-ориентированы. Главная особенность и отличие объектно-реляционных, как и объектных, СУБД от реляционных заключается в том, что О(Р)СУБД интегрированы с Объектно-Ориентированным (OO) языком программирования, внутренним или внешним как C++, Java. Характерные свойства OРСУБД - 1) комплексные данные, 2) наследование типа, и 3) объектное поведение. Комплексные данные могут быть реализованы через постоянно-хранимые объекты (persistent objects). Создание комплексных данных в большинстве существующих ОРСУБД основано на предварительном определении схемы через определяемый пользователем тип (UDT user-defined type). Используются также встроенные конструкторы составных типов, например массив(ARRAY). Иерархия структурных комплексных данных предлагает дополнительное свойство, наследование типа. То есть структурный типможет иметь подтипы, которые используют все его атрибуты и содержат дополнительные атрибуты, специфицированные в подтипе. Объектное поведение закладывается через описание программных объектов. Такие объекты должны быть сохраняемыми и переносимыми для обработки в базе данных, поэтому они называются обычно как постоянные (или долговременные) объекты. Внутри базы данных все отношения с постоянным программным объектом есть отношения с его объектным идентификатором (OID). Реляционный подход к построению инфологической модели Реляционная модель данных Реляционная модель есть представление БД в виде совокупности упорядоченных нормализованных отношений. Для реляционных отношений характерны следующие особенности. 1. Любой тип записи содержит только простые (по структуре) элементы данных. 2. Порядок кортежей в таблице несуществен. 3. Упорядочение значащих атрибутов в кортеже должно соответствовать упорядочению атрибутов в реляционном отношении. 4. Любое отношение должно содержать один атрибут или более, которые вместе составляют уникальный первичный ключ. 5. Если между двумя реляционными отношениями существует зависимость, то одно отношение является исходным, второе - подчиненным. 6. Чтобы между двумя реляционными отношениями существовала зависимость, атрибут, служащие первичным ключом в исходном отношении, должны также присутствовать в подчиненном отношении. Эти модели характеризуются простотой структуры данных, удобным для пользователя табличным представлением и возможностью использования формального аппарата алгебры отношений и реляционного исчисления для обработки данных. Реляционная модель ориентирована на организацию данных в виде двумерных таблиц. Каждая реляционная таблица представляет собой двумерный массив и обладает следующими свойствами: каждый элемент таблицы - один элемент данных; все столбцы в таблице однородные, т.е. все элементы в столбце имеют одинаковый тип (числовой, символьный и т.д.) и длину; каждый столбец имеет уникальное имя; одинаковые строки в таблице отсутствуют; порядок следования строк и столбцов может быть произвольным. Понятие информационного объекта Информационный объект - это описание некоторой сущности (реального объекта, явления, процесса, события) в виде совокупности логически связанных реквизитов (информационных элементов). Такими сущностями для информационных объектов могут служить: цех, склад, материал, вуз, студент, сдача экзаменов и т.д. Информационный объект определенного реквизитного состава и структуры образует класс (тип), которому присваивается уникальное имя (символьное обозначение), например Студент, Сессия, Стипендия. Информационный объект имеет множество реализации - экземпляров, каждый из которых представлен совокупностью конкретных значений реквизитов и идентифицируете* значением ключа (простого - один реквизит или составного - несколько реквизитов). Остальные реквизиты информационного объекта являются описательными. При этом одни и те же реквизиты в одних информационных объектах могут быть ключевыми, а в других- описательными. Информационный объект может иметь несколько ключей. В информационном объекте Студент ключом является реквизит Номер (№ личного дела), к описательным реквизитам относятся:Фамилия (Фамилия студента), Имя (Имя студента), Отчество (Отчество студента), Дата (Дата рождения), Группа (№ группы). Если отсутствует реквизит Номер, то для однозначного определения характеристик конкретного студента необходимо использование составного ключа из трех реквизитов: Фамилия + Имя + Отчество. Типы связей. Свойства отношений Реляционные базы данных состоят из нескольких таблиц, связь между которыми устанавливается с помощью совпадающих полей. Каждая запись в таблицах идентифицирует один объект. Отношение между объектами определяет отношение между таблицами. Существует 4 типа отношений: Отношение "один-к-одному" (1:1) означает, что каждая запись в одной таблице соответствует только одной записи в другой таблице. Отношение "один-ко-многим" (1 :М) означает, что каждой записи в одной таблице соответствует одна или несколько записей в другой таблице. Отношение "многие-к-одному" (М:1) аналогично рассмотренному ранее типу "один-комногим". Тип отношения между объектами зависит от вашей точки зрения. Отношение "многие-ко-многим" (М:М). возникает между двумя таблицами в тех случаях, когда каждой запись в одной таблице соответствует 0, 1, 2 и более записей в другой таблице и наоборот. В большинстве случаев любые две таблицы связаны отношением "один-ко-многим". Это означает, что любая запись в первой таблице может быть связана с несколькими записями во второй, однако любая запись второй таблицы связана только с одной записью в первой. Связь один к одному (1:1) предполагает, что в каждый момент времени одному экземпляру информационного объекта А соответствует не более одного экземпляра информационного объекта В и наоборот. Рисунок 5.5 иллюстрирует указанный тип отношения. Рис. 5.5. Графическое изображение реального отношения 1:1 Пример 5.11 Примером связи 1:1 может служить связь между информационными объектами СТУДЕНТ и СЕССИЯ: СТУДЕНТ <-> СЕССИЯ Каждый студент имеет определенный набор экзаменационных оценок в сессию. При связи один ко многим (1:М) одному экземпляру информационного объекта А соответствует 0, 1 или более экземпляров объекта В, но каждый экземпляр объекта В связан не более чем с 1 экземпляром объекта А. Графически данное соответствие имеет вид, представленный на рис. 5.6. Рис. 5.6. Графическое изображение реального отношения 1:М Пример 5.12 Примером связи 1 :М служит связь между информационными объектами СТИПЕНДИЯ и СЕССИЯ: СТИПЕНДИЯ <-" СЕССИЯ Установленный размер стипендии по результатам сдачи сессии может повторяться многократно для различных студентов. Связь многие ко многим (М:М) предполагает, что в каждый момент времени одному экземпляру информационного объекта А соответствует 0, 1 или более экземпляров объекта В и наоборот. На рис. 5.7 графически представлено указанное соответствие. Рис. 5.7. Графическое изображение реального отношения М:М Пример 5.13 Примером данного отношения служит связь между информационными объектами СТУДЕНТ и ПРЕПОДАВАТЕЛЬ: СТУДЕНТ "-" ПРЕПОДАВАТЕЛЬ Один студент обучается у многих преподавателей, один преподаватель обучает многих студентов. Простые и составные ключи Первичный ключ может состоять из единственного поля таблицы, значения которого уникальны для каждой записи. Так, например, на предприятии не может быть двух работников с одинаковыми табельными номерами, поэтому в таблице, содержащей записи о работниках, табельный номер может быть первичным ключом. Такой первичный ключ называют простым ключом. Если таблица не имеет единственного уникального поля, первичный ключ может быть составлен из нескольких полей, совокупность значений которых гарантирует уникальность. Так, имя, фамилия, отчество, номер паспорта, серия паспорта не могут быть первичными ключами по отдельности, так как могут оказаться одинаковыми у двух и более людей. Но не бывает двух личных документов одного типа с одинаковыми серией и номером. Поэтому в таблице, содержащей записи о людях, первичным ключом может быть набор полей, состоящий из типа личного документа, его серии и номера. Такой первичный ключ называютсоставным ключом Все остальные ключи отношения называются возможными ключами. В отличие от иерархической и сетевой моделей данных в реляционной отсутствует понятие группового отношения. Для отражения ассоциаций между кортежами разных отношений используется дублирование их ключей. Рассмотренный иерархический и сетевой пример базы данных, содержащей сведения о подразделениях предприятия и работающих в них сотрудниках, применительно к реляционной модели будет иметь вид: Атрибуты, представляющие собой копии ключей других отношений, называются внешними ключами. Иногда возникает потребность разбить одну таблицу на более мелкие - проблема может заключаться в том, что некоторые сведения из нее используются не слишком часто, или в том, что какие-то данные не предназначаются для всеобщего доступа. Например, часть информации о факультетах нужна только для рекламных целей и используется очень редко. С другой стороны, сведения о заработной плате должны быть доступны только определенным сотрудникам. В любом из этих случаев можно создать отдельную таблицу и связать ее с исходной таблицей отношением типа "один-к-одному". Это означает, что любая запись в первой таблице связана только с одной записью во второй. Если же между таблицами необходимо организовать связь "многие-ко-многим", то в Access придется создать дополнительную таблицу пересечения, с помощью которой одна связь будет сведена к двум связям типа "один-ко-многим".
