Получение таблицы, содержащей консолидированные данные

	A	B	C	D	E
	Объем продаж филиалами в 1999 г.
	Название	Объем продаж по кварталам, тыс.руб.
	I	II	III	IV
	Филиал 1
	Компьютеры
	Мониторы
	Процессоры
	Материнские платы
	Филиал 2
	Компьютеры
	Мониторы
	Процессоры
	Материнские платы
	Филиал 3
	Компьютеры
	Мониторы
	Процессоры
	Материнские платы
	Филиалы 1 - 3 (всего по фирме)
	Компьютеры
	Мониторы
	Процессоры
	Материнские платы

 

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

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

 

 

Таблица 8.5

Исходные данные для построения сводной таблицы

 

	A	B	C	D	E	F
	Объем продаж филиалами по кварталам 1999 г.
	Филиал	Название	I	II	III	IV
	Филиал 1	Компьютеры
	Филиал 1	Мониторы
	Филиал 1	Процессоры
	Филиал 1	Материнские платы
	Филиал 2	Компьютеры
	Филиал 2	Мониторы
	Филиал 2	Процессоры
	Филиал 2	Материнские платы
	Филиал 3	Компьютеры
	Филиал 3	Мониторы
	Филиал 3	Процессоры
	Филиал 3	Материнские платы

 

 

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

1) вызвать мастер сводных таблиц с помощью пункта меню Данные/Сводная таблица, указать источник данных (в списке или базе данных), нажать кнопку Далее;

2) указать диапазон, в котором находятся исходные данные (в нашем примере A3:F15); если ячейки выделены заранее, то программа определит диапазон по выделению; нажать кнопку Далее;

3) создать макет сводной таблицы, используя известные поля; в нашем примере надо переместить мышью кнопку поля Филиал в область Страница (Рис. 8.9), кнопку поля Наименование – в область Строка, а кнопки I, II, III, IV – в область Данные; нажать кнопку Далее;

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

 

 

 

 

Рис. 8.9. Создание макета сводной таблицы

 

Сводная таблица, созданная для нашего примера (Таблица 8.6), в первой строке содержит поле со списком. Если список раскрыть, то из него можно выбрать конкретный филиал или все (филиалы) – в зависимости от выбора изменяется содержимое столбца Всего.

Таблица 8.6

Пример сводной таблицы

Филиал	(Все)
Название	Данные	Всего
Компьютеры	Сумма по полю I
	Сумма по полю II
	Сумма по полю III
	Сумма по полю IV
Материнские платы	Сумма по полю I
	Сумма по полю II
	Сумма по полю III
	Сумма по полю IV
Мониторы	Сумма по полю I
	Сумма по полю II
	Сумма по полю III
	Сумма по полю IV
Процессоры	Сумма по полю I
	Сумма по полю II
	Сумма по полю III
	Сумма по полю IV
Итог Сумма по полю I
Итог Сумма по полю II
Итог Сумма по полю III
Итог Сумма по полю IV

На этом завершим рассмотрение табличного процессора Excel. Как и при описании текстового процессора Word (см. раздел 7), мы не ставили перед собой задачу проиллюстрировать абсолютно все возможности данного приложения. Для более полного знакомства с Excel мы рекомендуем проделать лабораторные и контрольные работы, приведенные в [ 6 ], а также познакомиться с расширенными возможностями Excel [1,2].

Кроме консолидации данных и построения сводных таблиц, Excel предоставляет и другие возможности, позволяющие работать с электронными таблицами как с базой данных. При желании эти возможности можно изучить самостоятельно, пользуясь литературой [1,2] и встроенной справкой. Но еще лучше воспользоваться более мощными средствами, имеющимися в системах управления базами данных (СУБД), которым посвящен следующий раздел.

 

 

Контрольные вопросы к разделу 8: назначение Excel; основные понятия: электронная таблица, ячейка таблицы, адрес ячейки, ссылка, блок ячеек, текущая (активная) ячейка, рабочая книга; как скопировать, переместить или переименовать лист рабочей книги; как изменять высоту строк, ширину столбцов, как удалять и вставлять строки и столбцы; как выделить ячейку, строку, столбец, блок ячеек; установка формата выделенных ячеек – вкладки Число, Выравнивание, Шрифт, Граница, Вид; копирование формата ячеек; кнопки панели инструментов Форматирование, их применение; выполнение расчетов по формулам: ввод формулы, операторы и функции, используемые в Excel, применение относительной и абсолютной адресации; автозаполнение; построение диаграмм: ряды и категории данных, этапы построения диаграммы, форматирование элементов диаграммы; сортировка, консолидация данных, сводные таблицы.

 

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

 

