Технология разработки и защиты БД

ИНФОКОММУНИКАЦИОННЫЕ СИСТЕМЫ И СЕТИ

1. История компьютерных сетей, принципы коммутации

2. Спутниковая связь, как разновидность радиосвязи. Преимущества и недостатки.

3. Протокол IPv4. Устройство протокола, принципы работы.

4. Протокол TCP. Устройство протокола, принципы работы.

5. Сетевая эталонная модель OSI. Основные функции уровней модели OSI.

6. Технические средства линий передачи: концентратор, репитер, коммутатор.

7. Транспортный уровень модели OSI. Назначение уровня, базовые протоколы.

8. Сеть на основе витой пары.

9. Канальный и физический уровни модели OSI. Стандарты и протоколы данных уровней.

10. Сетевой уровень модели OSI. Основные принципы маршрутизации.

11. Сеть на основе коаксиального кабеля.

12. Стек протоколов TCP/IP.

13. Каналы телекоммуникаций: кабельные(на основе медной проволоки), оптоволоконные, беспроводные.

14. Базовые топологии сетей: " шина", " кольцо", " звезда". Комбинирование сетевых топологий. Стандарты Ethernet.

15. Радиосвязь, Wi-Fi, WiMax.

16. Локальные вычислительные сети. Сети промежуточной передачи. Глобальные вычислительные сети.

17. Понятие " категория витой пары", различия, принципы передачи информации по " витой паре".

18. Таблица маршрутизации, понятие шлюз, маска. Принцип расчета адресации сети.

19. Протокол UDP. Устройство протокола, принципы работы.

20. Изменение типа данных при переходе по уровням модели OSI. Инкапсуляция.

21. Коммутация в стандартах Ethernet, протокол ARP. Принципиальное различие коммутатора и концентратора.

22. Протокол DNS. Устройство протокола, принципы работы.

ТЕХНОЛОГИЯ РАЗРАБОТКИ И ЗАЩИТЫ БД

1. Информация и данные предметных областей.

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

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

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

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

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

Рис. 1. Классификации объектов предметной области

1. ER-модель БД. Формирование связей сущностей. Бинарные отношения сущностей.

Работа с базой данных начинается с построения модели. Наиболее распространенной является ER-модель (entity-relationship model) - модель " Сущность-связь".
Для " ручного" построения ER-модели на практике будем использовать простую систему обозначений, предложенную Питером Ченом (обозначения, встречающиеся в разных источниках, могут отличаться от нижеприведенных):

Базовые понятия

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

Объект и его атрибуты соединяются ненаправленными дугами.

Связи между объектами могут быть 3-х типов:
Один - к одному. Этот тип связи означает, что каждому объекту первого вида соответствует не более одного объекта второго вида, и наоборот. Например: сотрудник может руководить только одним отделом, и у каждого отдела есть только один руководитель.

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

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

Ромб связи и прямоугольник объекта соединяются ненаправленными дугами в сторону " ко многим" и направленными в сторону " к одному".

Связь может соединять сущность саму с собой, например:

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

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

На схеме слабые сущности обозначаются двойными линиями.

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

Сущность " Контрагент" является надтипом для своих подтипов.

1. Организация систем БД. Средства поддержки БД.

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

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

Схемы и подсхемы базы данных часто изображают в виде диаграмм.

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

Средства поддержки БД – набор утилит, предназначенных для поддержки БД в процессе ее эксплуатации (тестирование структуры БД, миграция и конвертирование данных, резервное копирование и восстановление данных).

1. Свойства реляционных таблиц. Назначение первичных и вторичных ключей реляционных таблиц.

