Организация баз данных

МИНИСТЕРСТВО ОБЩЕГО И ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ
РОССИЙСКОЙ ФЕДЕРАЦИИ
Таганрогский государственный радиотехнический университет
Кафедра вычислительной техники
_________________________________________________________________________
Дистанционное обучение
1999 - 2000 учебный год
О Т Ч Ё Т
о выполнении практических заданий
по курсу
ОРГАНИЗАЦИЯ БАЗ ДАННЫХ
студента группы ВД - 39
. Найденко Алексея Владимировича .
Ф.И.О. полностью
Задание выполнил ________________ ____________________
подпись студента дата выполнения
Задание проверил ________________ ____________________
оценка подпись преподавателя
____________________
дата выполнения задания
Рецензия преподавателя
___________________________________________________________________
___________________________________________________________________
___________________________________________________________________
___________________________________________________________________
___________________________________________________________________
___________________________________________________________________
В в е д е н и е
При проектировании программ выясняются запросы и пожелания клиента и определяется
возможный подход к решению задачи. Задача анализируется. На основе этого анализа реализуется
конкретная модель в конкретной программной среде. Результаты каждого этапа проектирования
используются в качестве исходного материала следующего этапа.
Анализируется текущая организация предприятия, выделяются проблемы для решения, опре-
деляются объекты отношения между ними , составляется «эскиз» текущей организации предпри-
ятия, разрабатывается модель с учетом конкретных условий ее функционирования.
База данных ориентирована на определенную предметную область и организована на основе
некоторого подмножества данных. Возможности баз данных полезны в областях, связанных с дол-
говременным управлением информацией, таких как электронные библиотеки и хранилища данных.
Предварительное планирование, подготовка данных,
последовательность создания информационной модели
При проектировании системы обработки данных больше всего нас интересует организация
данных. Помочь понять организацию данных призвана информационная модель.
Процесс создания информационной модели начинается с определения концептуальных тре-
бований ряда пользователей. Концептуальные требования могут определяться и для некоторых за-
дач (приложений), которые в ближайшее время реализовывать не планируется. Это может не-
сколько повысить трудоемкость работы, однако поможет наиболее полно учесть все нюансы
функциональности, требуемой для разрабатываемой системы, и снизит вероятность переделки в
дальнейшем. Требования отдельных пользователей должны быть представлены в едином «обоб-
щенном представлении». Последнее называют концептуальной моделью.
? Объект – это абстракция множества предметов реального мира, обладающих одинаковыми ха-
рактеристиками и законами поведения. Объект представляет собой типичный неопределенный эк-
земпляр такого множества.
Объекты объединяются в классы по общим характеристикам. Например, в предложении «Бе-
лый Дом является зданием», «Белый Дом» представляет объект, а «здание» – класс. Классы обо-
значаются абстрактными существительными.
? Класс – это множество предметов реального мира, связанных общностью структуры и поведе-
нием.
Концептуальная модель представляет объекты и их взаимосвязи без указывания способов
их физического хранения. Таким образом, концептуальная модель является, по существу, моделью
предметной области. При проектировании концептуальной модели все усилия разработчика долж-
ны быть направлены в основном на структуризацию данных и выявление взаимосвязей между ни-
ми без рассмотрения особенностей реализации и вопросов эффективности обработки. Проектиро-
вание концептуальной модели основано на анализе решаемых на этом предприятии задач по обра-
ботке данных. Концептуальная модель включает описания объектов и их взаимосвязей, пред-
ставляющих интерес в рассматриваемой предметной области и выявляемых в результате анализа
данных. Имеются в виду данные, используемые как в уже разработанных прикладных программах,
так и в тех, которые только будут реализованы.
Проектирование концептуальной модели базы данных:
Анализ данных: сбор основных данных (например, объекты, связи между объектами).
Определим первоначальные данные:
Заявки - поступающие от магазинов на определённый период.
Договора - заключаются с поставщиками на определённый вид товара.
Поставщики - организации или физические лица, с которыми заключаются договора на поставку
товара.
Заказчики - в основном магазины, а также предприятия и организации, подающие заказ на приоб-
ретение того или иного товара.
Счета - ведутся на этапе заключения договором с поставщиками, а также с заказчиками.
Накладные - создаются на основании получения заказа о заказчика, для отгрузки.
Справки - получение/выдача различных справок как заказчику так и поставщику.
Товар - присутствует на основании заявки и договора с поставщиком.
Определение взаимосвязей.
Взаимосвязь выражает отображение или связь между двумя множествами данных. Различают
взаимосвязи типа «один к одному», «один ко многим» и «многие ко многим».
Например, если заказчик производит заказ на покупку товара впервые, осуществляется пер-
вичная регистрация его данных и сведений о сделанном заказе. Если же заказчик производит заказ
повторно, осуществляется регистрация только данного заказа. Вне зависимости от того, сколько
раз данный заказчик производил заказы, он имеет уникальный идентификационный номер (уни-
кальный ключ заказа). Информация о каждом заказчике включает наименование заказчика, адрес,
телефон, факс, фамилию, имя, отчество, признак юридического лица и примечание. Таким обра-
зом, свойствами объекта Заказчик являются «уникальный ключ заказчика», «наименование заказ-
чика».
Следующий представляющий для нас интерес объект — Товар. Этот объект имеет свойства
«уникальный ключ товара», «наименование товара».
Второй рассматриваемый объект — Поставщик. Его свойствами являются «уникальный ключ
поставщика», «наименование поставщика».
Третий рассматриваемый объект — Заказчик. Его свойствами являются «уникальный ключ
заказчика», «наименование заказчика».
Взаимосвязь «один к одному» (между двумя типами объектов)
Допустим, в определенный момент времени один заказчик может сделать только один заказ.
В этом случае между объектами Заказчик и Товар устанавливается взаимосвязь «один к одному».
Взаимосвязь «один ко многим» (между двумя типами объектов)
В определенный момент времени один заказчик может стать обладателем нескольких това-
ров, при этом несколько заказчиков не могут являться обладателями одного товара (на условии ес-
ли заказчик не претендует на часть товара). Взаимосвязь «один ко многим» можно обозначить с
помощью одинарной стрелки в направлении к «одному» и двойной стрелки в направлении ко
«многим» .В этом случае одной записи данных первого объекта (его часто называют родительским
или основным) будет соответствовать несколько записей второго объекта (дочернего или подчи-
ненного). Взаимосвязь «один ко многим» очень распространена при разработке реляционных баз
данных. В качестве родительского объекта часто выступает справочник, а в дочернем хранятся
уникальные ключи для доступа к записям справочника. В нашем примере в качестве такого спра-
вочника можно представить объект Заказчик, в котором хранятся сведения о всех заказчиках. При
обращении к записи для определенного заказчика нам доступен список всех покупок, которые он
сделал, и сведения о которых хранятся в объекте Товар.
Взаимосвязь «один к одному» (между двумя свойствами)
Мы предполагаем, что ключ (номер) магазина является его уникальным идентификатором, то
есть он не изменяется и при последующих поступлениях заказов от данного магазина. Если наряду
с номером магазина в базе данных хранится и другой его уникальный идентификатор (например,
адрес), то между такими двумя уникальными идентификаторами существует взаимосвязь «один к
одному».
Взаимосвязь «один ко многим» (между двумя свойствами)
Имя поставщика и его номер существуют совместно. Поставщиков с одинаковыми именами
может быть много, но все они имеют различные номера. Каждому поставщику присваивается уни-
кальный номер. Это означает, что данному номеру поставщика соответствует только одно имя.
Взаимосвязь «один ко многим» обозначается одинарной стрелкой в направлении к «одному» и
двойной стрелкой в направлении ко «многим».
Первоначальная схема данных
Функциональная
модель
Исследование токов
Данных
Данные выявленные в
ходе разработки
Отдел обработки
заявок
Заявки
Договора
Договоров
Поставщики
Заказчики
Ведение счетов
Счета
Погрузка
Накладные
Товар
Инвентаризация
Справки
Определение объектов
Выделим следующие объекты:
1. ТОВАР - (Т);
2. ЗАКАЗЧИК - (З);
3. ПОСТАВЩИК - (П);
4. СЧЕТА - (С);
5. ДОГОВОР - (Д);
6. НАКЛАДНЫЕ - (Н).
Первоначальное графическое представление концептуальной модели
Т
З
П
С
Н
Д
Задание первичных и альтернативных ключей, определение свойств объектов
Для каждого объекта определим свойства, которые будем хранить в БД. При этом необходи-
мо учитывать тот факт, что при переходе от логической к физической модели данных может про-
изойти усечение числа объектов. На самом деле, как правило, значительное число данных, необхо-
димых пользователю, может быть достаточно легко подсчитано в момент вывода информации. В
то же время, в связи с изменением алгоритмов расчета или исходных величин, некоторые расчет-
ные показатели приходится записывать в БД, чтобы гарантированно обеспечить фиксацию их зна-
чений. Выбор показателей, которые обязательно следует хранить в БД, достаточно сложен. Нечас-
то можно найти однозначное решение этой проблемы, и в любом случае оно потребует тщатель-
ного изучения работы предприятия и анализа концептуальной модели.
Свойства, включаемые в состав БД для рассматриваемой модели, приведены в табл.1.
Таблица 1. Свойства и первичные ключи объектов информационной модели.
Объект
Первичный ключ
Свойства
ТОВАР
Уникальный ключ товара
Уникальный ключ товара
Наименование товара
ЗАКАЗЧИК
Уникальный ключ заказчика
Уникальный ключ заказчика
Наименование заказчика
Юридическая принадлежность
Ф.И.О. руководителя
Адрес
Телефон/факс
Наименование товара
Количество товара
Предполагаемая цена
ПОСТАВЩИК
Уникальный ключ поставщика
Уникальный ключ поставщика
Наименование поставщика
Юридическая принадлежность
Ф.И.О. руководителя
Адрес
Телефон/факс
Наименование товара
Количество товара
Дата изготовления
Акцизная марка
Расшифровка штрих-кода
Срок годности
Вес Брутто
Вес Нетто
Цена за единицу
Суммарная цена
Вид упаковки
Способ доставки
СЧЕТА
Номер счёта
Номер счёта
Дата продажи
Наименование поставщика
Адрес поставщика
Юридическая принадлежность п.
Наименование заказчика
Адрес заказчика
Юридическая принадлежность з.
Наименование товара
Количество товара
Сумма
НДС
Сумма к оплате
ДОГОВОР
Номер договора
Номер договора
Дата заключения
Номер счёта
Наименование поставщика
Адрес поставщика
Юридическая принадлежность
Наименование товара
Количество товара
Сумма
НДС
НАКЛАДНЫЕ
Номер накладной
Номер накладной
Дата накладной
Пометка об оплате
Номер счёта
Наименование заказчика
Адрес заказчика
Юридическая принадлежность
Наименование товара
Количество товара
Сумма
НДС
Графическое представление первой таблицы
С
З
П
Т
Н
Д
Приведение модели к требуемому 1 уровню нормальной формы
Приведение модели к требуемому уровню нормальной формы является основой построения
реляционной БД. В процессе нормализации элементы данных группируются в таблицы, представ-
ляющие объекты и их взаимосвязи. Теория нормализации основана на том, что определенный на-
бор таблиц обладает лучшими свойствами при включении, модификации и удалении данных, чем
все остальные наборы таблиц, с помощью которых могут быть представлены те же данные. Введе-
ние нормализации отношений при разработке информационной модели обеспечивает минималь-
ный объем физической, то есть записанной на каком-либо носителе БД и ее максимальное быстро-
действие, что впрямую отражается на качестве функционирования информационной системы.
Нормализация информационной модели выполняется в несколько этапов.
Данные, представленные в виде двумерной таблицы, являются первой нормальной формой
реляционной модели данных. Первый этап нормализации заключается в образовании двумерной
таблицы, содержащей все необходимые свойства информационной модели, и в выделении ключе-
вых свойств. Очевидно, что полученная весьма внушительная таблица будет содержать очень раз-
нородную информацию. В этом случае будут наблюдаться аномалии включения, обновления и
удаления данных, так как при выполнении этих действий нам придется уделить внимание данным
(вводить или заботиться о том, чтобы они не были стерты), которые не имеют к текущим действи-
ям никакого отношения. Например, может наблюдаться такая парадоксальная ситуация.
Отношение задано во второй нормальной форме, если оно является отношением в первой
нормальной форме и каждое свойство, не являющийся первичным свойством в этом отношении,
полностью зависит от любого возможного ключа этого отношения.
Если все возможные ключи отношения содержат по одному свойству, то это отношение зада-
но во второй нормальной форме, так как в этом случае все свойства, не являющиеся первичными,
полностью зависят от возможных ключей. Если ключи состоят более чем из одного свойства, от-
ношение, заданное в первой нормальной форме, может не быть отношением во второй нормальной
форме. Приведение отношений ко второй нормальной форме заключается в обеспечении полной
функциональной зависимости всех свойств от ключа за счет разбиения таблицы на несколько, в
которых все имеющиеся свойства будут иметь полную функциональную зависимость от ключа
этой таблицы. В процессе приведения модели ко второй нормальной форме в основном исключа-
ются аномалии дублирования данных.
Отношение задано в третьей нормальной форме, если оно задано во второй нормальной
форме и каждое свойство этого отношения, не являющийся первичным, не транзитивно зависит от
каждого возможного ключа этого отношения.
Транзитивная зависимость выявляет дублирование данных в одном отношении. Если А, В и
С - три свойства одного отношения и С зависит от В, а В от А, то говорят, что С транзитивно зави-
сит от А. Преобразование в третью нормальную форму происходит за счет разделения исходного
отношения на два.
Таблица 2. Свойства и первичные ключи измененных или добавленных объектов информацион-
ной модели.
Объект
Первичный ключ
Свойства
ТОВАР
Уникальный ключ товара
Уникальный ключ товара
Уникальный ключ поставщика
Уникальный ключ заказчика
Наименование товара
Дата изготовления
Акцизная марка
Расшифровка штрих-кода
Срок годности
Вес Брутто
Вес Нетто
Цена за единицу
Суммарная цена
Вид упаковки
ЗАКАЗЧИК
Уникальный ключ заказчика
Уникальный ключ заказчика
Наименование заказчика
Юридическая принадлежность
Ф.И.О. руководителя
Адрес
Телефон/факс
Предполагаемая цена
ПОСТАВЩИК
Уникальный ключ поставщика
Уникальный ключ поставщика
Наименование поставщика
Юридическая принадлежность
Ф.И.О. руководителя
Адрес
Телефон/факс
СЧЕТА
Номер счёта
Номер счёта
Дата продажи
Уникальный ключ товара
НДС
Сумма к оплате
ДОГОВОР
Номер договора
Номер договора
Дата заключения
Уникальный ключ поставщика
НАКЛАДНЫЕ
Номер накладной
Номер накладной
Уникальный ключ заказчика
Пометка об оплате
Дата накладной
Графическое представление второй таблицы
З
Н
Т
П
Д
С
Табличная с определёнными связями, окончательная концептуальная модель.
ТОВАР
Уник. ключ поставщика
Уник. ключ заказчика
Наименование товара
Дата изготовления
Акцизная марка
Расшиф. Штрих-кода
ЗАКАЗЧИК
Срок годности
ПОСТАВЩИК
Уник. ключ заказчика
Вес Брутто
Уник. ключ поставщика
Наименов. Заказчика
Вес Нетто
Наименов. поставщика
Юрид-ская. принад.
Цена за единицу
Юрид-ская. принад.
Ф.И.О. руководителя
Суммарная цена
Ф.И.О. руководителя
Адрес
Вид упаковки
Адрес
Телефон/факс
Уник. ключ товара
Телефон/факс
Предполагаемая цена
Номер договора
Номер накладной
Дата заключения
Пометка об оплате
Дата накладной
СЧЕТА
Уник. ключ товара
Номер счёта
Дата продажи
НДС
Сумма к оплате
Графическое представление концептуальной модели в третьей нормальной форме
З
Т
П
С
Концептуальная модель переносится затем в модель данных, совместимую с выбранной
СУБД. Возможно, что отраженные в концептуальной модели взаимосвязи между объектами ока-
жутся впоследствии нереализуемыми средствами выбранной СУБД. Это потребует изменения
концептуальной модели. Версия концептуальной модели, которая может быть обеспечена кон-
кретной СУБД, называется логической моделью.
Логическая модель отражает логические связи между элементами данных вне зависимости от
их содержания и среды хранения. Логическая модель данных может быть реляционной, иерархи-
ческой или сетевой. Пользователям выделяются подмножества этой логической модели, назы-
ваемые внешними моделями, отражающие их представления о предметной области. Внешняя мо-
дель соответствует представлениям, которые пользователи получают на основе логической моде-
ли, в то время как концептуальные требования отражают представления, которые пользователи
первоначально желали иметь и которые легли в основу разработки концептуальной модели. Логи-
ческая модель отображается в физическую память, такую, как диск, лента или какой-либо другой
носитель информации.
Иерархическая модель данных строится по принципу иерархии типов объектов, то есть один
тип объекта является главным, а остальные, находящиеся на низших уровнях иерархии, — подчи-
ненными. Между главным и подчиненными объектами устанавливается взаимосвязь «один ко мно-
гим». В то же время для каждого экземпляра главного объекта может быть несколько экземпляров
подчиненных типов объектов. Взаимосвязи между объектами напоминают взаимосвязи в генеало-
гическом дереве за единственным исключением: для каждого порожденного (подчиненного) типа
объекта может быть только один исходный (главный) тип объекта.
Итак, полученную концептуальную модель, будем считать логико-иерархической моделью
данных. Потому что по моему мнению, больше преобразований не получится. Конечную модель
можно считать оконченной.
Физическая модель, определяющая размещение данных, методы доступа и технику индек-
сирования, называется внутренней моделью системы.
Внешние модели никак не связаны с типом физической памяти, в которой будут храниться
данные, и с методами доступа к этим данным. Это положение отражает первый уровень независи-
мости данных. С другой стороны, если концептуальная модель способна учитывать расширение
требований к системе в будущем, то вносимые в нее изменения не должны оказывать влияния на
существующие внешние модели. Это — второй уровень независимости данных. Построение ло-
гической модели обусловлено требованиями используемой СУБД. Поэтому при замене СУБД она
также может измениться.
С точки зрения прикладного программирования независимость данных определяется не тех-
никой программирования, а его дисциплиной, т.е. для того чтобы при любом изменении системы
избежать перекомпиляции приложения, рекомендуется не определять константы (постоянные зна-
чения данных) в программе. Лучшее решение состоит в передаче программе значений в качестве
параметров.
Все актуальные требования предметной области и адекватные им «скрытые» требования на
стадии проектирования должны найти свое отражение в концептуальной модели. Конечно, нельзя
предусмотреть все возможные варианты использования и изменения базы данных. Но в большин-
стве предметных областей такие основные данные, как объекты и их взаимосвязи, относительно
стабильны. Меняются только информационные требования, то есть способы использования дан-
ных для получения информации.
Степень независимости данных определяется тщательностью проектирования базы данных.
Всесторонний анализ объектов предметной области и их взаимосвязей минимизирует влияние из-
менения требований к данным в одной программе на другие программы. В этом и состоит всеобъ-
емлющая независимость данных.
Основное различие между указанными выше тремя типами моделей данных (концептуаль-
ной, логической и физической) состоит в способах представления взаимосвязей между объектами.
При проектировании БД требуется различать взаимосвязи между объектами, между свойствами
одного объекта и между свойствами различных объектов.
В процессе проектирования объекты преобразуются в отношения, свойства в поля таблиц,
методы – в процедуры, формы и т.д. (что и было произведено). Правильно проведенный объектно-
ориентированный анализ позволяет значительно облегчить работу.
Таблица 3. Проект таблицы для физической модели.
№ п/п
Наименование поля
Примечание
ТОВАР
1.
Key_tovar
Уникальный ключ товара
2.
Key_postav
Уникальный ключ поставщика
3.
Key_zakaz
Уникальный ключ заказчика
4.
Name_tovar
Наименование товара
5.
Date
Дата изготовления
6.
Marka
Акцизная марка
7.
Kod
Расшифровка штрих-кода
8.
Srok_god
Срок годности
9.
Ves_b
Вес Брутто
10.
Ves_n
Вес Нетто
11.
Cena_1
Цена за единицу
12.
Cena
Суммарная цена
13.
Upakovka
Вид упаковки
ЗАКАЗЧИК
1.
Key_zakaz
Уникальный ключ заказчика
2.
Name_zakaz
Наименование заказчика
3.
Yrid_zakaz
Юридическая принадлежность
4.
FIO_zakaz
Ф.И.О. руководителя
5.
Adres_zakaz
Адрес
6.
Tel_zakaz
Телефон/факс
7.
Cena_z
Предполагаемая цена
8.
Number_N
Номер накладной
9.
Oplata
Пометка об оплате
10.
Date_N
Дата накладной
ПОСТАВЩИК
1.
Key_poctav
Уникальный ключ поставщика
2.
Name_postav
Наименование поставщика
3.
Yrid_poctav
Юридическая принадлежность
4.
FIO_postav
Ф.И.О. руководителя
5.
Adres_postav
Адрес
6.
Tel_postav
Телефон/факс
7.
Number_D
Номер договора
8.
Date_Z
Дата заключения
СЧЕТА
1.
Number_S
Номер счёта
2.
Date_P
Дата продажи
3.
Key_tovar
Уникальный ключ товара
4.
NDS
НДС
5.
Summa
Сумма к оплате
Одним из основных факторов, влияющих на производительность программ, которые взаимо-
действуют с базой данных, является способ хранения и доступа к данным. Обычно в дополнение к
специализированным методам доступа в рамках внешней модели СУБД использует несколько ме-
тодов доступа внутренней модели. Мы рассмотрим (по условию варианта) индексно-
последовательный метод доступа (ИМД).
Существует множество индексных методов доступа, в основе которых лежит принцип созда-
ния отдельного файла или структуры из статей значений действительного ключа. Статья действи-
тельного ключа называется статьёй индекса, а весь файл действительных ключей - индексом. Ин-
дексный файл значительно меньше собственно базы данных, и, поскольку в оперативной памяти
могут находиться многие из его статей, скорость поиска в нём гораздо выше.
В индексно-последовательном методе доступа индексный файл всегда упорядочен по так на-
зываемому первичному ключу. Первичный ключ - главный атрибут физической записи. По его
значению идентифицируется физическая запись. До тех пор, пока это возможно, записи хранятся в
той же логической последовательности, что и индекс (отсюда и название "индексно-
последовательный метод доступа").
Приведём пример таблицы индексов и их связи с имеющимися файлами данных, согласно
варианта.
Таблица 4. Таблица индексного файла "ТОВАР" для индексно-последовательного метода доступа.
Примечание (Доходя через индексы к файлу данных, посредством самого индекса считывается
наименование товара и далее вся информация по полям находящаяся в записи, согласно таблицы
ТОВАР).
Индексный файл
Блок 7
Значение
Ключа
Номер
Блока
Файл дан-
ных Блок 1
10
1
01
15
2
05
Индексный файл
10
Блок 10
Блок 2
Значение
Номер
11
Ключа
Блока
15
15
7
25
8
Блок 3
35
9
Блок 8
16
Индекс 2-го уровня
Значение
Номер
20
Ключа
Блока
20
3
25
4
Блок 4
21
25
Блок 5
Блок 9
26
Значение
Номер
30
Ключа
Блока
30
5
Блок 6
35
6
31
Индекс 1-го уровня
35
У
н
и
к
а
л
ь
н
ы
й
к
л
ю
ч
т
о
в
а
р
а
Н
а
и
м
е
н
о
в
а
н
и
е
т
о
в
а
р
а
У
н
и
к
а
л
ь
н
ы
й
к
л
ю
ч
п
о
с
т
а
в
щ
и
к
а
У
н
и
к
а
л
ь
н
ы
й
к
л
ю
ч
з
а
к
а
з
ч
и
к
а
Д
а
т
а
и
з
г
о
т
о
в
л
е
н
и
я
А
к
ц
и
з
н
а
я
м
а
р
к
а
Р
а
с
ш
и
ф
р
о
в
к
а
ш
т
р
и
х
-
к
о
д
а
С
р
о
к
г
о
д
н
о
с
т
и
В
е
с
Б
р
у
т
т
о
В
е
с
Н
е
т
т
о
Ц
е
н
а
з
а
е
д
и
н
и
ц
у
С
у
м
м
а
р
н
а
я
ц
е
н
а
В
и
д
у
п
а
к
о
в
к
и
Форма «ГЛАВНАЯ КНОПОЧНАЯ ФОРМА»
Option Compare Database
Option Explicit
Private Sub Form_Open(Cancel As Integer)
' Свертывание окна базы данных, инициализация формы.
' Переход на страницу кнопочной формы, отмеченную для использования по умолчанию.
Me.Filter = "[ItemNumber] = 0 AND [Argument] = 'по умолчанию' "
Me.FilterOn = True
End Sub
Private Sub Form_Current()
' Обновление заголовка и заполнение списка команд.
Me.Caption = Nz(Me![ItemText], "")
FillOptions
End Sub
Private Sub FillOptions()
' Заполнение команд для страницы кнопочной формы.
' Число кнопок в форме.
Const conNumButtons = 8
Dim dbs As Database
Dim rst As Recordset
Dim strSQL As String
Dim intOption As Integer
' Установка фокуса на первую кнопку формы, скрытие всех кнопок формы, кроме первой.
' Поле с фокусом скрыть нельзя.
Me![Option1].SetFocus
For intOption = 2 To conNumButtons
Me("Option" & intOption).Visible = False
Me("OptionLabel" & intOption).Visible = False
Next intOption
' Открытие таб. элементов кнопочной формы, поиск первого элемента текущей страницы формы.
Set dbs = CurrentDb()
strSQL = "SELECT * FROM [Элементы кнопочной формы]"
strSQL = strSQL & " WHERE [ItemNumber] > 0 AND [SwitchboardID]=" & Me![SwitchboardID]
strSQL = strSQL & " ORDER BY [ItemNumber];"
Set rst = dbs.OpenRecordset(strSQL)
' Вывод сообщения при отсутствии элементов на странице кнопочной формы.
' В остальных случаях - заполнение страницы элементами.
If (rst.EOF) Then
Me![OptionLabel1].Caption = "Элементы кнопочной формы отсутствуют"
Else
While (Not (rst.EOF))
Me("Option" & rst![ItemNumber]).Visible = True
Me("OptionLabel" & rst![ItemNumber]).Visible = True
Me("OptionLabel" & rst![ItemNumber]).Caption = rst![ItemText]
rst.MoveNext
Wend
End If
' Закрытие набора записей и базы данных.
rst.Close
dbs.Close
End Sub
Private Function HandleButtonClick(intBtn As Integer)
' Эта функ. вызывается при нажатии кнопки. Аргумент intBtn указывает, какая кнопка была нажата.
' Константы для выполняемых команд.
Const conCmdGotoSwitchboard = 1
Const conCmdOpenFormAdd = 2
Const conCmdOpenFormBrowse = 3
Const conCmdOpenReport = 4
Const conCmdCustomizeSwitchboard = 5
Const conCmdExitApplication = 6
Const conCmdRunMacro = 7
Const conCmdRunCode = 8
' Особая ошибка.
Const conErrDoCmdCancelled = 2501
Dim dbs As Database
Dim rst As Recordset
On Error GoTo HandleButtonClick_Err
' Поиск записи, соответствующей нажатой кнопке, в таблице элементов кнопочной формы.
Set dbs = CurrentDb()
Set rst = dbs.OpenRecordset("Элементы кнопочной формы", dbOpenDynaset)
rst.FindFirst "[SwitchboardID]=" & Me![SwitchboardID] & " AND [ItemNumber]=" & intBtn
' Если нужная запись не найдена, вывод сообщения об ошибке и выход из функции.
If (rst.NoMatch) Then
MsgBox "Ошибка при чтении таблицы элементов кнопочной формы."
rst.Close
dbs.Close
Exit Function
End If
Select Case rst![Command]
' Переход к другой кнопочной форме.
Case conCmdGotoSwitchboard
Me.Filter = "[ItemNumber] = 0 AND [SwitchboardID]=" & rst![Argument]
' Открытие формы в режиме добавления записей.
Case conCmdOpenFormAdd
DoCmd.OpenForm rst![Argument], , , , acAdd
' Открытие формы.
Case conCmdOpenFormBrowse
DoCmd.OpenForm rst![Argument]
' Открытие отчета.
Case conCmdOpenReport
DoCmd.OpenReport rst![Argument], acPreview
' Настройка кнопочной формы.
Case conCmdCustomizeSwitchboard
' Обработка ситуации, когда диспетчер
' кнопочных форм не установлен
' (например, при сокращенной установке).
On Error Resume Next
Application...n "WZMAIN80.sbm_Entry"
If (Err <> 0) Then MsgBox "Команда недоступна."
On Error GoTo 0
' Обновление формы.
Me.Filter = "[ItemNumber] = 0 AND [Argument] = 'по умолчанию' "
Me.Caption = Nz(Me![ItemText], "")
FillOptions
' Выход из приложения.
Case conCmdExitApplication
CloseCurrentDatabase
' Запуск макроса.
Case conCmdRunMacro
DoCmd...nMacro rst![Argument]
' Выполнение программы.
Case conCmdRunCode
Application...n rst![Argument]
' Другие команды не поддерживаются.
Case Else
MsgBox "Неизвестная команда."
End Select
' Закрытие набора записей и базы данных.
rst.Close
dbs.Close
HandleButtonClick_Exit:
Exit Function
HandleButtonClick_Err:
' Если выполнение прервано пользователем, сообщение об ошибке не выводится.
' Вместо этого выполнение продолжается со следующей строки.
If (Err = conErrDoCmdCancelled) Then
Resume Next
Else
MsgBox "Ошибка при выполнении команды.", vbCritical
Resume HandleButtonClick_Exit
End If
End Function
Форма «ЗАКАЗЧИК»
Option Compare Database
Option Explicit
Private Sub Кнопка18_Click()
On Error GoTo Err_Кнопка18_Click
DoCmd.DoMenuItem acFormBar, acEditMenu, 8, , acMenuVer70
DoCmd.DoMenuItem acFormBar, acEditMenu, 6, , acMenuVer70
Exit_Кнопка18_Click:
Exit Sub
Err_Кнопка18_Click:
MsgBox Err.Description
Resume Exit_Кнопка18_Click
End Sub
Private Sub Кнопка20_Click()
On Error GoTo Err_Кнопка20_Click
Dim stDocName As String
stDocName = "Запрос2"
DoCmd.OpenReport stDocName, acPreview
Exit_Кнопка20_Click:
Exit Sub
Err_Кнопка20_Click:
MsgBox Err.Description
Resume Exit_Кнопка20_Click
End Sub
Private Sub Кнопка33_Click()
On Error GoTo Err_Кнопка33_Click
Dim stDocName As String
Dim stLinkCriteria As String
stDocName = "Товары"
DoCmd.OpenForm stDocName, , , stLinkCriteria
Exit_Кнопка33_Click:
Exit Sub
Err_Кнопка33_Click:
MsgBox Err.Description
Resume Exit_Кнопка33_Click
End Sub
Sub ПолеСоСписком34_AfterUpdate()
' Поиск записи, соответствующей этому элементу управления.
Me.RecordsetClone.FindFirst "[Name_zakaz] = '" & Me![ПолеСоСписком34] & "'"
Me.Bookmark = Me.RecordsetClone.Bookmark
End Sub
Форма «ПОСТАВЩИК»
Option Compare Database
Option Explicit
Private Sub Кнопка18_Click()
On Error GoTo Err_Кнопка18_Click
DoCmd.DoMenuItem acFormBar, acEditMenu, 8, , acMenuVer70
DoCmd.DoMenuItem acFormBar, acEditMenu, 6, , acMenuVer70
Exit_Кнопка18_Click:
Exit Sub
Err_Кнопка18_Click:
MsgBox Err.Description
Resume Exit_Кнопка18_Click
End Sub
Private Sub Кнопка20_Click()
On Error GoTo Err_Кнопка20_Click
Dim stDocName As String
stDocName = "Запрос1"
DoCmd.OpenReport stDocName, acPreview
Exit_Кнопка20_Click:
Exit Sub
Err_Кнопка20_Click:
MsgBox Err.Description
Resume Exit_Кнопка20_Click
End Sub
Форма «ТОВАР»
Option Compare Database
Option Explicit
Sub ПолеСоСписком18_AfterUpdate()
' Поиск записи, соответствующей этому элементу управления.
Me.RecordsetClone.FindFirst "[Name_tovar] = '" & Me![ПолеСоСписком18] & "'"
Me.Bookmark = Me.RecordsetClone.Bookmark
End Sub
Private Sub Кнопка25_Click()
On Error GoTo Err_Кнопка25_Click
DoCmd.Close
Exit_Кнопка25_Click:
Exit Sub
Err_Кнопка25_Click:
MsgBox Err.Description
Resume Exit_Кнопка25_Click
End Sub
Форма «О ПРОГРАММЕ»
Option Compare Database ' Сортировка базы данных для сравнения строк.
Option Explicit ' Обязательное описание переменных перед применением.
Private Sub Отмена_Click()
' Программа, созданная мастером кнопок.
On Error GoTo Err_Cancel_Click
' Закрытие формы.
DoCmd.Close
Exit_Cancel_Click:
Exit Sub
Err_Cancel_Click:
MsgBox Err.Description
Resume Exit_Cancel_Click
End Sub
Private Sub ОК_Click()
On Error GoTo Err_OK_Click
Dim strMsg As String, strTitle As String
Dim intStyle As Integer
' Если отчет о продажах по годам не был открыт для просмотра или печати, возникает ошибка.
' (Перем. blnOpening имеет значение True, только если для отчета произошло событие Open.)
If Not Reports![Дата].blnOpening Then Err.Raise 0
' Скрытие формы.
Me.Visible = False
Exit_OK_Click:
Exit Sub
Err_OK_Click:
strMsg = "Для использования формы нужно просматривать или печатать отчет 'Продажи по го-
дам' из окна базы данных или конструктора."
intStyle = vbOKOnly
strTitle = "Открытие из отчета"
MsgBox strMsg, intStyle, strTitle
Resume Exit_OK_Click
End Sub
Private Sub Кнопка5_Click()
On Error GoTo Err_Кнопка5_Click
DoCmd.Close
Exit_Кнопка5_Click:
Exit Sub
Err_Кнопка5_Click:
MsgBox Err.Description
Resume Exit_Кнопка5_Click
End Sub
Форма «ПОДЧИНЁННАЯ ФОРМА ТОВАРА»
Option Compare Database
Option Explicit
Private Sub Кнопка22_Click()
On Error GoTo Err_Кнопка22_Click
DoCmd.DoMenuItem acFormBar, acEditMenu, 8, , acMenuVer70
DoCmd.DoMenuItem acFormBar, acEditMenu, 6, , acMenuVer70
Exit_Кнопка22_Click:
Exit Sub
Err_Кнопка22_Click:
MsgBox Err.Description
Resume Exit_Кнопка22_Click
End Sub
Private Sub Кнопка23_Click()
On Error GoTo Err_Кнопка23_Click
DoCmd.DoMenuItem acFormBar, acEditMenu, 8, , acMenuVer70
DoCmd.DoMenuItem acFormBar, acEditMenu, 6, , acMenuVer70
Exit_Кнопка23_Click:
Exit Sub
Err_Кнопка23_Click:
MsgBox Err.Description
Resume Exit_Кнопка23_Click
End Sub
ЗАПРОС1
SELECT Товары.Name_tovar, Sum(Товары.Cena) AS Sum_Cena, Поставщик.Name_postav, Постав-
щик.Number_D, Поставщик.Date_Z
FROM Поставщик INNER JOIN Товары ON Поставщик.Key_postav = Товары.Key_tovar
WHERE (((Поставщик.Name_postav)=[Forms]![Поставщик]![Name_postav]))
GROUP BY Товары.Name_tovar, Поставщик.Name_postav, Поставщик.Number_D, Постав-
щик.Date_Z;
ЗАПРОС2
SELECT Заказчик.Name_zakaz, Заказчик.Adres_zakaz, Заказчик.Number_N, Заказчик.Date_N, Това-
ры.Name_tovar, Товары.Srok_god, Товары.Ves_b, Товары.Ves_n, Товары.Cena, Товары.Date
FROM [Заказчик] INNER JOIN Товары ON Заказчик.Name_tov = Товары.Name_tovar
WHERE (((Заказчик.Name_tov)=[Forms]![Заказчик1]![Name_tov]))
GROUP BY Заказчик.Name_zakaz, Заказчик.Adres_zakaz, Заказчик.Number_N, Заказчик.Date_N,
Товары.Name_tovar, Товары.Srok_god, Товары.Ves_b, Товары.Ves_n, Товары.Cena, Товары.Date;
13