9.1. Основные понятия

База данных – это совокупность структурированных данных, относящихся к некоторой предметной области.

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

Структурирование – это введение соглашений о способах представления данных. Это понятие близко к понятиям модель данных и формализация данных. В разделе 3 мы уже рассматривали понятие модели объекта – это формализованное описание существенных свойств объекта ограниченным набором параметров. Структуры данных - тоже объекты. Так, в реляционных базах данных, рассматриваемых далее, используются три структуры данных: таблица, запись, поле. И каждая из этих структур имеет свои свойства, описываемые параметрами. Таблица имеет имя и состоит из записей. Запись имеет номер в таблице и состоит из полей. У каждого поля есть имя, тип (текстовый, числовой и т.п.), длина в байтах. Поясним эти структуры на примере построения информационной модели конкретной предметной области.

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

 

Объекты [ Код об, Объект],

Работы [ Код раб, Работа],

Организации [ Код орг, Организация, Индекс, Город, Адрес, Телефон, Факс, Эл почта]

и собственно таблицу для учета затрат

Затраты [ Код затр, Затрата, Код об, Код раб, Код орг, Дата, Стоимость].

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

Ключевые поля служат также для связывания таблиц. Например, таблица Затраты может содержать множество записей, в которых указан код одной и той же организации-подрядчика. Предположим, одна и та же организация проектировала и строила мост, подъездную дорогу, трансформаторную подстанцию и, возможно, другие объекты. При обработке записей таблицы Затраты может потребоваться факс этой организации – его легко найти в таблице Организации, которая должна содержать единственную запись с требуемым нам кодом организации в поле Код орг. Связь между этими таблицами называется связью «один ко многим» (1 ® ¥): ссылка на одну запись в таблице Организации содержится во многих записях таблицы Затраты. Если бы мы ввели еще одну таблицу – Банковские реквизиты, в которой для каждой организации-подрядчика указали бы ее код, название банка, номера счетов и другие данные, используемые при оформлении платежей, то связь между этой таблицей и таблицей Организации была бы связью «один к одному» (1 ® 1), т.к. в этих таблицах есть только по одной записи с одним и тем же значением ключевого поля Код орг. В некоторых ситуациях ключ может состоять из двух-трех полей и тогда он называется составным. Например, подразделение может идентифицироваться номером цеха и номером бригады в данном цехе, точка геофизических измерений может идентифицироваться номером профиля и номером точки на этом профиле и т.п.

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

Итак, в нашем примере база данных охватывает несколько взаимосвязанных таблиц «объекты-свойства». Такие базы данных называются реляционными. Это понятие (relation – отношение) было введено известным американским специалистом в области систем управления базами данных И.Ф.Коддом. В 1994 г. отмечалась 25 годовщина с того момента, как И.Ф.Кодд (тогда научный сотрудник корпорации IBM) предложил реляционную модель. Тем не менее первая коммерческая реляционная СУБД, названная Oracle [14], появилась только в 1979 г. Она была разработана небольшой компанией Silicon Valley. Сегодня это Oracle Corporation – крупнейший в мире поставщик реляционных СУБД и сопутствующих программных продуктов. Первой СУБД клиент/сервер стал выпущенный в 1985 г. Oracle 5. В настоящее время широкое распространение получили более поздние реляционные СУБД, созданные корпорациями Oracle, Sybase, Microsoft и некоторыми другими. Современные ведущие реляционные СУБД сочетают реляционную модель данных с технологией клиент/сервер и с объектно-ориентированным подходом к созданию программных средств. На ЭВМ третьего поколения имели место многочисленные попытки применения иерархических и сетевых СУБД. Они оказались слишком сложными для восприятия пользователями и, кроме того, в них были ограничены или полностью отсутствовали возможности динамического изменения структуры баз данных. Последнее ограничение в некоторой степени присуще и реляционным СУБД, но все-таки с помощью языка SQL (см. подраздел 9.4) и другими методами здесь не так уж трудно изменить состав записей в таблице или создать новую таблицу и связать ее с имеющимися в рамках действующей СУБД.

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

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

 

