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

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

Содержательная сторона задачи обычно требует обмена данными между группами АРМ, так как изменения в какие-либо данные могут вноситься в одной группе, а использоваться они могут в другой. На практике обмен информацией реализуется регламентной передачей файлов - через модемное соединение или «с курьером».

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

В современной технологии АРМ объединены в локальную сеть. АРМ - клиент выдает запросы на выборку и обновление данных, а СУБД исполняет их. Запросы клиента в соответствии с требованиями задачи сгруппированы в логические единицы работы (транзакции). Если все операции с базой данных, содержащиеся внутри транзакции, выполнены удачно, транзакция в целом также выполняется успешно (фиксируется). Если хотя бы одна из операций с БД внутри транзакции произведена неудачно, то все изменения в БД, происшедшие к этому моменту из транзакции, отменяются (происходит откат транзакции). Такое функционирование обеспечивает логическую целостность информации в базе данных.

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

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

Транзакция может вносить изменения (то есть добавлять, удалять и изменять записи) в одну или несколько таблиц базы данных. Выбранные для репликации таблицы специальным образом помечаются. Для каждой такой таблицы или группы ее строк, выбранной по заданному условию, определяется один узел (СУБД), в котором данные таблицы являются первичными. Это тот узел, в котором происходит наиболее активное обновление данных. Репликационному серверу, обслуживающему БД с первичными данными, задается описание тиражирования (replication definition). В этом описании, к примеру, могут быть заданы интервалы значений первичного ключа таблицы или какое-нибудь другое условие, при выполнении которого измененные данные будут тиражироваться из этого узла к подписчикам. Если условие не задано, то описание тиражирования действует для всех записей таблицы. Возможность тиражирования группы записей таблицы означает, в частности, что часть записей может быть первичными данными в каком- то одном узле, а еще часть - в других узлах. В одном или нескольких узлах (СУБД), которым нужны измененные данные, в обслуживающем его репликационном сервере создается подписка (subscription) на соответствующее описание тиражирования. Здесь будет поддерживаться (с небольшой задержкой) копия первичных данных.

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

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

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

СУБД, хранящая вторичные данные, может быть любой из ряда доступных через шлюз: будь то Oracle, Informix, DB2, RMS, ISAM и т.п.. СУБД, хранящая первичные данные, требует наличия менеджера журнала транзакций (Log Transfer Manager - LTM). Сейчас разработаны LTM для Sybase SQL Server и Oracle; на очереди другие СУБД. Интерфейс LTM является открытым, и в скором времени, возможно, подобные модули будут созданы для нестандартных источников данных.

Вообще, тиражирование данных может найти самое разнообразное применение:

- для разгрузки сервера, выполняющего активное обновление данных (OLTP) от сложных запросов, связанных с поддержкой принятия решений (decision-support);

- для консолидации данных от подразделений в центре;

- для обмена данными по медленным или ненадежным линиям связи;

- для поддержания резервной базы данных;

-для построения сети равноправных узлов, обменивающихся данными.

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

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

Исторически первым появился метод синхронного внесения изменений в несколько БД, называемый двухфазной фиксацией (2РС, two- phase commit). Этот механизм реализован сейчас практически всеми производителями СУБД. Суть метода двухфазной фиксации состоит в том, что при завершении транзакции серверы БД, участвующие в ней, получают команду «приготовиться к фиксации транзакции». После получения подтверждений от всех серверов транзакция фиксируется на кадом из них. Таким образом, в любой момент времени обеспечивается целостность данных в распределенной системе. Платой за это являются требование доступности всех участвующих серверов и линий связи во время проведения транзакции, а также невозможность работы приложений-клиентов при недоступности, например, удаленного сервера. Кроме того, необходимо высокое быстродействие линий связи для обеспечения приемлемого времени реакции у приложения-клиента.

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

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

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

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

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

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

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