Любую структуру данных можно представить в виде простой двумерной таблицы. Базы данных, составленные из двумерных таблиц, называются реляционными.
Достоинства: простота и доступность; независимость данных; гибкость.
Реляционная модель позволяет:
- определить структуру данных;
- определить операции по поиску и запоминанию данных;
- определить ограничения, связанные с обеспечением целостности данных.
Реляционная база данных обладает следующими свойствами:
1. Реляционная таблица двумерна;
2. Каждый элемент таблицы – один элемент данных;
3. Все элементы в столбце таблицы имеют одинаковый тип и длину;
4. Каждый столбец имеет уникальное имя;
5. Одинаковые строки в таблице отсутствуют;
6. Порядок следования строк и столбцов – произвольный.
Структурные элементы:
1) Таблица – это совокупность данных, характеризующих объект. Состоит из фиксированного числа столбцов и переменного числа строк.
2) Запись – строка таблицы. Система сама нумерует записи.
3) Макет – описание столбцов в таблице.
4) Поле – столбец таблицы.

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

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

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

Пример.

Рассмотрим БД " Адреса клиентов", приведенную на Рис. 0.1.Здесь можно выделить два ключа-кандидата:

а) ШифрКлиента; б) ФИО + Адрес.

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

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

Пример.

Рассмотрим БД Сотрудники, имеющую структуру:

Сотрудники(№Таб, ФИО, ПаспортныеДанные, Должность).

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

1. Функциональные и многозначные зависимости. Операторы реляционной алгебры.

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

Аксиома транзитивности

Введем обозначения: X, Y, Z — атрибуты (А); R - отношение; QА - множество атрибутов отношения R; QF - множество функциональных зависимостей из R.

Аксиома.

Если атрибуты X, Y и Z принадлежат множеству QA и заданы зависимости

F1: X ® Y, F2: Y ® Z, которые принадлежат множеству функциональных зависимостей QF либо получены из него на основе правил вывода, то имеет место функциональная зависимость X ® Z или (x ® y) & (y ® z) x ® z.

Пример.

В отношении

Служащие(ФИО, ЗПлата, Задание Задание, ВремяВыполнения)

атрибут ВремяВыполнения зависит от атрибута Задание, который в свою очередь зависит от атрибута ФИО. Следовательно, атрибут Время Выполнения транзитивно зависит от атрибута ФИО.

Это можно представить схемой:

Функциональные зависимости

В отношении R атрибут типа Y функционально зависит от атрибута типа Х, если каждому значению атрибута X соответствует единственное значение атрибута типа Y. Синтаксис X ® Y (X влечет Y).

Многозначные зависимости

В отношении R имеет место многозначная зависимость, если при заданном значении атрибута типа X существует множество взаимосвязанных значений атрибута типа Y.

Для обозначения многозначной зависимости обычно используется символика: X ® ® Y.

Пример.

В отношении

Поставки (Завод, Изделие, Цена)

между атрибутами типов Завод и Изделие имеет место многозначная зависимость, т.к. одному значению атрибута типа Завод соответствует множество значений атрибута типа Изделие: Завод ® ® Изделие

В соответствии с лингвистическим обеспечением, используемым пользователями при работе с БД, предусмотрено три уровня манипулирования данными:

· низший уровень - это уровень, при котором пользователь БД оперирует непосредственно с записями;

· средний уровень, основанный на использовании реляционной алгебры. Пользователь для манипулирования данными использует наборы высокоуровневых операций над отношениями;

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

Операции над отношениями

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

Для реализации операций над отношениями Коддом было предложено три абстрактных теоретических языка:

· реляционная алгебра;

· реляционное исчисление с переменными - кортежами;

· реляционное исчисление с переменными - доменами.

Эти языки по своей выразительности эквивалентны.

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

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

Современные языки манипулирования данными SEQUEL (SQL), QBE, ISBL и др., используемые в СУБД, реализуют широкий набор операций:

· операции с данными: включение, модификация, удаление данных;

· операции обработки данных:

· арифметические выражения (вычисления, сравнения);

· команды присваивания и печати;

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

Агрегатными функциями называются функции, применяемые к доменам отношений для вычисления единственной величины.

1. Нормальные формы

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

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

1) первая нормальная форма (1 NF);

2) вторая нормальная форма (2 NF);

3) третья нормальная форма (3 NF);

4) нормальная форма Бойса – Кодда (BCNF);