9.2. Нормализация отношений (таблиц) и обеспечение целостности данных в реляционной базе данных

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

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

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

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

Понятие третьей нормальной формы основывается на понятии нетранзитивной зависимости [4]. Транзитивная зависимость наблюдается, если один из атрибутов зависит от ключа, а другой – от этого атрибута. Например, если в таблицу Затраты включить не только код организации, но и город, в котором она расположена, то получится, что атрибут Код орг функционально зависит от ключа Код затр, а атрибут Город зависит, в свою очередь, от атрибута Код орг и, следовательно, транзитивно зависит от ключа.

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

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

Дальнейшее изложение ориентировано на изучение возможностей СУБД Access, но прежде приведем схему [4] обобщенной технологии работы с СУБД (Рис. 9.1).

 

9.3. Работа с СУБД Access

Работу с СУБД Access рассмотрим на уже упоминавшемся примере учета затрат предприятия. Последовательность действий в основном будет соответствовать приведенной схеме (см. рис. 9.1).

Сначала создадим пустую базу данных “Затраты”, а затем – пустые таблицы этой БД, т.е. структуру таблиц. Для этого откроем приложение Access, выберем пункт меню Файл/Создать, в открывшемся диалоговом окне подтвердим желание создать новую БД нажатием кнопки Ok. После этого откроется стандартное диалоговое окно Сохранить как (см. подраздел 2.3). В нем надо выбрать каталог для размещения новой базы данных и дать имя файлу, например, Затраты.mdb. Этот файл будет содержать описание структуры таблиц, сами таблицы, формы, запросы и отчеты, которые будут созданы в соответствии с нашей технологической схемой (см. рис. 9.1). На рис. 9.2 показано окно приложения Access. В этом окне после создания пустой базы данных “Затраты” появится окно базы данных с заголовком “Затраты: база данных”, только в этом окне еще не будет перечня таблиц и, конечно, в окне приложения Access еще не будут открыты окна таблиц для просмотра и корректировки наших четырех таблиц. На рисунке эти таблицы показаны заранее, чтобы читатель яснее представлял то, что еще предстоит создать.

 

Рис. 9.1. Схема обобщенной технологии работы с СУБД

 

Теперь, когда пустая база данных существует, создадим пустые таблицы, т.е. пока только определим их структуру – опишем каждое поле записи. Начинать надо со вспомогательных таблиц Объекты, Работы и Организации. Для создания таблицы Объекты в окне базы данных (Затраты: база данных)нажмем кнопку Таблицы (вверху), а затем кнопку Создать (справа). В открывшемся диалоговом окне выберем из списка Конструктор. После этого откроется диалоговое окно Объекты: таблица – на рис. 9.3 оно показано справа. В этом окне в графе Имя поля введем Код об, а в поле со списком (см. подраздел 2.2) Тип данных выберем Числовой. После этого в поле со списком Размер поля выберем Длинное целое. Затем, нажав на панели инструментов кнопку с изображением ключа, сделаем поле Код об ключевым. Теперь определим второе поле – поле Объект. В графу Имя поля введем его название, а в поле со списком Тип данных выберем Текстовый. Длина текстового поля по умолчанию равна 50 байтам, и это нас устраивает. После этого окно, в котором мы определяли поля таблицы Объекты, можно закрыть с помощью кнопки системного меню (в строке заголовка окна, справа). При закрытии этого окна появится диалоговое окно, в котором надо задать имя таблицы – “Объекты”. Теперь таблица создана, ее можно открыть с помощью кнопки Открыть в окне базы данных и ввести в нее записи (см. рис. 9.2). Для ввода данных надо “встать” в нужное поле с помощью щелчка мыши или с помощью клавиш перемещения курсора и вводить данные в это поле. После ввода значения нажимают клавишу <Enter> - этим завершается ввод данных в ячейку таблицы, и курсор перемещается в следующее поле записи или в первое поле очередной записи. Для перемещения курсора также можно пользоваться клавишами <Tab> и <Shift>+<Tab>. Кроме того, перемещаться по записям таблицы помогает навигатор – линейка с кнопками внизу каждой таб
лицы (см. рис. 9.2).