Вместе с тем асинхронная репликация транзакций принципиально обеспечивает целостность информации, так как объектом обмена данными здесь является логическая единица работы - транзакция, а не просто данные из измененных таблиц.

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

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

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

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

В отличие от операционной системы, которая должна обеспечивать выполнение произвольных процессов, ВП подразделяются на несколько классов, каждый из которых спроектирован для наиболее оптимального выполнения задач определенного вида. Например, ВП CPU работают на потоки обслуживания клиентов, реализующие оптимизацию и логику выполнения запросов; ВП АIO выполняют операции асинхронного обмена с диском; ВП TLI контролируют сетевое взаимодействие.

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

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

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

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

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

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

2. БАЗА ДАННЫХ MS ACCESS

2.1. Microsoft Access - функционально полная реляционная СУБД

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

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

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

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

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

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

Связи-объединения. Между двумя таблицами может быть установлена связь-объединение по некоторому полю связи. Для связи-объединения может быть выбран один из трех способов объединения записей:

· Способ 1 - объединение только тех записей, в которых связанные поля обеих таблиц совпадают (производится по умолчанию);

· Способ 2 - объединение тех записей, в которых связанные поля обеих таблиц совпадают, а также объединение всех записей из первой таблицы, для которых нет связанных во второй, с пустой записью второй таблицы;

· Способ 3 - объединение тех записей, в которых связанные поля обеих таблиц совпадают, а также объединение всех записей из второй таблицы, для которых нет связанных в первой, с пустой записью первой таблицы.

Такой тип связи может быть определен, если связь характеризуется отношением 1:1 или 1:М, а также если тип отношения не может быть определен системой, то есть если не выполняются условия для этих отношений. Например, при выборе в главной таблице в качестве поля связи неключевого поля или поля, входящего в составной ключ, Access сообщает, что тип отношения не может быть определен. В этом случае между таблицами возможно установление только связи-объединения.

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

Создание схемы данных

Создание схемы данных начинается в окне Базы данных (Database) с выполнения команды Сервис|Схема данных (Tools|Relationships) или нажатия кнопки Схема данных (Relationships) на панели инструментов базы данных.

Включение таблиц в схему данных. После нажатия кнопки Схема данных (Relationships) открывается окно Добавление таблицы (Show Table) , в котором можно выбрать таблицы и запросы, включаемые в схему данных. Для размещения таблицы в окне Схема данных (Relationships) надо выделить ее в окне Добавление таблицы (Show Table) и нажать кнопку Добавить (Add). Для выделения нескольких таблиц надо, удерживая клавишу , щелкнуть мышью на каждой из этих таблиц. Включив все нужные таблицы в схему данных, нажать кнопку Закрыть (Close).

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

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

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

При создании связи по составному ключу необходимо выделить все поля, входящие в ключ главной таблицы, и перетащить их на одно из полей связи в подчиненной таблице. Для выделения всех полей, входящих в составной уникальный ключ, необходимо отмечать поля при нажатой клавише . После создания связи откроется окно Изменение связей (Edit Relationships). При этом в строке Тип отношения (Relationship Type) автоматически установится тип один-ко-многим (One-To-Many).

При составном ключе связи в окне Изменение связей (Edit Relationships) необходимо для каждого поля ключа в главной таблице ТАБЛИЦА/ЗАПРОС (Table/Query) выбрать соответствующее поле подчиненной таблицы, названной СВЯЗАННАЯ ТАБЛИЦА/ЗАПРОС (Related Table/Query).

Обеспечение целостности данных

При создании схемы данных пользователь включает в неё таблицы и устанавливает связи между ними. Для связей типа 1:1 и 1:М можно задать параметр обеспечения связной целостности данных, а также автоматическое каскадное обновление и удаление связанных записей.

Обеспечение связной целостности данных означает, что Access при корректировке базы данных обеспечивает для связанных таблиц контроль за соблюдением следующих условий:

· В подчиненную таблицу не может быть добавлена запись с несуществующим в главной таблице значением ключа связи;