Основные свойства нормальных форм состоят в следующем:

1) каждая следующая нормальная форма в некотором смысле лучше предыдущей нормальной формы;

2) при переходе к следующей нормальной форме свойства предыдущих нормальных форм сохраняются.

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

Первая нормальная форма (1NF)

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

Пример не 1NF таблицы:

В этом примере в одной из ячеек содержится список из двух элементов: Война и Мир, Азбука, т.е. он является не атомарным.

Исправить можно так:

Вот, теперь это таблица в первой нормальной форме.

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

Вторая нормальная форма (2NF)

Основные критерии: Таблица должна находиться в первой нормальной форме. Любое её поле, не входящее в состав первичного ключа, функционально полно зависит от первичного ключа. Сразу скажу, что если Ваша таблица приведена к первой нормальной форме и у нее установлен уникальный id для каждой строки, то она находится и во второй нормальной форме. Значение второго правила можно понять на примере, когда первичный ключ таблицы состоит из нескольких полей. То есть каждой строке соответствует уникальный набор из нескольких значение полей таблицы.

Например. Эта таблица находится в первой нормальной форме, но не во второй.

В этой таблице первичный ключ составляют первые два столбца (Категория и Дата).

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

Исправляется это разделением этой таблицы на две другие:

Вот и все. Теперь эти таблицы находятся во второй нормальной форме.

Методы приведения к 2NF: Создайте отдельные таблицы для наборов значений, относящихся к нескольким записям (Выше мы это сделали). Свяжите эти таблицы с помощью внешнего ключа (В нашем случае – это поле Категория).

Третья нормальная форма (3NF)

Основные критерии: Таблица находится во второй нормальной форме.

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

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

Благодаря этому правилу, при удалении какого-то государства, имена шпионов не будут утеряны

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

Методы приведения к 3NF: Удаление полей не зависящих от ключа

Нормальная форма Бойса-Кодда (BCNF)

Эта форма почти то же самое, что и третья. С одним небольшим дополнительным условием.

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

Методы приведения к BCNF: Вынести в отдельную таблицу потенциальные первичные ключи

1. Поддержка целостности данных

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

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

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

Замечания к правилам целостности сущностей и внешних ключей

На самом деле приведенные правила целостности сущностей и внешних ключей прямо следуют из определений понятий " потенциальный ключ" и " внешний ключ".

В определении потенциального ключа требуется, чтобы потенциальный ключ обладал свойством уникальности. Это фактически означает, что мы должны уметь различать значения потенциальных ключей, т.е. при сравнении двух значений потенциального ключа мы всегда должны получать значения либо ИСТИНА, либо ЛОЖЬ. Но любое сравнение, в которое входит null-значение, принимает значение U - НЕИЗВЕСТНО, откуда следует, что атрибуты потенциального ключа не могут содержать null-значений.

Для внешних ключей правило целостности фактически входит в определение

Операции, которые могут нарушить ссылочную целостность

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

Для родительского отношения

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

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

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

Для дочернего отношения

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

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

Удаление кортежа в дочернем отношении. При удалении кортежа в дочернем отношении ссылочная целостность не нарушается.

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

· Обновление кортежа в родительском отношении.

· Удаление кортежа в родительском отношении.

· Вставка кортежа в дочернее отношение.

· Обновление кортежа в дочернем отношении.

Существуют две основные стратегии поддержания ссылочной целостности.

RESTRICT (ОГРАНИЧИТЬ) – не разрешать выполнение операции, приводящей к нарушению ссылочной целостности. Это самая простая стратегия, требующая только проверки, имеются ли кортежи в дочернем отношении, связанные с некоторым кортежем в родительском отношении.

CASCADE (КАСКАДИРОВАТЬ) – разрешить выполнение требуемой операции, но внести при этом необходимые поправки в других отношениях так, чтобы не допустить нарушения ссылочной целостности и сохранить все имеющиеся связи. Изменение начинается в родительском отношении и каскадно выполняется в дочернем отношении.