Рис. 9.2. Рабочее окно СУБД Access с открытыми таблицами БД «Затраты»

 

Таблицы Работы и Организации создаются точно так же, как таблица Объекты, только в таблице Организации больше полей. А вот создание таблицы Затраты (см. окно Затраты: таблица на рис. 9.3) требует дополнительных пояснений по поводу определения полей Код об, Код раб, Код орг. Каждое из этих полей лучше определить как поле со списком. На рис. 9.3 показано, как это сделано для поля Код орг. После определения типа этого поля (числовой) и уточнения его общих параметров (длинное целое) с помощью вкладки Общие, переходим на вкладку Подстановка – она показана на рисунке слева, внизу. Здесь в полях со списком выбираем тип элемента управления (поле со списком), тип источника строк (таблица/запрос), источник строк (таблица Организации), присоединенный столбец (первый) и число столбцов в списке (2). Полезно указать также ширину столбцов и списка, например, 1; 6 см – столбцы, 7 см – весь список. Теперь при вводе данных в поле Код орг (прямо в таблицу Затраты или с помощью формы - рис. 9.4) можно не вспоминать коды организаций, а выбирать их из списка, в строках которого содержатся и коды и названия – ведь мы включили в список поля Код орг таблицы Затраты два столбца из таблицы Организации, причем полю Код орг таблицы Затраты соответствует именно первый (присоединенный) столбец таблицы Организации. Для того чтобы список появился, надо просто щелкнуть мышью по стрелке у правого края поля Код орг. Таким образом, Access предоставляет удобные средства для ввода и корректировки данных. Но еще удобнее для ввода данных в таблицу с большим числом полей использовать форму (см. форму Затраты на рис. 9.4).

Рис. 9.3. Создание таблиц Объекты и Затраты: определение имен и типов полей

 

 

Схема данных

Рис. 9.4. Использование формы для ввода и корректировки данных. Формирование или корректировка запроса в режиме конструктора

 

На рисунке форма Затраты изображена справа, вверху. Если в таблице мы видим сразу много записей, то в форме видны поля только одной записи, но зато сразу видны все поля – даже если запись очень длинная. Кроме того, при желании в форму Затраты можно включить поля не только из таблицы Затраты, но и из других таблиц, если, например, мы хотим видеть в форме не только коды (объекта, вида работ, организации), но и соответствующие названия. Правда, для этого надо перед созданием формы создать схему данных. Для этого можно воспользоваться пунктом меню Сервис/Схема данных или соответствующей кнопкой на панели инструментов. В появившемся диалоговом окне надо выбрать таблицы, включаемые в схему. После этого появится схематическое изображение таблиц в виде прямоугольников, содержащих список полей (см. рис. 9.4). После этого остается с помощью мыши соединить поля Код об, Код раб, Код орг таблицы Затраты с ключевыми полями других таблиц – на схеме появятся стрелки с указанием типа связи (см. подраздел 9.2). Если по стрелке щелкнуть правой клавишей мыши, то всплывет меню, позволяющее изменить свойства связи: например, можно, выбрав метод Изменить связь, установить в очередном диалоговом окне флажок Обеспечение целостности данных (см. подраздел 9.2). На рис. 9.4 схема данных изображена не в момент ее создания, а при создании запроса – схема данных используется всегда, когда данные берутся из нескольких связанных таблиц. Но вернемся к созданию формы.

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

Запросы создаются с целью отбора данных из таблиц по некоторым критериям. Например, создадим запрос Квартал2, содержащий данные о затратах за второй квартал 1998 г. Чтобы создать запрос, в окне базы данных нажмем кнопку Запросы (вверху), а затем кнопку Создать (справа). В следующем диалоговом окне выберем таблицы, из которых собираемся отбирать данные, и получим окно, изображенное на рис. 9.4, внизу. В этом окне в полях со списками Имя таблицы и Поле надо выбрать поля, включаемые в запрос, ниже можно выбрать вариант сортировки записей и указать условия их отбора. Закрыв окно, можно запомнить созданный запрос. При его просмотре мы видим виртуальную таблицу (представление [14]), включающую только те данные, которые мы отобрали. Если изменить данные в исходных таблицах, то результат просмотра запроса также изменится.