· В главной таблице нельзя удалить запись, если не удалены связанные с ней записи в подчиненной таблице;

· Изменение значений ключа связи в записи главной таблицы невозможно, если в подчиненной таблице имеются связанные с ней записи.

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

Установление между двумя таблицами связи типа 1:М или 1:1 и задание для нее параметров целостности данных возможно только при следующих условиях:

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

· Обе таблицы сохраняются в одной базе данных Access;

· Главная таблица связывается с подчиненной по первичному простому или составному ключу (уникальному индексу) главной таблицы.

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

Каскадное обновление и удаление связанных записей

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

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

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

При удалении записей непосредственно в таблице или через форму выводится предупреждение о возможности удаления связанных записей.

Язык SQL (аббревиатура Structured Query Language) - это язык структурированных запросов, стандартный язык, предназначенный для создания баз данных, добавления новых и поддержки имеющихся данных, а также извлечения требуемой информации. Язык SQL с самого начала был создан, чтобы работать с данными из тех баз, которые следуют реляционной модели.

Каждому запросу MS Access можно сопоставить эквивалентную инструкцию SQL. В MS Access пользователи, знакомые с языком SQL, могут использовать его для просмотра и изменения запросов в режиме конструктора, определения свойств форм и отчетов, создания специальных запросов (запросы объединения, запросы к серверу и управляющие запросы), создания подчиненных запросов.

При создании каждого запроса MS Access автоматически составляет эквивалентную ему инструкцию SQL. Изменения, внесенные в инструкцию SQL, автоматически отражаются в бланке конструктора.

Просмотрим или изменим инструкцию SQL:

1. Выполнив анализ предметной области, создадим групповой запрос «Список студентов группы ДФД-31» на основании таблиц «Студент» и «Группа» (рис. 21), в который включим список следующих полей таблиц:

Группа.[Обозначение группы], Студент.[Номер зачетной книжки], Студент.Фамилия, Студент.Имя, Студент.Отчество, Студент.Год рождения, Студент.Адрес, Студент.[Домашний телефон], Студент.[Балл при поступлении].

В поле Группа.[Обозначение группы] используем условие отбора по коду группы: «ДФД-31».

Групповой запрос «Список студентов группы ДФД-31» в MS Access в режиме конструктора

2. Выберем Режим SQL в меню Вид или через кнопку «Режим SQL» на панели инструментов. На экране появится текущий запрос в режиме SQL эквивалентный созданному в режиме конструктора (рис. 22).

Запрос «Список студентов группы ДФД-31» в MS Access в режиме SQL

3. В этот запрос можно внести изменения, и эти изменения будут отражены в бланке конструктора. Например, попробуем удалить в текстовом окне режима SQL записи Студент.Адрес, Студент.[Домашний телефон], Студент.[Балл при поступлении].

Результат выполнения измененного запроса «Список студентов группы ДФД-31»

Основной инструкцией языка SQL, всегда содержащейся в запросе, является команда SELECT [2].

В простейшей форме эта команда занимается поиском информации в таблице. Она имеет следующий формат:

SELECT field1, field 2, …

FROM Table;

Здесь field1, field 2,… - список столбцов таблицы Table, которые должны быть представлены в результате запроса.

Для получения всей таблицы вместо списка столбцов необходимо поставить символ «*» (звездочка).

Команда SELECT имеет следующие параметры:

A. DISTINCT (получить список без повторений)

Формат: SELECT DISTINCT field1, field2, …

FROM Table;

B. ALL (получить список со всеми повторениями)

Формат: SELECT ALL field1, field2, …

FROM Table;

C. WHERE (извлечь нужные строки)

Формат: SELECT field1, field2, …

FROM Table WHERE predicate;

Здесь predicate - логическое выражение, которое может быть истинно или ложно для каждой записи таблицы.

D. ORDER BY (рассортировать выходные данные)

Формат: SELECT field1, field2, …