1. Функции и состав универсальной СУБД.

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

Ниже перечислены основные функции СУБД.

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

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

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

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

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

Язык манипулирования данными (или язык запросов) представляет собой систему команд, например, следующего типа:

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

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

• найти в базе позицию данного и поместить туда новое значение (или удалить данное) и т.д.

Широкое распространение имеют СУБД для персональных компьютеров типа DBASE (DBASE III, IV, FoxPro, Paradox), Clipper, Clarion. Эти СУБД ориентированы на однопользовательский режим работы с базой данных и имеют очень ограниченные возможности. Языки подобных СУБД представляют собой сочетание команд выборки, организации диалога, генерации отчетов. В связи с развитием компьютерных сетей, в которых персональные компьютеры выступают в качестве развитых (интеллектуальных) терминалов, новые версии СУБД все в большей степени включают в себя возможности описанного ниже языка манипулирования данными SQL. В последнее время стали среди СУБД популярными ACCESS (входит в состав MS Office), Lotus, Oracle.

1. Лингвистическое обеспечение СУБД.

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

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

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

Лингвистическое обеспечение должно обеспечивать:

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

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

· наличие «горячих» клавиш, меню, кнопок;

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

· возможность сохранения однажды сделанных настроек;

· минимизацию трудовых и временных затрат на освоение;

· полную локализацию;

· унифицированность;

· онлайновые подсказки.

в) формирование запросов с АРМ и запуск информационных и иных задач;
г) защиту от ошибок и некорректных действий пользователей.

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

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

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

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

Концептуальная модель описывает хранимые в ЭВМ данные и связи. В силу этого каждая модель данных неразрывно связана с языком описания данных конкретной СУБД.

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

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

Типы структур данных

Среди широкого множества определений, обозначающих типы структур данных, наиболее распространена терминология CODASYL (Conference of DAta SYstems Language) — международной ассоциации по языкам систем обработки данных, созданной в 1959 г.

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

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

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

· БД может содержать любое количество типов записей и типов наборов;

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

· тип записи может быть владельцем и одновременно членом нескольких типов наборов.

Операции над данными

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

· найти следующее данное (запись);

· найти предыдущее данное;

· найти энное данное;

· найти первое (последнее) данное.

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

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

^ ВОЕННО-УЧЕТНАЯ СПЕЦИАЛЬНОСТЬ = 200100; ВОЗРАСТ > 20; ДАТА < 19.04.2002 и т.п.

Булево условие отбора формируется путем объединения простых условий с применением логических операций, например: (ДАТА_РОЖДЕНИЯ < 28.12.1963) И (СТАЖ > 10); (УЧЕНОЕ_ЗВАНИЕ = ДОЦЕНТ) ИЛИ (УЧЕНОЕ ЗВАНИЕ = ПРОФЕССОР) и т.п.

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

1. Общая характеристика СУБД MS Access.

Система управления базами данных Microsoft Access является одним из самых популярных приложений в семействе настольных СУБД. Все версии Access имеют в своем арсенале средства, значительно упрощающие ввод и обработку данных, поиск данных и предоставление информации в виде таблиц, графиков и отчетов. Начиная с версии Access 2000, появились также Web-страницы доступа к данным, которые пользователь может просматривать с помощью программы Internet Explorer. Помимо этого, Access позволяет использовать электронные таблицы и таблицы из других настольных и серверных баз данных для хранения информации, необходимой приложению. Присоединив внешние таблицы, пользователь Access будет работать с базами данных в этих таблицах так, как если бы это были таблицы Access. При этом и другие пользователи могут продолжать работать с этими данными в той среде, в которой они были созданы.

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

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

1. Основные этапы разработки базы данных в среде MS Access.

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

1. разработка и описание структур таблиц данных

2. разработка схемы данных и задание системы взаимосвязей между таблицам

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

4. разработка экранных форм ввода/вывода данных

5. разработка системы отчетов по данным

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

7. разработка системы защиты данных, прав и ограничений по доступу

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

