Информатика (Базы данных)

ПОВОЛЖСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ ТЕЛЕКОММУНИКАЦИЙ И ИНФОРМАТИКИ Курс лекций для студентов дистанционной формы обучения (2-ой семестр) «Информатика (Базы данных)» Кафедра «Информатика и вычислительная техника» г. Самара 2012 ОГЛАВЛЕНИЕ Введение ............................................................................................................ 3 1 Основные понятия баз данных ..................................................................... 4 Определение основных терминов............................................................... 6 Основные требования, предъявляемые к банкам данных ........................ 9 Компоненты банка данных........................................................................ 10 Пользователи БД и СУБД.......................................................................... 11 2 Классификация БД ...................................................................................... 12 Классификация баз данных ....................................................................... 13 Классификация СУБД................................................................................ 14 Основные функции СУБД ......................................................................... 16 Функциональные возможности СУБД ..................................................... 20 3 Проектирование баз данных ....................................................................... 22 Подходы к проектированию...................................................................... 22 Архитектура СУБД .................................................................................... 24 Методология проектирования баз данных............................................... 25 Основные этапы разработки БД................................................................ 29 4 Модели организации баз данных .............................................................. 31 Иерархическая модель базы данных ........................................................ 32 Сетевая модель базы данных. ................................................................... 36 Операции над данными в сетевой модели БД. ........................................ 39 Достоинства и недостатки ранних СУБД ................................................ 39 Объектно-ориентированные СУБД .......................................................... 40 Объектно-реляционные СУБД .................................................................. 42 5 Реляционный подход к построению инфологической модели................ 43 Реляционная модель данных ..................................................................... 43 Понятие информационного объекта ......................................................... 44 Нормализация отношений ......................................................................... 45 Свойства отношений. ................................................................................. 49 Простые и составные ключи ..................................................................... 51 6. Работа с СУБД MS Access ......................................................................... 53 Объекты Microsoft Access. ......................................................................... 53 Работа с таблицами .................................................................................... 55 Создание межтабличных связей ............................................................... 56 Работа с запросами ..................................................................................... 59 Запросы и фильтры .................................................................................... 60 Работа с формами ....................................................................................... 60 Работа с отчётами ....................................................................................... 61 Литература ...................................................................................................... 62 Введение В настоящее время жизнь человека настолько насыщена различного рода информацией, что для ее обработки требуется создание огромного количества хранилищ информации различного назначения. Современные информационные системы характеризуются огромными объемами хранимых данных, сложной организацией, необходимостью удовлетворять разнообразные требования многочисленных пользователей. Основой информационной системы является база данных. Целью любой информационной системы является обработка данных об объектах реального мира. В широком смысле слова база данных - это совокупность сведений о конкретных объектах реального мира, в какой - либо предметной области. Кроме того, база данных - это хранилище данных для совместного использования. При автоматизации деятельности человека происходит перенос реального мира в электронный формат. Многочисленная литература по применяемым СУБД и различным Windows-приложениям конкретизирована вплоть до кнопок, что затрудняет понимание не только самих программных средств, но принципов и правил их построения. Более того, в ней часто вводятся новые термины, порой не определяемые или имеющие разные названия в различных источниках. Много отдельных вопросов по базам данных опубликованы в труднодоступных журналах, прежде всего иностранных. Кроме того, в свете современного представления о базе данных трансформировался ряд понятий и положений о ней. Данное пособие предназначено для получения студентами представления об основных понятиях при работе с базой данных, классификации баз данных и систем управления данными в рамках предмета информатика. Кроме того, в пособие включены задания по лабораторным работам и варианты курсовых работ для создания баз данных в СУБД MS Access. 3 1 Основные понятия баз данных На первом разделе мы рассмотрим общий смысл понятий базы данных (БД) и системы управления базами данных (СУБД). С самого начала развития вычислительной техники образовались два основных направления использования ее. Первое направление - применение вычислительной техники для выполнения численных расчетов, которые слишком долго или вообще невозможно производить вручную. Становление этого направления способствовало интенсификации методов численного решения сложных математических задач, развитию класса языков программирования, ориентированных на удобную запись численных алгоритмов, становлению обратной связи с разработчиками новых архитектур ЭВМ. Второе направление, это использование средств вычислительной техники в автоматических или автоматизированных информационных системах. В самом широком смысле информационная система представляет собой программный комплекс, функции которого состоят в поддержке надежного хранения информации в памяти компьютера, выполнении специфических для данного приложения преобразований информации и/или вычислений, предоставлении пользователям удобного и легко осваиваемого интерфейса. Обычно объемы информации, с которыми приходится иметь дело таким системам, достаточно велики, а сама информация имеет достаточно сложную структуру. Классическими примерами информационных систем являются банковские системы, системы резервирования авиационных или железнодорожных билетов, мест в гостиницах и т.д. На самом деле, второе направление возникло несколько позже первого. Это связано с тем, что на заре вычислительной техники компьютеры обладали ограниченными возможностями в части памяти. Понятно, что можно говорить о надежном и долговременном хранении информации только при наличии запоминающих устройств, сохраняющих информацию после выключения электрического питания. Оперативная память этим свойством обычно не обладает. В начале использовались два вида устройств внешней памяти: магнитные ленты и барабаны. При этом емкость магнитных лент была достаточно велика, но по своей физической природе они обеспечивали последовательный доступ к данным. Магнитные же барабаны (они больше всего похожи на современные магнитные диски с фиксированными головками) давали возможность произвольного доступа к данным, но были ограниченного размера. Легко видеть, что указанные ограничения не очень существенны для чисто численных расчетов. Даже если программа должна обработать 4 (или произвести) большой объем информации, при программировании можно продумать расположение этой информации во внешней памяти, чтобы программа работала как можно быстрее. С другой стороны, для информационных систем, в которых потребность в текущих данных определяется пользователем, наличие только магнитных лент и барабанов неудовлетворительно. Представьте себе покупателя билета, который стоя у кассы должен дождаться полной перемотки магнитной ленты. Одним из естественных требований к таким системам является средняя быстрота выполнения операций. Именно требования к вычислительной технике со стороны не численных приложений вызвали появление съемных магнитных дисков с подвижными головками, что явилось революцией в истории вычислительной техники. Эти устройства внешней памяти обладали существенно большей емкостью, чем магнитные барабаны, обеспечивали удовлетворительную скорость доступа к данным в режиме произвольной выборки, а возможность смены дискового пакета на устройстве позволяла иметь практически неограниченный архив данных. С появлением магнитных дисков началась история систем управления данными во внешней памяти. До этого каждая прикладная программа, которой требовалось хранить данные во внешней памяти, сама определяла расположение каждой порции данных на магнитной ленте или барабане и выполняла обмены между оперативной и внешней памятью с помощью программно-аппаратных средств низкого уровня (машинных команд или вызовов соответствующих программ операционной системы). Такой режим работы не позволяет или очень затрудняет поддержание на одном внешнем носителе нескольких архивов долговременно хранимой информации. Кроме того, каждой прикладной программе приходилось решать проблемы именования частей данных и структуризации данных во внешней памяти. Историческим шагом стал переход к использованию систем управления файлами. С точки зрения прикладной программы файл – это именованная область внешней памяти, в которую можно записывать и из которой можно считывать данные. Правила именования файлов, способ доступа к данным, хранящимся в файле, и структура этих данных зависят от конкретной системы управления файлами и, возможно, от типа файла. Система управления файлами берет на себя распределение внешней памяти, отображение имен файлов в соответствующие адреса внешней памяти и обеспечение доступа к данным. Любая задача обработки информации и принятия решений может быть представлена в виде схемы, показанной на рис. 1.1. 5 Рисунок 1.1. Схема решения задач обработки информации и принятия решений: x-штрих, y-штрих - входная и выходная информация; f - внутреннее операторное описание Определение основных терминов Для нее дадим определения основных терминов. В качестве составных частей схемы выделяются информация (входная и выходная) и правила ее преобразования. Правила могут быть в виде алгоритмов, процедур и эвристических последовательностей. Алгоритм - последовательность правил перехода от исходных данных к результату. Правила могут выполняться компьютером или человеком. Данные - совокупность объективных сведений. Информация - сведения, неизвестные ранее получателю информации, пополняющие его знания, подтверждающие или опровергающие положения и соответствующие убеждения. Информация носит субъективный характер и определяется уровнем знаний субъекта и степенью его восприятия. Информация извлекается субъектом из соответствующих данных. Знания - совокупность фактов, закономерностей и эвристических правил, с помощью которых решается поставленная задача. Последовательность 6 операций обработки данных называют информационной технологией (ИТ). В силу значительного количества информации в современных задачах она должна быть упорядочена. Существует два подхода к упорядочению. 1. Данные связаны с конкретной задачей (технология массивов) упорядочение по использованию. Вместе с тем алгоритмы более подвижны (могут чаще меняться), чем данные. Это вызывает необходимость переупорядочения данных, которые к тому же могут повторяться в различных задачах. 2. В связи с этим предложена другая, широко используемая технология баз данных, представляющая собой упорядочение по хранению. КОДАСИЛ (CODASYL) – набор стандартов для сетевых БД. Кортеж - совокупность полей или запись. Объект - термин, обозначающий факт, лицо, событие, предмет, о котором могут быть собраны данные. Сущность - примитивный объект данных, отображающий элемент предметной области (человек, место, вещь и т.д.). Под базой данных (БД) понимают совокупность хранящихся вместе данных при наличии такой минимальной избыточности, которая допускает их использование оптимальным образом для одного или нескольких приложений. Целью создания баз данных, как разновидности информационной технологии и формы хранения данных, является построение системы данных, не зависящих от принятых алгоритмов (программного обеспечения), применяемых технических средств и физического расположения данных в ЭВМ; обеспечивающих непротиворечивую и целостную информацию при нерегламентируемых запросах. БД предполагает многоцелевое ее использование (несколько пользователей, множество форм документов и запросов одного пользователя). База знаний (БЗ) представляет собой совокупность БД и используемых правил, полученных от лиц, принимающих решения (ЛПР). Наряду с понятием «база данных» существует термин «банк данных», который имеет две трактовки. 1. В настоящее время данные обрабатываются децентрализовано (на рабочих местах) с помощью персональных компьютеров (ПК). 7 Первоначально же использовалась централизованная обработка на больших ЭВМ. В силу централизации базу данных называли банком данных и потому часто не делают различия между базами и банками данных. 2. Банк данных - база данных и система управления ею (СУБД). СУБД (например, FoxPro) представляет собой приложение для создания баз данных как совокупности двумерных таблиц. Банк данных (БнД) - это система специально организованных данных, программных, языковых, организационных и технических средств, предназначенных для централизованного накопления и коллективного многоцелевого использования данных. Базы данных (БД) - это именованная совокупность данных, отображающая состояние объектов и их отношения в рассматриваемой предметной области. Характерной чертой баз данных является постоянство: данные постоянно накапливаются и используются; состав и структура данных, необходимы для решения тех или иных прикладных задач, обычно постоянны и стабильны во времени; отдельные или даже все элементы данных могут меняться - но и это есть проявления постоянства - постоянная актуальность. Система управления базами данных (СУБД) - это совокупность языковых и программных средств, предназначенных для создания, ведения и совместного использования БД многими пользователями. Иногда в составе банка данных выделяют архивы. Основанием для этого является особый режим использования данных, когда только часть данных находится под оперативным управлением СУБД. Все остальные данные обычно располагаются на носителях, оперативно не управляемых СУБД. Одни и те же данные в разные моменты времени могут входить как в базы данных, так и в архивы. Банки данных могут не иметь архивов, но если они есть, то состав банка данных может входить и система управления архивами. Эффективное управление внешней памятью являются основной функцией СУБД. Эти обычно специализированные средства настолько важны с точки зрения эффективности, что при их отсутствии система просто не сможет выполнять некоторые задачи уже по тому, что их выполнение будет занимать слишком много времени. При этом ни одна из таких специализированных функций не является видимой для пользователя и обеспечивает независимость между логическим и физическим уровнями системы: прикладной программист не должен писать программы индексирования, распределять память на диске и т. д. 8 Основные требования, предъявляемые к банкам данных Развитие теории и практики создания информационных систем, основанных на концепции баз данных, создание унифицированных методов и средств организации и поиска данных позволяют хранить и обрабатывать информацию о все более сложных объектах и их взаимосвязях, обеспечивая многоаспектные информационные потребности разных пользователей. Основные требования, предъявляемые к банкам данных, можно сформулировать так: - Многократное использование данных: пользователи должны иметь возможность использовать данные различным образом. - Простота: пользователи должны иметь возможность легко узнать и понять, какие данные имеются в их распоряжении. - Легкость использования: пользователи должны иметь возможность осуществлять (процедурно) простой доступ к данным, при этом все сложности доступа к данным должны быть скрыты в самой системе управления базами данных. - Гибкость использования: обращение к данным или их поиск должны осуществляться с помощью различных методов доступа. - Быстрая обработка запросов на данные: запросы на данные, должны обрабатываться с помощью высокоуровневого языка запросов, а не только прикладными программами, написанными с целью обработки конкретных запросов. - Язык взаимодействия конечных пользователей с системой должен обеспечивать конечным пользователям возможность получения данных без использования прикладных программ. База данных - это основа для будущего наращивания прикладных программ: базы данных должны обеспечивать возможность быстрой и дешевой разработки новых приложений. - Сохранение затрат умственного труда: существующие программы и логические структуры данных не должны переделываться при внесении изменений в базу данных. - Наличие интерфейса прикладного программирования: прикладные программы должны иметь возможность просто и эффективно выполнять запросы на данные; программы должны быть изолированными от расположения файлов и способов адресации данных. - Распределенная обработка данных: система должна функционировать в условиях вычислительных сетей и обеспечивать 9 - - - - - эффективный доступ пользователей к любым данным распределенной БД, размещенным в любой точке сети. Адаптивность и расширяемость: база данных должна быть настраиваемой, причем настройка не должна вызывать перезаписи прикладных программ. Кроме того, поставляемый с СУБД набор предопределенных типов данных должен быть расширяемым - в системе должны иметься средства для определения новых типов и не должно быть различий в использовании системных и определенных пользователем типов. Контроль за целостностью данных: система должна осуществлять контроль ошибок в данных и выполнять проверку взаимного логического соответствия данных. Восстановление данных после сбоев: автоматическое восстановление без потери данных транзакции. В случае аппаратных или программных сбоев система должна возвращаться к некоторому согласованному состоянию данных. Вспомогательные средства должны позволять разработчику или администратору базы данных предсказать и оптимизировать производительность системы. Автоматическая реорганизация и перемещение: система должна обеспечивать возможность перемещения данных или автоматическую реорганизацию физической структуры. Компоненты банка данных Определение банка данных предполагает, что с функциональноорганизационной точки зрения банк данных является сложной человекомашинной системой, включающей в себя все подсистемы, необходимые для надежного, эффективного и продолжительного во времени функционирования. В структуре банка данных выделяют следующие компоненты: · Информационная база; · Лингвистические средства; · Программные средства; · Технические средства; · Организационно-административные подсистемы и нормативнометодическое обеспечение. Организационно-методические средства - это совокупность инструкций, методических и регламентирующих материалов, описаний структуры и процедуры работы пользователя с СУБД и БД. 10 Пользователи БД и СУБД Пользователей возможно разделить на две основные категории: конечные пользователи; администраторы баз данных. Особо следует поговорить об администраторе базы данных (АБД). Естественно, что база данных строится для конечного пользователя (КП). Однако первоначально предполагалось, что КП не смогут работать без специалиста-программиста, которого назвали администратором базы данных. С появлением СУБД они взяли на себя значительную часть функций АБД, особенно для БД с небольшим объемом данных. Однако для крупных централизованных и распределенных баз данных потребность в АБД сохранилась. В широком плане под АБД понимают системных аналитиков, проектировщиков структур данных и информационного обеспечения, проектировщиков технологии процессов обработки, системных и прикладных программистов, операторов, специалистов в предметной области и по техническому обслуживанию. Иными словами, в крупных базах данных это могут быть коллективы специалистов. В обязанности АБД входит: 1) анализ предметной области, статус информации и пользователей; 2) проектирование структуры и модификация данных; 3) задание и обеспечение целостности; 4) загрузка и ведение БД; 5) защита данных; 6) обеспечение восстановления БД; 7) сбор и статистическая обработка обращений к БД, анализ эффективности функционирования БД; 8) работа с пользователем. 11 2 Классификация БД Классификация - разделение множества на подмножества по неформально предложенному признаку. В силу многогранности баз данных и СУБД (комплекса технических и программных средств для хранения, поиска, защиты и использования данных) имеется множество классификационных признаков. Классификация БД по основным из них приведена на рис. 2.1. Базы данных могут классифицироваться и с точки зрения экономической: по условиям предоставления услуг - бесплатные и платные (бесприбыльные, коммерческие); по форме собственности государственные, негосударственные; по степени доступности общедоступные, с ограниченным кругом пользователей. Рисунок 2.1 Классификация баз данных 12 Классификация баз данных В мире существует множество СУБД. Несмотря на их различие, все они опираются на единый устоявшийся комплекс основных понятий. СУБД носит централизованный характер. Что предполагает необходимость существования некоторого лица (группы лиц), на которое возлагаются функции администрирования данными, хранимыми в базе. По технологии обработки данных БД делятся на: Централизованные и Распределённые. Централизованная БД хранится в памяти одной вычислительной системы (применяется в локальных сетях ПК). Централизованные БД могут быть и с сетевым доступом. Архитектуры систем централизованных БД с сетевым доступом подразделяются на файл-сервер и клиент-сервер. Рисунок 2.2 БД с сетевым доступом (Файл-сервер) Архитектура систем БД с сетевым доступом (Файл-сервер) как показано на рисунке 2.2. предполагает выделение одной из машин сети в качестве центральной (сервер файлов). На ней хранится совместно используемая централизованная БД. Все другие машины сети являются рабочими станциями. Файлы БД в соответствии с пользовательскими запросами передаются на рабочие станции, где и производится обработка. При большой интенсивности доступа к одним и тем же данным производительность системы падает. Рисунок 2.3. БД с сетевым доступом Клиент - сервер 13 В архитектуре Клиент-сервер (рисунок 2.3) подразумевается, что помимо хранения централизованной БД центральная машина (сервер базы данных) должна обеспечивать выполнение основного объёма обработки данных. Запрос на данные клиента, порождает поиск и извлечение данных на сервере. Извлечённые данные (но не файлы) транспортируются по сети от сервера к клиенту. Пример БД – деловой ежедневник, в котором каждому календарному дню выделено по странице. Даже в отсутствии там записей, он не перестаёт быть ежедневником, т.к. имеет структуру, отличающую его от записных книжек, рабочих тетрадей и т.п. Другие примеры БД: база данных больных в поликлинике, БД по видеофильмам (видеотека), БД по сотрудникам организации (Ф.И.О., пол, дата рождения, место жительство, телефон, состав семьи и т.д.) Распределённая БД состоит из нескольких частей, хранимых в различных ЭВМ вычислительной сети (работа с такой БД происходит с помощью СУБД). По способу доступа к данным БД разделяются на: БД с локальным и удаленным доступом. БД с локальным доступом называется, если эта вычислительная система является компонентом сети ЭВМ, возможен распределённый доступ к такой базе. Такой способ использования БД часто применяют в локальных сетях ПК. БД с удалённым (сетевым) доступом называется когда, части БД могут пересекаться или даже дублироваться, но хранятся в различных ЭВМ вычислительной сети. Для работы с созданной БД пользователю или администратору БД следует иметь перечень файлов-таблиц с описанием состава их данных (структуры, схемы). Для этого создается специальный файл, называемый словарем данных (депозитарием, словарем-справочником, энциклопедией). Описание БД относится к метаинформации. В качестве технических средств могут выступать супер- или персональные компьютеры с соответствующими периферийными устройствами. Классификация СУБД Система управления базами данных (СУБД) - это совокупность языковых и программных средств, предназначенных для создания, ведения и совместного использования БД многими пользователями. Системы управления базами данных следует классифицировать отдельно (рисунок 2.4.). 14 Рис. 2.4 Классификация СУБД Состав СУБД и работа БД СУБД представляет собой оболочку, с помощью которой при организации структуры таблиц и заполнения их данными получается та или иная база данных. В связи с этим полезно поговорить о системе программно-технических, организационных и «человеческих» составляющих (рисунок 2.5). Программные средства включают систему управления, обеспечивающую ввод-вывод, обработку и хранение информации, создание, модификацию и тестирование БД, трансляторы. Рисунок 2.5 Состав СУБД Базовыми внутренними языками программирования являются языки четвертого поколения. В качестве базовых языков могут использоваться C, C++, Pascal, Object Pascal. Язык C++ позволяет строить программы на языке Visual Basic с широким спектром возможностей, более близком и понятном даже пользователю-непрофессионалу, и на непроцедурном (декларативном) языке структурированных запросов SQL. Следует отметить, что исторически для системы управления базой данных сложились три языка: 1) язык описания данных (ЯОД), называемый также языком описания схем, - для построения структуры («шапки») таблиц БД; 2) язык манипулирования данными (ЯМД) - для заполнения БД данными и операций обновления (запись, удаление, модификация); 15 3) язык запросов - язык поиска наборов величин в файле в соответствии с заданной совокупностью критериев поиска и выдачи затребованных данных без изменения содержимого файлов и БД (язык преобразования критериев в систему команд). В настоящее время функции всех трех языков выполняет язык SQL, относящийся к классу языков, базирующихся на исчислении кортежей (кортеж чаще всего является единицей информации), языки СУБД FoxPro, Visual Basic for Application (СУБД Access) и т.д. Вместе с тем сохранились и языки запросов, например язык запросов по примеру Query By Example (QBE) класса исчисления доменов. Отметим, что эти языки в качестве «информационной единицы» БД используют отдельную запись. С помощью языков БД создаются приложения, базы данных и интерфейс пользователя, включающий экранные формы, меню, отчеты. При создании БД на базе СУБД FoxPro эти элементы (объекты) фиксируются в отдельных файлах, которые, в свою очередь, сосредоточиваются в одном файле, называемом проектом. После отработки БД проект преобразуется в приложение. В СУБД Access все созданные объекты размещаются в одном файле. Основные функции СУБД Более точно, к числу функций СУБД принято относить следующие: 1. Непосредственное управление данными во внешней памяти Эта функция включает обеспечение необходимых структур внешней памяти как для хранения данных, непосредственно входящих в БД, так и для служебных целей, например, для убыстрения доступа к данным в некоторых случаях (обычно для этого используются индексы). В некоторых реализациях СУБД активно используются возможности существующих файловых систем, в других работа производится вплоть до уровня устройств внешней памяти. Но подчеркнем, что в развитых СУБД пользователи в любом случае не обязаны знать, использует ли СУБД файловую систему, и если использует, то как организованы файлы. В частности, СУБД поддерживает собственную систему именования объектов БД. 2. Управление буферами оперативной памяти СУБД обычно работают с БД значительного размера; по крайней мере, этот размер обычно существенно больше доступного объема оперативной памяти. Понятно, что если при обращении к любому элементу данных будет производиться обмен с внешней памятью, то вся система будет работать со скоростью устройства внешней памяти. Практически единственным способом реального увеличения этой скорости является 16 буферизация данных в оперативной памяти. При этом, даже если операционная система производит общесистемную буферизацию (как в случае ОС UNIX), этого недостаточно для целей СУБД, которая располагает гораздо большей информацией о полезности буферизации той или иной части БД. Поэтому в развитых СУБД поддерживается собственный набор буферов оперативной памяти с собственной дисциплиной замены буферов. Заметим, что существует отдельное направление СУБД, которое ориентировано на постоянное присутствие в оперативной памяти всей БД. Это направление основывается на предположении, что в будущем объем оперативной памяти компьютеров будет настолько велик, что позволит не беспокоиться о буферизации. Пока эти работы находятся в стадии исследований. 3. Управление транзакциями Транзакция - это последовательность операций над БД, рассматриваемых СУБД как единое целое. Либо транзакция успешно выполняется, и СУБД фиксирует изменения БД, произведенные этой транзакцией, во внешней памяти, либо ни одно из этих изменений никак не отражается на состоянии БД. Понятие транзакции необходимо для поддержания логической целостности БД. Приведем пример информационной системы с файлами СОТРУДНИКИ и ОТДЕЛЫ, то единственным способом не нарушить целостность БД при выполнении операции приема на работу нового сотрудника является объединение элементарных операций над файлами СОТРУДНИКИ и ОТДЕЛЫ в о ну д тр нзакцию. а Таким обр зо а м , поддержание механизма транзакций является обязательным условием даже однопользовательских СУБД (если, конечно, такая система заслуживает названия СУБД). Но понятие транзакции гораздо более важно в многопользовательских СУБД. То свойство, что каждая транзакция начинается при целостном состоянии БД и оставляет это состояние целостным после своего завершения, делает очень удобным использование понятия транзакции как единицы активности пользователя по отношению к БД. При соответствующем управлении параллельно выполняющимися транзакциями со стороны СУБД каждый из пользователей может в принципе ощущать себя единственным пользователем СУБД (на самом деле, это несколько идеализированное представление, поскольку в некоторых случаях пользователи многопользовательских СУБД могут ощутить присутствие своих коллег). 17 4. Журнализация Одним из основных требований к СУБД является надежность хранения данных во внешней памяти. Под надежностью хранения понимается то, что СУБД должна быть в состоянии восстановить последнее согласованное состояние БД после любого аппаратного или программного сбоя. Обычно рассматриваются два возможных вида аппаратных сбоев: так называемые мягкие сбои, которые можно трактовать как внезапную остановку работы компьютера (например, аварийное выключение питания), и жесткие сбои, характеризуемые потерей информации на носителях внешней памяти. Примерами программных сбоев могут быть: аварийное завершение работы СУБД (по причине ошибки в программе или в результате некоторого аппаратного сбоя) или аварийное завершение пользовательской программы, в результате чего некоторая транзакция остается незавершенной. Первую ситуацию можно рассматривать как особый вид мягкого аппаратного сбоя; при возникновении последней требуется ликвидировать последствия только одной транзакции. Понятно, что в любом случае для восстановления БД нужно располагать некоторой дополнительной информацией. Другими словами, поддержание надежности хранения данных в БД требует избыточности хранения данных, причем та часть данных, которая используется для восстановления, должна храниться особо надежно. Наиболее распространенным методом поддержания такой избыточной информации является ведение журнала изменений БД. Журнал - это особая часть БД, недоступная пользователям СУБД и поддерживаемая с особой тщательностью (иногда поддерживаются две копии журнала, располагаемые на разных физических дисках), в которую поступают записи обо всех изменениях основной части БД. В разных СУБД изменения БД журнализуются на разных уровнях: иногда запись в журнале соответствует некоторой логической операции изменения БД (например, операции удаления строки из таблицы реляционной БД), иногда - минимальной внутренней операции модификации страницы внешней памяти; в некоторых системах одновременно используются оба подхода. Во всех случаях придерживаются стратегии "упреждающей" записи в журнал (так называемого протокола Write Ahead Log - WAL). Грубо говоря, эта стратегия заключается в том, что запись об изменении любого объекта БД должна попасть во внешнюю память журнала раньше, чем измененный объект попадет во внешнюю память основной части БД. 18 Известно, что если в СУБД корректно соблюдается протокол WAL, то с помощью журнала можно решить все проблемы восстановления БД после любого сбоя. Самая простая ситуация восстановления - индивидуальный откат транзакции. Строго говоря, для этого не требуется общесистемный журнал изменений БД. Достаточно для каждой транзакции поддерживать локальный журнал операций модификации БД, выполненных в этой транзакции, и производить откат транзакции путем выполнения обратных операций, следуя от конца локального журнала. В некоторых СУБД так и делают, но в большинстве систем локальные журналы не поддерживают, а индивидуальный откат транзакции выполняют по общесистемному журналу, для чего все записи от одной транзакции связывают обратным списком (от конца к началу). 5. Поддержка языков БД Для работы с базами данных используются специальные языки, в целом называемые языками баз данных. В ранних СУБД поддерживалось несколько специализированных по своим функциям языков. Чаще всего выделялись два языка - язык определения схемы БД (SDL - Schema Definition Language) и язык манипулирования данными (DML - Data Manipulation Language). SDL служил главным образом для определения логической структуры БД, т.е. той структуры БД, какой она представляется пользователям. DML содержал набор операторов манипулирования данными, т.е. операторов, позволяющих заносить данные в БД, удалять, модифицировать или выбирать существующие данные. В современных СУБД обычно поддерживается единый интегрированный язык, содержащий все необходимые средства для работы с БД, начиная от ее создания, и обеспечивающий базовый пользовательский интерфейс с базами данных. Стандартным языком наиболее распространенных в настоящее время реляционных СУБД является язык запросов SQL (Structured Query Language). Язык SQL содержит специальные средства определения ограничений целостности БД. Опять же, ограничения целостности хранятся в специальных таблицах-каталогах, и обеспечение контроля целостности БД производится на языковом уровне, т.е. при компиляции операторов модификации БД компилятор SQL на основании имеющихся 19 в БД ограничений программный код. целостности генерирует соответствующий Специальные операторы языка SQL позволяют определять так называемые представления БД, фактически являющиеся хранимыми в БД запросами (результатом любого запроса к реляционной БД является таблица) с именованными столбцами. Для пользователя представление является такой же таблицей, как любая базовая таблица, хранимая в БД, но с помощью представлений можно ограничить или наоборот расширить видимость БД для конкретного пользователя. Поддержание представлений производится также на языковом уровне. Наконец, авторизация доступа к объектам БД производится также на основе специального набора операторов SQL. Идея состоит в том, что для выполнения операторов SQL разного вида пользователь должен обладать различными полномочиями. Пользователь, создавший таблицу БД, обладает полным набором полномочий для работы с этой таблицей. В число этих полномочий входит полномочие на передачу всех или части полномочий другим пользователям, включая полномочие на передачу полномочий. Полномочия пользователей описываются в специальных таблицах-каталогах, контроль полномочий поддерживается на языковом уровне. Функциональные возможности СУБД По степени универсальности различают два класса СУБД: • системы общего назначения – реализованные как программный продукт, способный функционировать на ЭВМ в определённой операционной системе и поставляемый пользователям как коммерческое изделие; • специализированные системы – создаваемые в случаях невозможности или не целесообразности использования СУБД общего назначения. СУБД общего назначения – это сложные программные комплексы, предназначенные для выполнения всей совокупности функций, связанных с созданием и эксплуатацией БД информационной системы. Рынок программного обеспечения ПК располагает большим числом разнообразных по своим функциональным возможностям коммерческих систем СУБД общего назначения. СУБД – лидеры на рынке программ: • dBASE IV, компании Borland International; • Microsoft Access 2007; • Microsoft FoxPro 2.6 for DOS; 20 • Microsoft FoxPro for Windows, Microsoft Corp: • Paradox for DOS 4.5: • Paradox for Windows, версия 4.5 Borland.. Производительность СУБД оценивается: • временем выполнения запросов; • скоростью поиска информации; • временем выполнения операций импортирования данных их других форматов; • скоростью выполнения таких операций как обновления, вставка, удаление данных; • максимальным числом параллельных обращений к данным в многопользовательском режиме; • временем генерации отчёта. На производительность СУБД оказывают влияния 2 фактора: • правильное проектирование • построения БД. СУБД, которые следят за соблюдением целостности данных, несут дополнительную нагрузку, которую не испытывают другие программы; Целостность данных подразумевает наличие средств, позволяющих удостовериться, что информация в БД всегда остаётся корректной и полной. Операции, обеспечивающие безопасность: • шифрование прикладных программ; • шифрование данных; • защита паролем; • ограничение уровня доступа Хороший уровень безопасности в СУБД dBase IV, Access Для сохранения информации используется двойной подход. Некоторые операции сохранения происходят в обход операционной системы Целостность должна обеспечиваться независимо от того, каким образом данные заносятся в память, не конкретных действий пользователей, пробоев сети и т.п. Он предусматривает назначение паролей для индивидуальных пользователей или групп пользователей и присвоение различных прав доступа отдельно таблицам, запросам, отчётам на уровне пользователя или группы. 21 3 Проектирование баз данных Подходы к проектированию В конце 70-х годов появились современные СУБД, обеспечивающие физическую и логическую независимость, безопасность данных, обладающие развитыми языками БД. Последнее десятилетие характеризуется появлением распределенных и объектноориентированных баз данных, характеристики которых определяются приложениями средств автоматизации проектирования и интеллектуализации БД (рисунок 3.1). Существует два подхода к построению БД, базирующихся на двух подходах к созданию автоматизированной системы управления (АСУ). Первый из них, широко использовавшийся в 80-е годы и потому получивший название классического (традиционного), связан с автоматизацией документооборота (совокупность документов, движущихся в процессе работы предприятия). Исходными и выходными координатами являлись документы. Рисунок 3.1 Характеристики БД К 90-м годам сформировался второй, современный подход, связанный с автоматизацией управления. Он предполагает 22 первоначальное выявление стандартных алгоритмов приложений (алгоритмов бизнеса в зарубежной терминологии), под которые определяются данные, а стало быть, и база данных. Объектноориентированное программирование только усилило значимость этого подхода. Состав БД для различных подходов представлен на рис. 3.2. Рисунок 3.2 Схемы классического (а) и современного подходов при построении БД В работе БД возможен одно- и многопользовательский (несколько пользователей подключаются к одному компьютеру через разные порты) режимы. Используют восходящее и нисходящее проектирование БД. Первое применяют в распределенных БД при интеграции спроектированных локальных баз данных, которые могут быть выполнены с использованием различных моделей данных. Более характерным для централизованных БД является нисходящее проектирование. Работа с базами данных может быть представлена в виде схемы, показанной на рисуноке 3.3. Из нее видно , что следует выделять методологию создания и методологию использования БД. Методология БД определяется в процедуре проектирования, но проявляется и в процедуре использования. 23 Рисунок 3.3 Схема создания использования БД Архитектура СУБД СУБД имеет многоуровневую структуру, в которой реализуется принцип относительной независимости логической и физической организации данных (рисунок 3.4). Рисунок 3.4 Структура СУБД 24 Различают концептуальный, внутренний и внешний уровни представления данных БД, которым соответствуют модели аналогичного назначения. Концептуальная модель состоит из множества экземпляров различных типов данных, имеющих структуру в соответствии с требованиями СУБД к логической структуре БД. СУБД имеет два режима работы: • проектировочный – предназначен для создания или изменения структуры базы и создания её объектов; Проектирование БД состоит в построении комплекса взаимосвязанных моделей данных. • пользовательский – использование ранее подготовленных объектов для наполнения базы или получения данных из нее. Методология проектирования баз данных Существует много разновидностей методологии рассмотрения баз данных в классическом подходе, однако чаще всего придерживаются методологии ANSI/SPARC, схема которой представлена на рисунке 3.5. На рисунке 3.5 показана совокупность процедур проектирования централизованной БД, которые можно объединить в четыре этапа. На этапе формулирования и анализа требований устанавливаются цели организации, определяются требования к БД. Они состоят из общих требований, определенных выше, и специфических требований. Для формирования специфических требований обычно используется методика интервьюирования персонала различных уровней управления. Все требования документируются в форме, доступной конечному пользователю и проектировщику БД. Этап концептуального проектирования заключается в описании и синтезе информационных требований пользователей в первоначальный проект БД. Исходными данными могут быть совокупность документов пользователя (рисунок 3.3) при классическом подходе или алгоритмы приложений (алгоритмы бизнеса) при современном подходе. Результатом этого этапа является высокоуровневое представление (в виде системы таблиц 25 БД) информационных различных подходов. требований пользователей Рисунок 3.5 Схема этапов проектирования БД 26 на основе Сначала выбирается модель БД. Затем с помощью ЯОД создается структура БД, которая заполняется данными с помощью команд ЯМД, систем меню, экранных форм или в режиме просмотра таблиц БД. Здесь же обеспечивается защита и целостность (в том числе ссылочная) данных с помощью СУБД или путем построения триггеров. В процессе логического проектирования высокоуровневое представление данных преобразуется в структуру используемой СУБД. Основной целью этапа является устранение избыточности данных с использованием специальных правил нормализации. Цель нормализации - минимизировать повторения данных и возможные структурные изменения БД при процедурах обновления. Это достигается разделением (декомпозицией) одной таблицы в две или несколько с последующим использованием при запросах операции навигации. Полученная логическая структура БД может быть оценена количественно с помощью различных характеристик (число обращений к логическим записям, объем данных в каждом приложении, общий объем данных). На основе этих оценок логическая структура может быть усовершенствована с целью достижения большей эффективности. Специального обсуждения заслуживает процедура управления БД. Она наиболее проста в однопользовательском режиме. В многопользовательском режиме и в распределенных БД процедура сильно усложняется. При одновременном доступе нескольких пользователей без принятия специальных мер возможно нарушение целостности. Для устранения этого явления используют систему транзакций и режим блокировки таблиц или отдельных записей. Транзакция - процесс изменения файла, записи или базы данных, вызванный передачей одного входного сообщения. На этапе физического проектирования решаются вопросы, связанные с производительностью системы, определяются структуры хранения данных и методы доступа. Взаимодействие между этапами проектирования и словарной системой необходимо рассматривать отдельно. Процедуры проектирования могут использоваться независимо в случае 27 отсутствия словарной системы. Сама словарная система может рассматриваться как элемент автоматизации проектирования. Средства проектирования и оценочные критерии используются на всех стадиях разработки. В настоящее время неопределенность при выборе критериев является наиболее слабым местом в проектировании БД. Это связано с трудностью описания и идентификации большого числа альтернативных решений. Проще обстоит дело при работе с количественными критериями, к которым относятся время ответа на запрос, стоимость модификации, стоимость памяти, время на создание, стоимость на реорганизацию. Затруднение может вызывать противоречие критериев друг другу. В то же время существует много критериев оптимальности, являющихся неизмеримыми свойствами, трудно выразимыми в количественном представлении или в виде целевой функции. К качественным критериям могут относиться гибкость, адаптивность, доступность для новых пользователей, совместимость с другими системами, возможность конвертирования в другую вычислительную среду, возможность восстановления, возможность распределения и расширения. Процесс проектирования является длительным и трудоемким и обычно продолжается несколько месяцев. Основными ресурсами проектировщика БД являются его собственная интуиция и опыт, поэтому качество решения во многих случаях может оказаться низким. Основными причинами низкой эффективности проектируемых БД могут быть:  недостаточно глубокий анализ требований (начальные этапы проектирования), включая их семантику и взаимосвязь данных;  большая длительность процесса структурирования, делающая этот процесс утомительным и трудно выполняемым при ручной обработке. В этих условиях важное значение приобретают вопросы автоматизации разработки. 28 Основные этапы разработки БД. Этап 1. Уточнение задач На первом этапе составляется список всех основных задач, которые в принципе должны решаться этим приложением, – включая и те, которые не нужны сегодня, но могут появиться в будущем. Под «основными» задачами понимаются функции, которые должны быть представлены в формах или отчетах приложения. Этап 2. Последовательность выполнения задач Для того, чтобы приложение работало логично и удобно, лучше всего объединить основные задачи в тематические группы и затем упорядочить задачи каждой группы так, чтобы они располагались в порядке их выполнения. Может получиться так, что некоторые задачи будут связаны с разными группами или, что выполнение некоторой задачи должно предшествовать выполнению другой, принадлежащей к иной группе. Этап 3. Анализ данных После формирования списка задач, наиболее важным этапом является составление подробного перечня всех данных, необходимых для решения каждой задачи. Некоторые данные понадобятся в качестве исходных и меняться не будут. Другие данные будут проверяться и изменяться в ходе выполнения задачи. Некоторые элементы данных могут быть удалены или добавлены. И наконец, некоторые данные будут получены с помощью вычислений: их вывод будет частью задачи, но в базу данных вноситься они не будут. Этап 4. Определение структуры данных После предварительного анализа всех необходимых элементов данных нужно упорядочить их по объектам и соотнести объекты с таблицами и запросами базы данных. Для реляционных баз данных типа Access используется процесс, называемый нормализацией, в результате которого вырабатывается наиболее эффективный и гибкий способ хранения данных. Этап 5. Разработка макета приложения и пользовательского интерфейса После задания структуры таблиц приложения, в Microsoft Access легко создать его макет с помощью форм и связать их между собой, используя несложные макросы или процедуры обработки событий. Предварительный рабочий макет легко продемонстрировать заказчику и получить его одобрение еще до детальной реализации задач приложения. 29 Этап 6. Создание приложения В случае очень простых задач созданный макет является практически законченным приложением. Однако довольно часто приходится писать процедуры, позволяющие полностью автоматизировать решение всех намеченных в проекте задач. Поэтому, понадобится создать специальные связующие формы, которые обеспечивают переход от одной задачи к другой. Этап 7. Тестирование и усовершенствование После завершения работ по отдельным компонентам приложения необходимо проверить функционирование приложения в каждом из возможных режимов. Необходимо проверить работу макросов, для этого использовав пошаговый режим отладки, при котором будет выполняться одна конкретная макрокоманда. При использовании Visual Basic для приложений в вашем распоряжении имеются разнообразные средства отладки, позволяющие проверить работу приложения, выявить и исправить ошибки. По мере разработки автономных разделов приложения желательно передать их заказчику для проверки их функционирования и получения мнения о необходимости внесения тех или иных изменений. После того как заказчик ознакомится с работой приложения, у него практически всегда возникают дополнительные предложения по усовершенствованию, какой бы тщательной не была предварительная проработка проекта. Пользователи часто обнаруживают, что некоторые моменты, о которых в процессе постановки задач, они говорили как об очень важных и необходимых, на самом деле не играют существенной роли при практическом использовании приложения. Выявление необходимых изменений на ранних стадиях разработки приложения позволяет существенно сократить время на последующие переделки. 30 4 Модели организации баз данных Различают три основные модели базы данных – это иерархическая, сетевая и реляционная. Эти модели отличаются между собой по способу установления связей между данными. 1. Иерархический подход к организации баз данных. Иерархические базы данных имеют форму деревьев с дугами-связями и узламиэлементами данных. Иерархическая структура предполагала неравноправие между данными – одни жестко подчинены другим. Подобные структуры, безусловно, четко удовлетворяют требованиям многих, но далеко не всех реальных задач. 2. Сетевая модель данных. В сетевых БД наряду с вертикальными реализованы и горизонтальные связи. Однако унаследованы многие недостатки иерархической и главный из них, необходимость четко определять на физическом уровне связи данных и столь же четко следовать этой структуре связей при запросах к базе. 3. Реляционная модель. Реляционная модель появилась вследствие стремления сделать базу данных как можно более гибкой. Данная модель предоставила простой и эффективный механизм поддержания связей данных. Во-первых, все данные в модели представляются в виде таблиц и только таблиц. Реляционная модель – единственная из всех обеспечивает единообразие представления данных. И сущности, и связи этих самых сущностей представляются в модели совершенно одинаково – таблицами. Правда, такой подход усложняет понимание смысла хранящейся в базе данных информации, и, как следствие, манипулирование этой информацией. Избежать трудностей манипулирования позволяет второй элемент модели – реляционно-полный язык (отметим, что язык является неотъемлемой частью любой модели данных, без него модель не существует). Полнота языка в приложении к реляционной модели означает, что он должен выполнять любую операцию реляционной алгебры или реляционного исчисления (полнота последних доказана математически Э.Ф. Коддом). Более того, язык должен описывать любой запрос в виде операций с таблицами, а не с их строками. Одним из таких языков является SQL. Третий элемент реляционной модели требует от реляционной модели поддержания некоторых ограничений целостности. Одно из таких ограничений утверждает, что каждая строка в таблице должна иметь некий уникальный идентификатор, называемый первичным ключом. 31 Второе ограничение накладывается на целостность ссылок между таблицами. Оно утверждает, что атрибуты таблицы, ссылающиеся на первичные ключи других таблиц, должны иметь одно из значений этих первичных ключей. 4. Объектно-ориентированная модель. Новые области использования вычислительной техники, такие как научные исследования, автоматизированное проектирование и автоматизация учреждений, потребовали от баз данных способности хранить и обрабатывать новые объекты – текст, аудио- и видеоинформацию, а также документы. Основные трудности объектно-ориентированного моделирования данных проистекают из того, что такого развитого математического аппарата, на который могла бы опираться общая объектно-ориентированная модель данных, не существует. В большой степени, поэтому до сих пор нет базовой объектно-ориентированной модели. С другой стороны, некоторые авторы утверждают, что общая объектно-ориентированная модель данных в классическом смысле и не может быть определена по причине непригодности классического понятия модели данных к парадигме объектной ориентированности. Несмотря на преимущества объектно-ориентированных систем – реализация сложных типов данных, связь с языками программирования и т.п. – на ближайшее время превосходство реляционных СУБД гарантировано. Рассмотрим более подробно эти модели данных далее. Иерархическая модель базы данных Иерархические базы данных — самая ранняя модель представления сложной структуры данных. Информация в иерархической базе организована по принципу древовидной структуры, в виде отношений «предок-потомок». Каждая запись может иметь не более одной родительской записи и несколько подчиненных. Связи записей реализуются в виде физических указателей с одной записи на другую. Основной недостаток иерархической структуры базы данных — невозможность реализовать отношения «много-ко-многим», а также ситуации, когда запись имеет несколько предков. Иерархические базы данных. Иерархические базы данных графически могут быть представлены как перевернутое дерево, состоящее из объектов различных уровней. Верхний уровень (корень дерева) занимает один объект, второй - объекты второго уровня и так далее. Между объектами существуют связи, каждый объект может включать в себя несколько объектов более низкого уровня. Такие 32 Рисунок 4.1 Иерархическая база данных Каталог папок Windows объекты находятся в отношении предка (объект, более близкий к корню) к потомку (объект более низкого уровня), при этом объект-предок может не иметь потомков или иметь их несколько, тогда как объект-потомок обязательно имеет только одного предка. Объекты, имеющие общего предка, называются близнецами. Иерархической базой данных является Каталог папок Windows, с которым можно работать, запустив Проводник. Верхний уровень занимает папка Рабочий стол. На втором уровне находятся папки Мой компьютер, Мои документы, Сетевое окружение и Корзина, которые являются потомками папки Рабочий стол, а между собой является близнецами. В свою очередь, папка Мой компьютер является предком по отношению к папкам третьего уровня -папкам дисков (Диск 3,5(А:), (С:), (D:), (Е:), (F:)) и системным папкам (сканер, bluetooth и.т.д.) - рис. 4.1. Организация данных в СУБД иерархического типа определяется в терминах: элемент, агрегат, запись (группа), групповое отношение, база данных. • Атрибут (элемент данных) - наименьшая единица структуры данных. Обычно каждому элементу при описании базы данных присваивается уникальное имя. По этому имени к нему обращаются при обработке. Элемент данных также часто называют полем. • Запись - именованная совокупность атрибутов. Использование записей позволяет за одно обращение к базе получить некоторую логически связанную совокупность данных. Именно записи изменяются, добавляются и удаляются. Тип записи определяется составом ее 33 атрибутов. Экземпляр записи - конкретная запись с конкретным значением элементов • Групповое отношение - иерархическое отношение между записями двух типов. Родительская запись (владелец группового отношения) называется исходной записью, а дочерние записи (члены группового отношения) - подчиненными. Иерархическая база данных может хранить только такие древовидные структуры. Корневая запись каждого дерева обязательно должна содержать ключ с уникальным значением. Ключи некорневых записей должны иметь уникальное значение только в рамках группового отношения. Каждая запись идентифицируется полным сцепленным ключом, под которым понимается совокупность ключей всех записей от корневой по иерархическому пути. При графическом изображении групповые отношения изображают дугами ориентированного графа, а типы записей - вершинами (диаграмма Бахмана). Для групповых отношений в иерархической модели обеспечивается автоматический режим включения и фиксированное членство. Это означает, что для запоминания любой некорневой записи в БД должна существовать ее родительская запись. Пример: Рассмотрим следующую модель данных предприятия (см. рисунок 4.2): предприятие состоит из отделов, в которых работают сотрудники. В каждом отделе может работать несколько сотрудников, но сотрудник не может работать более чем в одном отделе. Поэтому, для информационной системы управления персоналом необходимо создать групповое отношение, состоящее из родительской записи ОТДЕЛ (НАИМЕНОВАНИЕ_ОТДЕЛА, ЧИСЛО_РАБОТНИКОВ) и дочерней записи СОТРУДНИК (ФАМИЛИЯ, ДОЛЖНОСТЬ, ОКЛАД). Это отношение показано на рисунке 4.2 (а) (Для простоты полагается, что имеются только две дочерние записи). Для автоматизации учета контрактов с заказчиками необходимо создание еще одной иерархической структуры: заказчик - контракты с ним - сотрудники, задействованные в работе над контрактом. Это дерево будет включать записи ЗАКАЗЧИК (НАИМЕНОВАНИЕ_ЗАКАЗЧИКА, АДРЕС), КОНТРАКТ(НОМЕР, ДАТА,СУММА), ИСПОЛНИТЕЛЬ (ФАМИЛИЯ, ДОЛЖНОСТЬ, НАИМЕНОВАНИЕ_ОТДЕЛА) (рисунок 4.2b). Из этого примера видны недостатки иерархических БД: 34 Рисунок 4.2. Пример иерархической базы данных Частично дублируется информация между записями СОТРУДНИК и ИСПОЛНИТЕЛЬ (такие записи называют парными), причем в иерархической модели данных не предусмотрена поддержка соответствия между парными записями. Иерархическая модель реализует отношение между исходной и дочерней записью по схеме 1:N, то есть одной родительской записи может соответствовать любое число дочерних. Допустим теперь, что исполнитель может принимать участие более чем в одном контракте (т.е. возникает связь типа M:N). В этом случае в базу данных необходимо ввести еще одно групповое отношение, в котором ИСПОЛНИТЕЛЬ будет являться исходной записью, а КОНТРАКТ – дочерней (рисунок 4.2 c). Таким образом, мы опять вынуждены дублировать информацию. Операции над данными, определенные в иерархической модели: 35 • ДОБАВИТЬ в базу данных новую запись. Для корневой записи обязательно формирование значения ключа. • ИЗМЕНИТЬ значение данных предварительно извлеченной записи. Ключевые данные не должны подвергаться изменениям. • УДАЛИТЬ некоторую запись и все подчиненные ей записи. • ИЗВЛЕЧЬ: извлечь корневую запись по ключевому значению, допускается также последовательный просмотр корневых записей извлечь следующую запись (следующая запись извлекается в порядке левостороннего обхода дерева) В операции ИЗВЛЕЧЬ допускается задание условий (например, извлечь сотрудников с окладом более 10 тысяч руб.) Как видим, все операции изменения применяются только "текущей" записи (которая предварительно извлечена из базы Такой подход к манипулированию данных получил "навигационного". Ограничения целостности. выборки к одной данных). название Поддерживается только целостность связей между владельцами и членами группового отношения (никакой потомок не может существовать без предка). Как уже отмечалось, не обеспечивается автоматическое поддержание соответствия парных записей, входящих в разные иерархии. Сетевая модель базы данных. На разработку этого стандарта большое влияние оказал американский ученый Ч.Бахман. Основные принципы сетевой модели данных были разработаны в середине 60-х годов, эталонный вариант сетевой модели данных описан в отчетах рабочей группы по языкам баз данных (COnference on DAta SYstem Languages) CODASYL (1971 г.). Сетевая модель данных определяется в тех же терминах, что и иерархическая. Она состоит из множества записей, которые могут быть владельцами или членами групповых отношений. Связь между записьювладельцем и записью-членом также имеет вид 1:N. Основное различие этих моделей состоит в том, что в сетевой модели запись может быть членом более чем одного группового отношения. Согласно этой модели каждое групповое отношение именуется и проводится различие между его типом и экземпляром. Тип группового отношения задается его именем и определяет свойства общие 36 для всех экземпляров данного типа. Экземпляр группового отношения представляется записью-владельцем и множеством (возможно пустым) подчиненных записей. При этом имеется следующее ограничение: экземпляр записи не может быть членом двух экземпляров групповых отношений одного типа (т.е. сотрудник из примера в п..1, например, не может работать в двух отделах). Иерархическая структура рисунок 4.2 преобразовывается в сетевую следующим образом (см. рисунок 4.3): - деревья (a) и (b), показанные на рисунке 4.2, заменяются одной сетевой структурой, в которой запись СОТРУДНИК входит в два групповых отношения; - для отображения типа M:N вводится запись СОТРУДНИК_КОНТРАКТ, которая не имеет полей и служит только для связи записей КОНТРАКТ и СОТРУДНИК, см. рис. 4.3 (Отметим, что в этой записи может храниться и полезная информация, например, доля данного сотрудника в общем вознаграждении по данному контракту.) Рисунок 4.3. Сетевая модель базы данных Каждый экземпляр группового отношения следующими признаками: способ упорядочения подчиненных записей: • произвольный, характеризуется 37 • хронологический /очередь/, • обратный хронологический /стек/, • сортированный. Если запись объявлена подчиненной в нескольких групповых отношениях, то в каждом из них может быть назначен свой способ упорядочивания. режим включения подчиненных записей: автоматический - невозможно занести в БД запись без того, чтобы она была сразу же закреплена за неким владельцем; ручной - позволяет запомнить в БД подчиненную запись и не включать ее немедленно в экземпляр группового отношения. Эта операция позже инициируется пользователем). режим исключения. Принято выделять три класса членства подчиненных записей в групповых отношениях: • Фиксированное. Подчиненная запись жестко связана с записью владельцем и ее можно исключить из группового отношения только удалив. При удалении записи–владельца все подчиненные записи автоматически тоже удаляются. В рассмотренном выше примере фиксированное членство предполагает групповое отношение "ЗАКЛЮЧАЕТ" между записями "КОНТРАКТ" и "ЗАКАЗЧИК", поскольку контракт не может существовать без заказчика. • Обязательное. Допускается переключение подчиненной записи на другого владельца, но невозможно ее существование без владельца. Для удаления записи-владельца необходимо, чтобы она не имела подчиненных записей с обязательным членством. Таким отношением связаны записи "СОТРУДНИК" и "ОТДЕЛ". Если отдел расформировывается, все его сотрудники должны быть либо переведены в другие отделы, либо уволены. • Необязательное. Можно исключить запись из группового отношения, но сохранить ее в базе данных не прикрепляя к другому владельцу. При удалении записи-владельца ее подчиненные записи - необязательные члены сохраняются в базе, не участвуя более в групповом отношении такого типа. Примером такого группового отношения может служить "ВЫПОЛНЯЕТ" между "СОТРУДНИКИ" и "КОНТРАКТ", поскольку в организации могут существовать работники, чья деятельность не связана с выполнением каких-либо договорных обязательств перед заказчиками. 38 Операции над данными в сетевой модели БД. • ДОБАВИТЬ - внести запись в БД и, в зависимости от режима включения, либо включить ее в групповое отношение, где она объявлена подчиненной, либо не включать ни в какое групповое отношение. • ВКЛЮЧИТЬ В ГРУППОВОЕ ОТНОШЕНИЕ - связать существующую подчиненную запись с записью-владельцем. • ПЕРЕКЛЮЧИТЬ - связать существующую подчиненную запись с другой записью-владельцем в том же групповом отношении. • ОБНОВИТЬ - изменить значение элементов предварительно извлеченной записи. • ИЗВЛЕЧЬ - извлечь записи последовательно по значению ключа, а также используя групповые отношения - от владельца можно перейти к записям - членам, а от подчиненной записи к владельцу набора. • УДАЛИТЬ - убрать из БД запись. Если эта запись является владельцем группового отношения, то анализируется класс членства подчиненных записей. Обязательные члены должны быть предварительно исключены из группового отношения, фиксированные удалены вместе с владельцем, необязательные останутся в БД. • ИСКЛЮЧИТЬ ИЗ ГРУППОВОГО ОТНОШЕНИЯ - разорвать связь между записью-владельцем и записью-членом. Ограничения целостности. Как и в иерархической модели обеспечивается только поддержание целостности по ссылкам (владелец отношения - член отношения). Достоинства и недостатки ранних СУБД Достоинства ранних СУБД: • развитые средства управления данными во внешней памяти на низком уровне; • возможность построения вручную эффективных прикладных систем; • возможность экономии памяти за счет разделения подобъектов (в сетевых системах) Недостатки ранних СУБД • сложность использования; • высокий уровень требований к знаниям о физической организации БД; • зависимость прикладных систем от физической организации БД; • перегруженность логики прикладных систем деталями организации доступа к БД. 39 Как иерархическая, так и сетевая модель данных предполагает наличие высококвалифицированных программистов. И даже в таких случаях реализация пользовательских запросов часто затягивается на длительный срок. Объектно-ориентированные СУБД Появление объектно-ориентированных СУБД вызвано потребностями программистов на ОО-языках, которым были необходимы средства для хранения объектов, не помещавшихся в оперативной памяти компьютера. Также важна была задача сохранения состояния объектов между повторными запусками прикладной программы. Поэтому, большинство ООСУБД представляют собой библиотеку, процедуры управления данными которой включаются в прикладную программу. Примеры реализации ООСУБД как выделеного сервера базы данных крайне редки. Сразу же необходимо заметить, что общепринятого определения "объектно-ориентированной модели данных" не существует. Сейчас можно говорить лишь о неком "объектном" подходе к логическому представлению данных и о различных объектно-ориентированных способах его реализации. Мы знаем, что любая модель данных должна включать три аспекта: структурный, целостный и манипуляционный. Посмотрим, как они реализуются на основе объектно-ориентированная парадигмы программирования: Структура: Структура объектной модели описываются с помощью трех ключевых понятий: инкапсуляция - каждый объект обладает некоторым внутренним состоянием (хранит внутри себя запись данных), а также набором методов - процедур, с помощью которых (и только таким образом) можно получить доступ к данным, определяющим внутреннее состояние объекта, или изменить их. Таким образом, объекты можно рассматривать как самостоятельные сущности, отделенные от внешнего мира; наследование - подразумевает возможность создавать из классов объектов новые классы объекты, которые наследуют структуру и методы своих предков, добавляя к ним черты, отражающие их собственную индивидуальность. Наследование может быть простым (один предок) и множественным (несколько предков); 40 полиморфизм - различные объекты могут по разному реагировать на одинаковые внешние события в зависимости от того, как реализованы их методы. Целостность данных: Для поддержания целостности объектно-ориентированный подход предлагает использовать следующие средства: автоматическое поддержание отношений наследования возможность объявить некоторые поля данных и методы объекта как "скрытые", не видимые для других объектов; такие поля и методы используются только методами самого объекта создание процедур контроля целостности внутри объекта Средства манипулирования данными: К сожалению, в объектно-ориентированном программировании отсутствуют общие средства манипулирования данными, такие как реляционная алгебра или реляционное счисление. Работа с данными ведется с помощью одного из объектно-ориентированных языков программирования общего назначения, обычно это SmallTalk, C++ или Java. Подведем теперь некоторые итоги: В объектно-ориентированных базах данных, в отличие от реляционных, хранятся не записи, а объекты. ОО-подход представляет более совершенные средства для отображения реального мира, чем реляционная модель, естественное представление данных. В реляционной модели все отношения принадлежат одному уровню, именно это осложняет преобразование иерархических связей модели "сущностьсвязь" в реляционную модель. ОО-модель можно рассматривать послойно, на разных уровнях абстракции. Имеется возможность определения новых типов данных и операций с ними. В то же время, ОО-модели присущ и ряд недостатков: • осутствуют мощные непроцедурные средства извлечения объектов из базы. Все запросы приходится писать на процедурных языках, проблема их оптимизации возлагается на программиста; • вместо чисто декларативных ограничений целостности (типа явного объявления первичных и внешних ключей реляционных таблиц с помощью ключевых слов PRIMARY KEY и REFERENCES) или полудекларативных триггеров для обеспечения внутренней целостности приходится писать процедурный код. Очевидно, что оба эти недостатка связаны с отсутствием развитых средств манипулирования данными. Эта задача решается двумя 41 способами - расширение ОО-языков в сторону управления данными (стандарт ODMG), либо добавление объектных свойств в реляционные СУБД (SQL-3, а также так называемые объектно-реляционных СУБД). Объектно-реляционные СУБД Разница между объектно-реляционными и объектными СУБД: первые являют собой надстройку над реляционной схемой, вторые же изначально объектно-ориентированы. Главная особенность и отличие объектно-реляционных, как и объектных, СУБД от реляционных заключается в том, что О(Р)СУБД интегрированы с ОбъектноОриентированным (OO) языком программирования, внутренним или внешним как C++, Java. Характерные свойства OРСУБД - 1) комплексные данные, 2) наследование типа, и 3) объектное поведение. Комплексные данные могут быть реализованы через постояннохранимые объекты (persistent objects). Создание комплексных данных в большинстве существующих ОРСУБД основано на предварительном определении схемы через определяемый пользователем тип (UDT - userdefined type). Используются также встроенные конструкторы составных типов, например массив (ARRAY). Иерархия структурных комплексных данных предлагает дополнительное свойство, наследование типа. То есть структурный тип может иметь подтипы, которые используют все его атрибуты и содержат дополнительные атрибуты, специфицированные в подтипе. Объектное поведение закладывается через описание программных объектов. Такие объекты должны быть сохраняемыми и переносимыми для обработки в базе данных, поэтому они называются обычно как постоянные (или долговременные) объекты. Внутри базы данных все отношения с постоянным программным объектом есть отношения с его объектным идентификатором (OID). Объектно-реляционными СУБД являются, к примеру, широко известные Oracle Database, Microsoft SQL Server 2005, PostgreSQL, а также Sav Zigzag, IBM Cloudscape, 42 5 Реляционный подход к построению инфологической модели Реляционная модель данных Реляционная модель есть представление БД в виде совокупности упорядоченных нормализованных отношений. Для реляционных отношений характерны следующие особенности. 1. Любой тип записи содержит только простые (по структуре) элементы данных. 2. Порядок кортежей в таблице несуществен. 3. Упорядочение значащих атрибутов в кортеже должно соответствовать упорядочению атрибутов в реляционном отношении. 4. Любое отношение должно содержать один атрибут или более, которые вместе составляют уникальный первичный ключ. 5. Если между двумя реляционными отношениями существует зависимость, то одно отношение является исходным, второе – подчиненным. 6. Чтобы между двумя реляционными отношениями существовала зависимость, атрибут, служащие первичным ключом в исходном отношении, должны также присутствовать в подчиненном отношении. Пример 5.1. Представим БД «Учебный процесс»в виде реляционной модели (табл. 5.1). Таблица 5.1. а) Отношение ГРУППА Индекс ИГ Название группы НГ Количество ответов КОЛ Проходной балл ПБАЛЛ 1 2 3 А1 А2 А3 16 28 18 4,3 4,0 4,3 Фамилия, и.о СФИО Год рождения б) Отношение СТУДЕНТ Номер зачетной книжки НЗ ИГ Понятие реляционный (англ. relation — отношение) связано с разработками известного американского специалиста в области систем баз данных Е. Кодда. 43 Эти модели характеризуются простотой структуры данных, удобным для пользователя табличным представлением и возможностью использования формального аппарата алгебры отношений и реляционного исчисления для обработки данных. Реляционная модель ориентирована на организацию данных в виде двумерных таблиц. Каждая реляционная таблица представляет собой двумерный массив и обладает следующими свойствами: • каждый элемент таблицы — один элемент данных; • все столбцы в таблице однородные, т.е. все элементы в столбце имеют одинаковый тип (числовой, символьный и т.д.) и длину; • каждый столбец имеет уникальное имя; • одинаковые строки в таблице отсутствуют; • порядок следования строк и столбцов может быть произвольным. Пример 1. Реляционной таблицей можно представить информацию о студентах, обучающихся в вузе (рисунок 5.1). № личного дела 16493 16593 16693 Фамилия Имя Отчество Дата рождения Группа Сергеев Петр Михайлович 01.01.76 Петрова Анна Владимировна 15.03.75 Анохин Андрей Борисович 14.04.76 ИСТ 11 СК 12 ИСТ 11 Рисунок 5.1. Пример реляционной таблицы Понятие информационного объекта Информационный объект — это описание некоторой сущности (реального объекта, явления, процесса, события) в виде совокупности логически связанных реквизитов (информационных элементов). Такими сущностями для информационных объектов могут служить: цех, склад, материал, вуз, студент, сдача экзаменов и т.д. Информационный объект определенного реквизитного состава и структуры образует класс (тип), которому присваивается уникальное имя (символьное обозначение), например Студент, Сессия, Стипендия. Информационный объект имеет множество реализации — экземпляров, каждый из которых представлен совокупностью конкретных значений реквизитов и идентифицируете* значением ключа (простого — один реквизит или составного — несколько реквизитов). Остальные реквизиты информационного объекта являются описательными. При этом одни и те же реквизиты в одних информационных объектах могут быть ключевыми, а в других— описательными. Информационный объект может иметь несколько ключей. 44 Пример 2. На рис. 5.2 представлен пример структуры и экземпляров информационного объекта Студент. В информационном объекте Студент ключом является реквизит Номер (№ личного дела), к описательным реквизитам относятся: Фамилия (Фамилия студента), Имя (Имя студента). Отчество (Отчество студента). Дата (Дата рождения), Группа (№ группы). Если отсутствует реквизит Номер, то для однозначного определения характеристик конк4ретного студента необходимо использование составного ключа из трех реквизитов: Фамилия + Имя + Отчество. Структура Номер Фамилия Имя Отчество Дата Группа Михайлович 01.01.96 ИСТ 11 Экземпляры 16493 Сергеев Петр инф.объекта 16593 Петрова Анна Владимировна 15.03.95 СК 12 Студент 16693 Анохин Андрей Борисович 14.04.96 ИСТ 11 Рисунок 5.2. Пример структуры и экземпляров информационного объекта Пример 3. На рис. 5.3 изображен пример компактного представления информационного объекта Студент с обозначением имени объекта, ключа и указанием максимально возможного числа экземпляров записи. Студент 150 Номер Рисунок 5.3. Пример компактного представления информационного объекта Пример 4. Пример представления информационного объекта Студент в виде графа на рис. 5.4. Рисунок 5.4. Пример представления информационного объекта в виде графа Нормализация отношений Понятие нормализации отношений Одни и те же данные могут группироваться в таблицы (отношения) различными способами, т.е. возможна организация 45 различных наборов отношений взаимосвязанных информационных объектов. Группировка атрибутов в отношениях должна быть рациональной, т.е. минимизирующей дублирование данных и упрощающей процедуры их обработки и обновления. Определенный набор отношений обладает лучшими свойствами при включении, модификации, удалении данных, чем все остальные возможные наборы отношений, если он отвечает требованиям нормализации отношений. Нормализация отношений — формальный аппарат ограничений на формирование отношений (таблиц), который позволяет устранить дублирование, обеспечивает непротиворечивость хранимых в базе данных, уменьшает трудозатраты на ведение (ввод, корректировку) базы данных. [2] Е. Коддом выделены три нормальные формы отношений и предложен механизм, позволяющий любое отношение преобразовать к третьей (самой совершенной) нормальной форме. Первая нормальная форма Отношение называется нормализованным или приведенным к первой нормальной форме, если все его атрибуты простые (далее неделимы). Преобразование отношения к первой нормальной форме может привести к увеличению количества реквизитов (полей) отношения и изменению ключа. Например, отношение Студент = (Номер, Фамилия, Имя, Отчество, Дата, Группа) находится в первой нормальной форме. Вторая нормальная форма Чтобы рассмотреть вопрос приведения отношений ко второй нормальной форме, необходимо дать пояснения к таким понятиям, как функциональная зависимость и полная функциональная зависимость. Описательные реквизиты информационного объекта логически связаны с общим для них ключом, эта связь носит характер функциональной зависимости реквизитов. Функциональная зависимость реквизитов — зависимость, при которой в экземпляре информационного объекта определенному значению ключевого реквизита соответствует только одно значение описательного реквизита. Такое определение функциональной зависимости позволяет при анализе всех взаимосвязей реквизитов предметной области выделить самостоятельные информационные объекты. Пример 5. Пример графического изображения функциональных зависимостей реквизитов Студент показан на рисунке 5.5, на котором 46 ключевой реквизит указан *. Рисунок 5.5. Графическое изображение функциональной зависимости реквизитов В случае составного ключа вводится понятие функционально полной зависимости. Функционально полная зависимость неключевых атрибутов заключается в том, что каждый неключевой атрибут функционально зависит от ключа, но не находится в функциональной зависимости ни от какой части составного ключа. Таблица находится во второй нормальной форме, если она удовлетворяет требованиям первой нормальной формы и все ее поля, не входящие в первичный ключ, связаны полной функциональной зависимостью с первичным ключом, то есть любое не ключевое поле однозначно идентифицируется полным набором ключевых полей. Итак, таблица, находящаяся во второй нормальной форме, должна удовлетворять следующим правилам: • таблица должна содержать данные об одном типе объектов; • каждая таблица должна содержать одно поле или несколько полей, образующих уникальный идентификатор (или первичный ключ) для каждой строки; • все поля, не имеющие ключа, должны определяться полным уникальным идентификатором данной таблицы. Пример 6. находится в первой и во второй нормальной форме Отношение Студент = (Номер, Фамилия, Имя, одновременно, так как описательные реквизиты Отчество, Дата, Группа) однозначно определены и функционально зависят от Отношение Успеваемость = (Номер, Фамилия, Имя, Отчество, Дисциплина, оценка) ключа Номер. находится в первой нормальной форме и имеет составной ключ Номер + Дисциплина. Это отношение не находится во второй нормальной форме, так как атрибуты Фамилия, Имя, Отчество не находятся в полной функциональной зависимости с составным ключом отношения. Третья нормальная форма Понятие третьей нормальной формы нетранзитивной зависимости. основывается на понятии Транзитивная зависимость наблюдается в том случае, если один 47 из двух описательных реквизитов зависит от ключа, а другой описательный реквизит зависит от первого описательного реквизита. Таблица находится в третьей нормальной форме, если она удовлетворяет определению второй нормальной формы и ни одно из ее неключевых полей функционально не зависит от любого другого неключевого поля. Можно сказать, что таблица находится в третьей нормальной форме, если она находится во второй нормальной форме и каждое неключевое поле нетранзитивно зависит от первичного ключа. Требование третьей нормальной формы сводится к тому, чтобы все нёключевые поля зависели только от первичного ключа и не зависели друг от друга. Другими словами, нужно иметь возможность изменять значение любого неключевого поля, не изменяя значения любого другого поля базы данных. Это требование исключает любое поле, значения в котором получаются как результат вычислений, использующих значения других полей. Пример 7. Если в состав описательных реквизитов информационного объекта Студент включить фамилию старосты группы (Староста), которая определяется только номером группы, то одна и та же фамилия старосты будет многократно повторяться в разных экземплярах данного информационного объекта. В этом случае наблюдаются затруднения в корректировке фамилии старосты в случае назначения нового старосты, а также неоправданный расход памяти для хранения дублированной информации. Для устранения транзитивной зависимости описательных реквизитов необходимо провести "расщепление" исходного информационного объекта. В результате расщепления часть реквизитов удаляется из исходного информационного объекта и включается в состав других (возможно, вновь созданных) информационных объектов. Пример 8. "Расщепление" информационного объекта, содержащего транзитивную зависимость описательных реквизитов, показано на рис. 5.6. Как видно из рис. 5.6, исходный информационный объект Студент группы представляется в виде совокупности правильно структурированных информационных объектов (Студент и Группа), реквизитный состав которых тождественен исходному объекту. Отношение Студент = (Номер, Фамилия, Имя, Отчество, Дата, Группа) находится одновременно в первой, второй и третьей нормальной форме. 48 Рисунок 5.6. "Расщепление" информационного объекта, содержащего транзитивную зависимость описательных реквизитов. Типы связей Свойства отношений. Отсутствие кортежей-дубликатов. Из этого свойства вытекает наличие у каждого кортежа первичного ключа. Для каждого отношения, по крайней мере, полный набор его атрибутов является первичным ключом. Однако, при определении первичного ключа должно соблюдаться требование "минимальности", т.е. в него не должны входить те атрибуты, которые можно отбросить без ущерба для основного свойства первичного ключа - однозначно определять кортеж. Отсутствие упорядоченности кортежей. Отсутствие упорядоченности атрибутов. Для ссылки на значение атрибута всегда используется имя атрибута. Атомарность значений атрибутов, т.е. среди значений домена не могут содержаться множества значений (отношения). Реляционные базы данных состоят из нескольких таблиц, связь между которыми устанавливается с помощью совпадающих полей. Каждая запись в таблицах идентифицирует один объект. Отношение между объектами определяет отношение между таблицами. Существует 4 типа отношений: Отношение «один-к-одному» (1:1)означает, что каждая запись в одной таблице соответствует только одной записи в другой таблице. Отношение «один-ко-многим» (1 :М)означает, что каждой записи в одной таблице соответствует одна или несколько записей в другой таблице. Отношение «многие-ко-одному» (М:1)аналогично рассмотренному ранее типу. Тип отношения между объектами зависит от вашей точки зрения. Отношение «многие-ко-многим» (М:М).возникает между двумя таблицами в тех случаях, когда: В большинстве случаев любые две таблицы связаны отношением «одинко-многим». Это означает, что любая запись в первой таблице может быть 49 связана с несколькими записями во второй, однако любая запись второй таблицы связана только с одной записью в первой. Пример 9. Дана совокупность информационных объектов, отражающих учебный процесс в вузе: СТУДЕНТ (Номер, Фамилия, Имя, Отчество, Пол, Дата рождения, Группа) СЕССИЯ (Номер, Оценка1, Оценка2, ОценкаЗ, Оценка4, Результат) СТИПЕНДИЯ (Результат, Процент) ПРЕПОДАВАТЕЛЬ (Код преподавателя. Фамилия, Имя, Отчество) Связь один к одному (1:1) предполагает, что в каждый момент времени одному экземпляру информационного объекта А соответствует не более одного экземпляра информационного объекта В и наоборот. Рисунок 5.7 иллюстрирует указанный тип отношения. Рисунок 5.7. Графическое изображение реального отношения 1:1 Пример 10. Примером связи 1:1 может служить связь между информационными объектами СТУДЕНТ и СЕССИЯ: СТУДЕНТ <–> СЕССИЯ Каждый студент имеет определенный набор экзаменационных оценок в сессию. При связи один ко многим (1:М) одному экземпляру информационного объекта А соответствует 0, 1 или более экземпляров объекта В, но каждый экземпляр объекта В связан не более чем с 1 экземпляром объекта А. Графически данное соответствие имеет вид, представленный на рисунок 5.8. Рисунок 5.8. Графическое изображение реального отношения 1 :М Пример 11. Примером связи 1 :М служит связь между информационными объектами СТИПЕНДИЯ и СЕССИЯ: СТИПЕНДИЯ <-» СЕССИЯ Установленный размер стипендии по результатам сдачи сессии может повторяться многократно для различных студентов. Связь многие ко многим (М:М) предполагает, что в каждый момент времени одному экземпляру информационного объекта А соответствует 0, 1 или более экземпляров объекта В и наоборот. На 50 рисунке 5.9 графически представлено указанное соответствие. Рисунок 5.9. Графическое изображение реального отношения М:М Пример 12. Примером данного отношения служит связь между информационными объектами СТУДЕНТ и ПРЕПОДАВАТЕЛЬ: СТУДЕНТ «-» ПРЕПОДАВАТЕЛЬ Один студент обучается у многих преподавателей, один преподаватель обучает многих студентов. Простые и составные ключи Первичный ключ может состоять из единственного поля таблицы, значения которого уникальны для каждой записи. Так, например, на предприятии не может быть двух работников с одинаковыми табельными номерами, поэтому в таблице, содержащей записи о работниках, табельный номер может быть первичным ключом. Такой первичный ключ называют простым ключом. Если таблица не имеет единственного уникального поля, первичный ключ может быть составлен из нескольких полей, совокупность значений которых гарантирует уникальность. Так, имя, фамилия, отчество, номер паспорта, серия паспорта не могут быть первичными ключами по отдельности, так как могут оказаться одинаковыми у двух и более людей. Но не бывает двух личных документов одного типа с одинаковыми серией и номером. Поэтому в таблице, содержащей записи о людях, первичным ключом может быть набор полей, состоящий из типа личного документа, его серии и номера. Такой первичный ключ называют составным ключом Все остальные ключи отношения называются возможными ключами. В отличие от иерархической и сетевой моделей данных в реляционной отсутствует понятие группового отношения. Для отражения ассоциаций между кортежами разных отношений используется дублирование их ключей. Рассмотренный иерархический и сетевой пример базы данных, содержащей сведения о подразделениях предприятия и работающих в них сотрудниках, применительно к реляционной модели будет иметь вид: 51 Рисунок 5.10 База данных о подразделениях и сотрудниках предприятия. Например, связь между отношениями ОТДЕЛ и СОТРУДНИК создается путем копирования первичного ключа "Номер_отдела" из первого отношения во второе. Таким образом: - для того, чтобы получить список работников данного подразделения, необходимо из таблицы ОТДЕЛ установить значение атрибута "Номер_отдела", соответствующее данному "Наименованию_отдела" выбрать из таблицы СОТРУДНИК все записи, значение атрибута "Номер_отдела" которых равно полученному на предыдущем шаге. - для того, чтобы узнать в каком отделе работает сотрудник, нужно выполнить обратную операцию: определяем "Номер_отдела" из таблицы СОТРУДНИК по полученному значению находим запись в таблице ОТДЕЛ. Атрибуты, представляющие собой копии ключей других отношений, называются внешними ключами. Иногда возникает потребность разбить одну таблицу на более мелкие – проблема может заключаться в том, что некоторые сведения из нее используются не слишком часто, или в том, что какие-то данные не предназначаются для всеобщего доступа. Например, часть информации о факультетах нужна только для рекламных целей и используется очень редко. С другой стороны, сведения о заработной плате должны быть доступны только определенным сотрудникам. В любом из этих случаев можно создать отдельную таблицу и связать ее с исходной таблицей отношением типа «один-к-одному». Это означает, что любая запись в первой таблице связана только с одной записью во второй. Если же между таблицами необходимо организовать связь «многие-ко-многим», то в Access придется создать дополнительную таблицу пересечения, с помощью которой одна связь будет сведена к двум связям типа «один-ко-многим». 52 6. Работа с СУБД MS Access Объекты Microsoft Access. Microsoft Access называет объектами все, что может иметь имя (в смысле Access). В базе данных Access основными объектами являются таблицы, запросы, формы, отчеты, макросы и модули. В других СУБД, как правило, термин база данных обычно относится только к файлам, в которых хранятся данные. В Microsoft Access база данных включает в себя все объекты, связанные с хранимыми данными, в том числе и те, которые определяются для автоматизации работы с ними. Ниже приведен список основных объектов базы данных Access. 1. Таблица. Объект, который определяется и используется для хранения данных. Каждая таблица включает информацию об объекте определенного типа, например о клиентах. Таблица содержит поля (столбцы), в которых хранятся различного рода данные, например фамилия или адрес клиента, и записи (которые называются также строками). В записи собрана вся информация о некотором объекте (человеке, образце продукции и т.п.). Для каждой таблицы можно определить первичный ключ (одно или несколько полей, содержащих уникальные для каждой записи значения) и один или несколько индексов, помогающих ускорить доступ к данным. 2. Запрос. Объект, который позволяет пользователю получить нужные данные из одной или нескольких таблиц. Для создания запроса можно использовать бланк QBE (запрос по образцу) или инструкции SQL (структурированный язык запросов). Можно создать запросы на выборку, обновление, удаление или добавление данных. С помощью запросов можно также создавать новые таблицы, используя данные из одной или нескольких существующих таблиц. 3. Форма. Объект, предназначенный в основном для ввода данных, отображения их на экране или управления работой приложения. Формы используются для того, чтобы реализовать требования пользователя к представлению данных из запросов или таблиц. Формы можно также распечатать. С помощью формы можно в ответ на некоторое событие, например изменение значения определенных данных, запустить макрос или процедуру VBA. 4. Отчет. Объект, предназначенный для создания документа, который впоследствии может быть распечатан или включен в документ другого приложения. 53 5. Макрос. Объект, представляющий собой структурированное описание одного или нескольких действий, которые должен выполнить Access в ответ на определенное событие. Например, можно определить макрос, который в ответ на выбор некоторого элемента в основной форме открывает другую форму. С помощью другого макроса можно осуществлять проверку значения некоторого поля при изменении его содержимого. В макрос можно включить дополнительные условия для выполнения или невыполнения тех или иных указанных в нем действий. Из одного макроса можно также запустить другой макрос или процедуру VBA. 6. Модуль. Объект, содержащий программы, написанные на языке Visual Basic для приложений. Модули могут быть независимыми объектами, содержащими функции, вызываемые из любого места приложения, но они могут быть и непосредственно «привязаны» к отдельным формам или отчетам для реакции на те или иные происходящие в них изменения. Страницы доступа. Страницы – служат для обеспечения доступа к данным, содержащимся в базе, удалённой от потребителя (например, через Интернет). 7. Концептуальные взаимосвязи объектов Access показаны на рис.6.3. Рисунок 6.3. Взаимосвязи основных объектов в Microsoft Access 54 Работа с таблицами Создание таблицы в режиме конструктора: 1. щёлкнуть по значку Создание таблицы в режиме конструктора. Откроется окно Конструктора. Список полей Список типов Кнопка выбора типа Панель редактирова-ния Рисунок 6.2 Вид таблицы в режиме конструктора 2. Заполнить имена полей, (перемещаясь по ячейкам с помощью клавиш Tab или стрелками управления курсором); 3. Выбрать из раскрывающегося списка типы данных; 4. Задать ключевое поле: • щёлкнуть на его имени правой кнопкой мыши и • в открывшемся контекстном меню выбрать пункт Ключевое поле. 5. Бланк закрывают, после чего дают таблице имя. Созданную таблицу открывают двойным щелчком на её значке. Новая таблица имеет только названия столбцов. 55 Переход из режима конструктора в режим таблицы и наоборот Рисунок 6.1 Вид в режиме таблицы При заполнении таблицы данными сохранение их происходит автоматически. Но если произошло изменение макета таблицы (ширина столбцов), то СУБД попросит подтверждение сохранения этих изменений. Для изменения структуры Таблицы её надо открыть в режиме Конструктора. Создание межтабличных связей Целостность данных - это набор правил, гарантирующих, что Access будет работать только с непротиворечивыми данными и разрешёнными операциями. Активизировать команду Сервис \ Схема данных В диалоговом окне Схема данных: 1. Щёлкнуть по кнопке Добавить таблицу. 2. В диалоговом окне из списков выбрать Таблицы, между которыми создаются связи. Закрыть окно Добавление таблицы. Искомые таблицы появятся в окне Схема данных.. 3. Выделить в 1-й таблице ключевое поле и с помощью мыши перетащить его на одноименное поле 2-й таблицы. При отпускании кнопки мыши откроется диалоговое окно Связи 4. Установить флаг Обеспечение целостности данных. 5. Щёлкнуть по кнопке Создать. Появится связь 1:1. Предположим, что требуется установить связь между таблицами "Кафедра" и "Преподаватель" через поле ККАФ (код кафедры). В таблице "Кафедра" это поле является уникальным ключом, а в таблице "Преподаватель" — внешним ключом. Если схема данных создается заново, то при нажатии на кнопку "Схема данных" поверх окна схемы данных появится окно "Добавление таблицы". В этом окне следует выделить требуемые таблицы и нажать "Добавить". 56 В результате в окно схемы данных будут добавлены графические образы двух таблиц: Необходимо перетащить мышью поле ККАФ таблица "Кафедра" на поле ККАФ таблицы "Преподаватель". В открывшемся окне "Изменение связей" следует установить флажок "Обеспечение целостности данных". В этом случае Access будет выдавать предупреждающие сообщения о неправильном вводе данных, если, например, в поле ККАФ подчиненной таблицы "Преподаватель" будет введено значение, отсутствующее в поле ККАФ базовой таблицы "Кафедра". 57 Обратите внимание, что Access автоматически определил тип связи как "один-ко-многим". Можно также установить флажки "каскадное обновление связей" и "каскадное удаление связей". В этом случае Access автоматически скорректирует (удалит) записи в подчиненных таблицах, если будут изменены записи в базовой таблице. После нажатия на кнопку "Создать", образы таблиц будут соединены связями как показано на рисунке. Ключевые в базовых таблицах выделяются жирным шрифтом. Для установления связей по составному ключу необходимо в окне "Изменение связей" в полях "Таблица/Запрос" и "Связанная таблица/запрос" вручную выбрать из списков пары связываемых полей. На рисунке показан пример связи по составному ключу. Если перетащить поле, не являющееся ключевым и не имеющее уникального индекса, на другое поле, которое также не является ключевым и не имеет уникального индекса, создается неопределенное отношение. В запросах, содержащих таблицы с неопределенным отношением, Microsoft Access по умолчанию отображает линию объединения между таблицами, но условия целостности данных при этом 58 не накладываются и нет гарантии уникальности записей в любой из таблиц. Образовавшиеся межтабличные данные отображаются в окне Схема данных в виде линий, соединяющие 2 поля разных таблиц. Одна из таблиц считается главной, а другая – связанной. Главная – это та таблица, которая участвует в связи своим ключевым полем. Связь между таблицами позволяет: • Исключить возможность удаления или изменения данных в ключевом поле главной таблицы, если с этим полем связаны поля других таблиц; Установить флаг Обеспечение целостности данных. • При удалении данных в ключевом поле главной таблицы автоматически удалить соответствующие данные в полях связанных таблиц. Установить дополнительно флаги Каскадное обновление связанных полей и Каскадное удаление связанных записей. Работа с запросами Запрос – это отбор записей в разнообразных формах, в соответствии с выбранными условиями. Запросы служат для извлечения данных из таблиц и предоставления их пользователю в удобном виде. Виды запросов: • На выборку; • Запрос с параметром (критерий задаёт сам пользователь) • Итоговые запросы (производят вычисления по заданному полю и выдают результат); • Запросы на изменение (позволяют автоматизировать - заполнение полей таблиц); • Перекрёстные запросы (позволяют создавать результирующие таблицы на основе результатов расчётов, полученных при анализе группы таблиц) Специфические запросы – запросы к серверу БД, написанные на языке запросов SQL Для подготовки используем закладку Создание и выбираем способ создания запроса. 59 Запросы и фильтры Запрос на выборку содержит условия отбора данных и возвращает выборку, соответствующую указанным условиям, без изменения возвращаемых данных. В Microsoft Access существует также понятие фильтра, который в свою очередь является набором условий, позволяющих отбирать подмножество записей или сортировать их. Сходство между запросами на выборку и фильтрами заключается в том, что и в тех и в других производится извлечение подмножества записей из базовой таблицы или запроса. Однако между ними существуют различия, которые нужно понимать, чтобы правильно сделать выбор, в каком случае использовать запрос, а в каком — фильтр. Основные отличия запросов и фильтров заключаются в следующем. • Фильтры не позволяют в одной строке отображать данные из нескольких таблиц, т. е. объединять таблицы. • Фильтры не дают возможности указывать поля, которые должны отображаться в результирующем наборе записей, они всегда отображают все поля базовой таблицы. • Фильтры не могут быть сохранены как отдельный объект в окне базы данных (они сохраняются только в виде запроса). • Фильтры не позволяют вычислять суммы, средние значения, подсчитывать количество записей и находить другие итоговые значения. Запросы могут использоваться только с закрытой таблицей или запросом. Фильтры обычно применяются при работе в режиме Формы или в режиме Таблицы для просмотра или изменения подмножества записей. Запрос можно использовать: • для просмотра подмножества записей таблицы без предварительного открытия этой таблицы или формы; • для того чтобы объединить в виде одной таблицы на экране данные из нескольких таблиц; • для просмотра отдельных полей таблицы; • для выполнения вычислений над значениями полей. Работа с формами Формы позволяют: • Вводить данные в таблицы БД без непосредственного доступа к самим таблицам; • Выводить результаты работы запросов в виде красиво оформленных форм. Существует два вида формирования структуры форм: • На основе таблицы; • На основе запроса. • Возможен и комбинированный (творческий) подход. 60 Работа с отчётами Отчёты служат для форматированного вывода данных на печатающее устройство. Здесь существуют средства ручного, автоматического и автоматизированного проектирования. Структура готового отчёта отличается от структуры формы только увеличенным количеством разделов. Кроме разделов заголовка, примечания и данных, отчёт может содержать разделы верхнего и нижнего колонтитулов. Если отчёт занимает более одной страницы, эти разделы необходимы для печати служебной информации, например номеров страниц. Мастер отчётов работает в шесть этапов. I. выбор таблицы или запросов, на которых отчёт базируется; выбор полей, отражаемых в отчёте; II. выбор полей группировки (уровней и интервалов группировки); III. выбор полей и методов сортировки; IV. выбор структуры отчёта печатного макета (блочный, ступенчатый, выровненный по левому краю и т.п.) V. выбор стиля оформления (из предложенного списка); VI. на последнем этапе выполняется сохранение отчёта под заданным именем. Более подробно работу с СУБД Microsoft Access можно изучить по специальной литературе, а практические навыки приобрести, выполнив лабораторные работы по созданию баз данных. 61 Литература Основная: "Информатика". Базовый курс. Учебник для ВУЗ, под ред. С. Симонович, СПБ, Питер, 2003. 2. “Информатика”, Учебник для ВУЗов /Под ред. Макаровой Н.В. Изд. 3-е, перераб. Москва, Финансы и статистика, 2007. Дополнительная: 3. Кошелев В.Е. - Access 2007. Эффективное использование. - М., Бином, 2008. 4. Чертовской В.Д. «Базы и банки данных: Учебное пособие СПб: Издво МГУП, 2001». 1. 62