FROM Table

ORDER BY field1 DESC;

Это означает, что выходные данные будут рассортированы по столбцу field1 в порядке убывания (порядок возрастания задается по умолчанию или с помощью слова ASC).

E. GROUP BY (группировать выходные данные)

Формат: SELECT field1, field2, …

FROM Table

GROUP BY [field1, field2, …]

ORDER BY field1 DESC;

Группировка - это объединение записей в соответствии со значениями некоторого заданного поля.

Агрегатные функции

Существуют следующие основные агрегатные функции:

· Count - определение численности;

· Sum - определение суммы;

· First/Last - определение первого/последнего значения;

· Min/Max - определение минимума/максимума;

· Avg - определение среднего значения.

Для обозначения связи двух таблиц дополнительно к команде FROM используются атрибуты INNER JOIN и ON.

Так как в сложном запросе появляется несколько таблиц, то появляется необходимость указывать поле с обозначением таблицы, например, см. рис. 22.

С помощью атрибута INNER JOIN мы указали, что таблица «Студент» связана с таблицей «Группа». А с помощью атрибута ON мы указали, как именно связаны между собой две таблицы «Студент» и «Группа»: по полю Код группы (FROM Группа INNER JOIN Студент ON Группа.[Код группы] = Студент.[Код группы]).

С помощью атрибута WHERE мы указали, что нужно извлечь только строки, которые содержат запись в поле Группа.[Обозначение группы] «ДФД-31»: WHERE (((Группа.[Обозначение группы])="ДФД-31")).

ПРИМЕЧАНИЕ. Обратите внимание на то, что в качестве имени поля всегда используется то имя, которое было присвоено полю в процессе создания таблицы в режиме конструктора, а не надпись, которую мы видим на экране в таблице в режиме заполнения.

4. Запрос может быть создан также только исключительно через Режим SQL в конструкторе.

Выберем в окне базы данных «Запрос», «Создать» через опцию «Конструктор». В диалоговом окне «Добавление таблицы» выберем опцию «Закрыть». В меню Вид выберите Режим SQL. Появится окно «Запрос на выборку». Наберем следующую инструкцию SQL:

Эта инструкция предназначена для получения списков всех предметов и их кодов. Данные для этого запроса берутся из таблицы «Предмет». Результатом выполнения данного запроса будет таблица, состоящая из двух полей (Наименование предмета и Код предмета) и из всех записей таблицы «Предмет».

Результат запроса для получения списков всех предметов и их кодов

Так как в запросе используется только одна таблица, то нет необходимости указывать поле с обозначением таблицы. Очевидно, что запрос выполняется на основании таблицы «Предмет».

Рассмотрим запрос «План проведения занятий в группе», созданный на основании анализа предметной области:

SELECT Группа.[Обозначение группы], Предмет.[Наименование предмета], Преподаватель.Фамилия, Преподаватель.Имя, Преподаватель.Отчество, Преподаватель.[Табельный номер], [Учебный план].Часы, [Учебный план].[Вид занятия], [Учебный план].Семестр

FROM (Группа INNER JOIN Студент ON Группа.[Код группы] = Студент.[Код группы]) INNER JOIN (Преподаватель INNER JOIN (Предмет INNER JOIN ([Учебный план] INNER JOIN Успеваемость ON [Учебный план].[Код учебного плана] = Успеваемость.[Код учебного плана]) ON Предмет.[Код предмета] = [Учебный план].[Код предмета]) ON Преподаватель.[Код преподавателя] = [Учебный план].[Код преподавателя]) ON Студент.[Код студента] = Успеваемость.[Код студента]

GROUP BY Группа.[Обозначение группы], Предмет.[Наименование предмета], Преподаватель.Фамилия, Преподаватель.Имя, Преподаватель.Отчество, Преподаватель.[Табельный номер], [Учебный план].Часы, [Учебный план].[Вид занятия], [Учебный план].Семестр