1. Создание таблиц и схем данных в среде MS Access.

Процесс разработки базы данных в СУБД MS Access начинается с задания описания структур таблиц. Рассмотрим этот процесс более подробно для таблиц примера, описанного в 2.3.

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

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

Рис. 5. Создание описания структуры таблицы Бумаги

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

Выбор типа данных в Access одновременно определяет набор дополнительных атрибутов соответствующего поля. В частности, поле ДатаЭм (дата эмиссии) имеет тип Дата и, как это показано на рис. 5, может иметь дополнительные атрибуты:

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

- содержит расширенный заголовок;

- значение по умолчанию - позволяет указать значение, автоматически присваиваемое полю при создании новой записи. В нашем случае по умолчанию будет задаваться текущая дата, возвращаемая встроенной функцией Date();

- условие на значение - определяет требования к данным, вводимым в поле. Например, для выполнения требования, чтобы дата эмиссии предшествовала текущей, следует задать выражение < =Date();

- сообщение об ошибке - определяет текст сообщения, которое будет выводиться в случае нарушения заданного выше условия;

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

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

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

Рис. 6. Панель инструментов конструктора таблиц

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

Рис. 7. Создание индексов для таблицы

Рис. 8. Задание списка подстановки для поля

Эффективным методом решения задач контроля корректности входных данных является ограничение множества допустимых значений поля некоторым списком. Рассмотрим это более подробно на примере поля ТипБум (тип бумаги), которая, допустим, в рассматриваемой торговой системе может быть либо акцией, либо облигацией. Нетрудно заметить, что будет разумным присвоить типу Акция код 1, а типу Облигация - код 2. Это позволит существенно сэкономить место за счет уменьшения объема хранимой информации (особенно при большом количестве записей). Однако с точки зрения восприятия вводимой информации пользователем гораздо удобнее иметь дело с осмысленным текстом, чем запоминать, какие коды ему соответствуют.
Средством решения этой проблемы в Access является задание подстановочного списка значений для поля. Для этого следует выбрать вкладку Подстановка в окне Свойства поля, далее для свойства Тип элемента управления задать значение Список. На рис. 8 показано, как описать другие свойства элемента управления Список, чтобы организовать заполнение поля ТипБум требуемыми значениями.
После создания описания структуры таблицы можно перейти в режим непосредственного ввода в нее данных. Как уже говорилось, важным преимуществом интерфейса СУБД Access является продуманная гибкая система перехода от режима Конструктора к режиму ввода данных в таблицу (Режим таблицы). Такой переход можно осуществить, щелкнув мышью по пиктограмме Вид, расположенной на панели инструментов, либо выбрав функцию меню Вид > Режим таблицы.
На рис. 9 показано окно режима непосредственного ввода данных в таблицу Бумаги,

Рис. 9. Ввод данных в таблицу Бумаги

Хочется еще раз обратить внимание читателя на то, что выбор типа бумаги осуществляется из заранее предопределенного списка.

Очевидно, что те действия, которые были подробно описаны для таблицы Бумаги, следует проделать и для остальных информационных массивов: Агенты, Портфели, Заявки. В результате мы получим систему таблиц базы данных TfadeTest. Подчеркнем, именно систему, так как находящиеся в них данные тесно и содержательно связаны между собой. Действительно, данные, находящиеся в поле Код агента таблицы Портфели, должны быть согласованы по типу и размеру с данными, находящимися в одноименном поле таблицы Бумаги. Более того, логика рассматриваемой задачи требует, чтобы, работая с информацией, относящейся к портфелю, мы могли одновременно обратиться к данным, характеризующим текущего агента, и т. д.
Механизм описания логических связей между таблицами в Access реализован в виде объекта, называемого Схемой данных. Перейти к ее созданию можно из панели инструментов База данных, доступной из главного окна. Альтернативный вариант вызова данного режима доступен через меню Сервис > Схема данных. Вид, который будет иметь схема данных для построенных на предыдущих шагах таблиц, представлен на рис. 10.

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