Результаты запроса удобно использовать в качестве источника информации для составления отчета. На рис. 9.5 показан отчет Апрель-июнь, в который включены данные из запроса Квартал2. Отчет получен с помощью мастера отчетов. В окне базы данных надо нажать кнопку Отчеты (вверху), а затем кнопку Создать (справа), далее выбрать Мастер отчетов и запрос Квартал2 - в качестве источника данных. После этого, делая выбор в предлагаемых диалогах, остается уточнить перечень полей, включаемых в отчет, вариант группировки и сортировки записей, вариант вывода итоговых строк и ориентацию страниц. Отчет в сочетании с запросом позволяет отобрать из базы данных требуемую информацию, сгруппировать итоговые записи (на рис. 9.5 группировка выполнена по организациям-подрядчикам) и автоматически получить итоговые строки. Отчет можно напечатать, выбрав пункт меню Файл/Печать, или преобразовать в формат текстового процессора Word с помощью пункта меню Сервис/Связи с Office/Публикация в MS Word – так получен рис. 9.5. Наконец, в отчет нетрудно внести редакционные изменения, но не в режиме создания с помощью мастера отчетов, а в режиме конструктора. Так в нашем примере слово Sum, которое процедура Мастер отчетов вставляет в итоговые строки, заменено на слово Сумма. Вообще в режиме конструктора можно изменять и таблицы, и формы, и запросы, и отчеты.

 

Апрель-июнь

Организация АООТ «Мостшустрострой»

Код затрЗатратаСтоимостьДата

9 Строительство моста через р. Белый Урюм 995.00 15.06.98

8 Строительство моста через р. Черный Урюм 1 035.00 12.05.98

7 Проектирование моста через р. Белый Урюм 155.00 15.04.98

Итоги для 'Организация' = АООТ "Мостшустрострой" (3 записей)

Сумма 2 185.00

Организация ОАО "Всестрой"

Код затрЗатратаСтоимостьДата

12 Проектирование линии электропередач 305.00 02.04.98

11 Строительство трансформаторной подстанции 480.00 15.05.98

Итоги для 'Организация' = ОАО "Всестрой" (2 записей)

Сумма 785.00

ИТОГО 2 970.00

21 августа 1999 г.Страница 1 из 1

Рис. 9.5. Типичный вид отчета, получаемого с помощью СУБД Access

 

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

Кроме выполнения SQL-запросов в рамках базы данных, созданной на локальном компьютере, Access позволяет (пункт меню Запрос/Запрос SQL/К серверу) посылать запросы на SQL-сервер (см. подраздел 5.3), поддерживающий ODBC (Open Data Base Connectivity) – взаимодействие баз данных открытой архитектуры. Легче всего организовать такое использование Access в рамках технологии клиент/сервер, если в качестве SQL-сервера применяется Microsoft SQL Server, но и в этом случае требуется установка необходимых драйверов ODBC. Такие вопросы обычно решаются системными программистами и выходят за рамки этой книги. Но основные инструкции (команды) языка SQL мы считаем полезным рассмотреть, т.к. представление о языке SQL позволяет лучше понять возможности манипулирования данными, имеющиеся в современных СУБД. В русских переводах компьютерной литературы инструкции SQL и других языков программирования часто называют операторами. В англоязычных изданиях применяются термины statement или instruction.

 

9.4. Основные возможности языка структурированных запросов (SQL)

Сразу заметим, что в этой небольшой книге мы не ставим задачу дать описание SQL, а всего лишь приведем обзор основных команд и на нескольких примерах покажем возможности SQL-запросов. Что касается точного описания инструкций SQL, то это описание не совсем совпадает для различных СУБД. Наиболее известные серверы реляционных баз данных (Oracle, MS SQL Server, Cybase, Informix и некоторые другие) поддерживают ту или иную версию или уровень стандарта ANSI / ISO SQL (ANSI – Американский национальный институт стандартов, ISO – Международная организация стандартизации), но для повышения эффективности каждый коммерческий SQL-сервер применяет некоторые расширения стандарта. Приведенные ниже примеры проверены в рамках СУБД Access. Кстати, с