ORDER BY Группа.[Обозначение группы], Предмет.[Наименование предмета], Преподаватель.Фамилия;

Результатом будет следующий запрос на выборку

Аналогично, следует подготовить запрос «Экзаменационная ведомость», созданный на основании анализа предметной области (см. рис. 5):

SELECT Предмет.[Наименование предмета], Группа.[Обозначение группы], Студент.[Номер зачетной книжки], Студент.Фамилия, Студент.Имя, Студент.Отчество, Успеваемость.Оценка, Успеваемость.[Дата сдачи], [Учебный план].Семестр, [Учебный план].[Вид сдачи]

FROM (Группа INNER JOIN Студент ON Группа.[Код группы] = Студент.[Код группы]) INNER JOIN (Преподаватель INNER JOIN (Предмет INNER JOIN ([Учебный план] INNER JOIN Успеваемость ON [Учебный план].[Код учебного плана] = Успеваемость.[Код учебного плана]) ON Предмет.[Код предмета] = [Учебный план].[Код предмета]) ON Преподаватель.[Код преподавателя] = [Учебный план].[Код преподавателя]) ON Студент.[Код студента] = Успеваемость.[Код студента]

WHERE ((([Учебный план].[Вид сдачи])="экзамен" Or ([Учебный план].[Вид сдачи])="Зачет"))

ORDER BY Предмет.[Наименование предмета], Группа.[Обозначение группы], Студент.Фамилия;

Рассмотрим для примера запрос «Успеваемость студентов в группах по предметам у преподавателей». Запишем текст запроса на языке SQL в окно Режим SQL:

SELECT Группа.[Обозначение группы], Студент.[Номер зачетной книжки], Студент.Фамилия, Студент.Имя, Студент.Отчество, Преподаватель.Фамилия, Преподаватель.Имя, Преподаватель.Отчество, Предмет.[Наименование предмета], Avg(Успеваемость.Оценка) AS [Avg-Оценка]

FROM (Группа INNER JOIN Студент ON Группа.[Код группы] = Студент.[Код группы]) INNER JOIN (Преподаватель INNER JOIN (Предмет INNER JOIN ([Учебный план] INNER JOIN Успеваемость ON [Учебный план].[Код учебного плана] = Успеваемость.[Код учебного плана]) ON Предмет.[Код предмета] = [Учебный план].[Код предмета]) ON Преподаватель.[Код преподавателя] = [Учебный план].[Код преподавателя]) ON Студент.[Код студента] = Успеваемость.[Код студента]

GROUP BY Группа.[Обозначение группы], Студент.[Номер зачетной книжки], Студент.Фамилия, Студент.Имя, Студент.Отчество, Преподаватель.Фамилия, Преподаватель.Имя, Преподаватель.Отчество, Предмет.[Наименование предмета]

HAVING (((Группа.[Обозначение группы])="ДФД-31"));

Результатом запроса будут сведения о средней успеваемости студентов в групп ДФД-31 у всех преподавателей во всех семестрах.

Для задания ограничений на создаваемые группы совместно с ключевым словом GROUP BY может использоваться предложение HAVING. Оно должно следовать после GROUP BY, но до предложения ORDER BY (если оно присутствует в запросе).

Сохраним запрос и просмотрим результаты этого запроса.

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

Использование форм и отчетов для создания приложений в MS Access

Формы предназначены для вывода данных на экран в удобном виде, форма может использоваться для поиска данных. Если изъять формы из MS Access, то программа превратится в заурядную СУБД, каких множество. С одной стороны, формы позволяют пользователям вводить данные в таблицы базы данных без непосредственного доступа к самим таблицам. С другой стороны, они позволяют выводить результаты работы запросов не в виде скупых результирующих таблиц, а в виде красиво оформленных форм. В связи с таким разделением существует два вида формирования структуры форм: на основе таблицы и на основе запроса, хотя возможен и комбинированный подход, - это вопрос творчества [1].