Интерфейс задания связей между полями в схеме основан на " перетаскивании" (перемещении при нажатой левой кнопки мыши) выбранного поля и " наложении" его на то поле, с которым должна быть установлена связь. Для связывания сразу нескольких полей их следует перемещать при нажатой клавише Ctrl. Выделяют несколько типов связей между таблицами в схеме. " Один к одному" (1: 1) - одному значению поля в одной таблице соответствует только одно значение поля в другой. " Один ко многим" (1:?) - одному значению поля в одной таблице соответствует несколько (одно или более) значений в другой.
Важнейшей задачей, которую позволяет решать схема, является обеспечение логической целостности данных в базе. Так, в базе данных TradeTest нарушение целостности может возникнуть в случае удаления из таблицы Бумаги записей по тем бумагам, о которых существуют записи в таблицах Портфели или Заявки, в результате чего в их составе окажутся ссылки на " потерянные" коды. Очевидно, что это можно предотвратить, если каскадно удалить как записи из таблицы Бумаги, так и записи из связанных с ней таблиц. Такой эффект в Access может быть достигнут за счет задания определенных свойств для связи. Чтобы это сделать, необходимо щелкнуть кнопкой мыши, находясь на линии схемы, обозначающей связь. После этого появляется диалоговое окно, предназначенное для изменения свойств связи. Как видно из рис. 11, в рамках режима обеспечения целостности данных можно по выбранной связи задать как каскадное обновление значений для связанных полей, так и каскадное удаление связанных записей.

Рис. 11. Задание свойств связи

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

- поиск записи по условию (см. функцию меню Правка > Найти);

- сортировка записей в требуемом порядке (см. функцию меню Записи > Сортировка);

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

Рис. 12. Контекстное меню работы с данными в таблице

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

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

- Наименование агента;

- Тип бумаги;

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

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

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

- задание порядка, в котором данные должны выводиться при выполнении запроса;

- задание условий вывода записей в запросе.

На рис. 13 показано окно конструктора запроса.

Рис. 13. Окно конструктора запроса

Отметим, что колонки таблицы запроса на рис. 13 содержа? как поля таблиц, так и выражения, построенные на основе полей. В частности, последняя колонка (ей присвоено имя НоминСтоим) содержит выражение [Номинал]*[СуммОбъем], при этом записи будут выводиться отсортированными по типу бумаг.

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

Рис. 14. Вывод данных по запросу СтруктураПортфелей

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

Рис. 15. Создание запроса с групповыми операциями

На рис. 15 показано окно конструктора в процессе создания запроса, выводящего информацию по суммарному спросу и предложению на ценные бумаги. Операция свертки нескольких записей из таблицы Заявки в одну результирующую запись, осуществляемая для каждого наименования бумаги, определяется командой Группировка, расположенной в строке Групповая операция. Для двух последующих колонок запроса (СуммСпрос и СуммПредл) определены операции суммирования по группе (Sum), расположенные в той же строке, а в строке Поле находятся производные выражения, суммы которых мы хотим получить в запросе. В соответствии с ранее принятыми соглашениями объем суммарного спроса определяется совокупностью всех записей по данной бумаге, имеющих положительное значение в поле ОбъемЗаявки, а объем суммарного предложения - записями, содержащими в данном поле отрицательную величину. Таким образом, для вычисления СуммСпрос необходимо просуммировать If[0бъем3аявки]> =0; [Цена3аявки]*[0бъем3аявки]; 0), а для вычисления СуммПредл - If[ОбъемЗаявки]< =0; -1* [Цена3аявки]*[0бъем3аявки]; 0).

ПРИМЕЧАНИЕ
Встроенная функция lf(bArg; Arg1; Arg2) возвращает значение аргумента Arg1, если значение аргумента bArg, который может содержать только логическую величину, является истинным (bArg = ИСТИНА), и значение Агд2, если bArg = ЛОЖЬ.

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

- задание параметров, запрашиваемых при открытии запроса;

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

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

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

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