Пример 1. Предметная область “Инвестиционная компания (внутренний учет)”
1. Описание постановки задачи. Описание бизнес-
правил
Наименование предприятия:
Инвестиционная КомпанияНаименование предметной области: Инвестиционная компания, внутренний учет сделок.
Цель разработки информационной системы (базы данных): информационное обеспечение работы финансового менеджера, портфельного менеджера для анализа финансовых результатов инвестиций.
Пользователь базы данных: портфельный менеджер, осуществляющий текущее управление портфелем ценных бумаг в рамках портфельной политики, разработанной финансовым менеджером или клиентом.
Точка зрения: Финансовый менеджер.
Модель бизнес-процессов и информации предметной области приведена на рис. П.1.

Рис. П.2.1. Основные компоненты бизнес-системы (процессы и информация)
Описание бизнес-процессов
:1. Финансовый менеджер (ФМ) или клиент (К) разрабатывает портфельную политику, устанавливает основные характеристики портфеля (максимальный риск, минимальная прибыль, ликвидность портфеля).
2. Портфельный менеджер (ПМ) анализирует и выбирает объекты для инвестирования в рамках портфельной политики и основных характеристик, составляет портфель, согласовывает с (ФМ или К) и направляет заказ трейдеру (Т) на покупку (продажу) ценных бумаг.
3. Трейдер принимает заказ ПМ, исполняет его, посылает отчет ПМ. Отчет включает в себя информацию о виде операции (покупка или продажа), дате операции, о том, что, в каком объеме и по какой цене куплено (продано).
4. ПМ ведет журнал учета операций, журнал состояния портфеля, журнал сводных итогов. Эти три отчета посылаются ФМ или К. База данных, содержащая сведения о совершенных сделках, предназначена для автоматизации составления этих отчетов.
Перечень процессов, для поддержки которых создается ИС (база данных):
·
учет совершенных сделок;·
учет представленных ценных бумаг эмитентов;·
учет полученных и уплаченных сумм ;·
учет состояния портфеля;·
составление отчета.Перечень отчетов по предметной области:
1. Отчет о совершенных сделках - за день, за период, по типам операций.
2. Журнал учета операций - на указанную дату, за период.
3. Журнал состояния портфеля - за день.
Перечень запросов к базе данных:
Запрос 1.
Вывести информацию обо всех операциях купли за указанный день (в примере - за 04.08.97 г.).
Запрос 2.
Вывести информацию обо всех операциях продажи за указанный день (в примере - за 04.08.97 г.).
Запрос 3.
Информация о количестве ценных бумаг указанного эмитента по типам акций.
Запрос 4.
Выбрать данные для “Журнала состояния портфеля”.
Запрос 5.
Показать итоги совершенных операций за день для получения “Журнала учета операций”.
2. Информационная модель данных
При анализе бизнес - процессов предметной области был выявлен следующий перечень сущностей:
·
журнал операций (сделок);·
справочник операций;·
эмитент;·
доллар;·
акция (справочник типов ценных бумаг);·
рынок.Информацию из отчета трейдера портфельный менеджер заносит в “Журнал операций ”, где код операции обозначается “+” или “- ”. Для расшифровки необходима сущность “Справочник операций”. В сущности “Эмитент” хранится информация об эмитентах, с ценными бумагами которых работает портфельный менеджер. В этой сущности тип акции обозначается “о” / “п” (общая, привилегированная). Для расшифровки нужна сущность “Акция
”.В Российской Торговой Системе (РТС) цена акции устанавливается в долларах США ($). Для составления отчетов портфельного менеджера необходимо переводить цену в рубли. Для перевода необходима сущность “Доллар”, в которой содержится обменный курс доллара (руб/ $) на определенную дату. Для отслеживания состояния портфеля необходимо проводить переоценку финансовых активов, содержащихся в нем, каждый день (рабочий). Для этого отслеживают рынок ценных бумаг, т.е. информацию о результатах торгов в РТС вносят в сущность “Рынок”.
На рис. 2 показана концептуальная информационная модель предметной области.

Рис. П.2.2. Концептуальная информационная модель предметной области
На основе анализа концептуальной модели выполнена диаграмма отношения сущностей (ERD) по стандарту IDEF1X, показанная на рис. П.2.3. В диаграмме появилась сущность “Остаток на конец дня”, необходимая для составления отчетов.
Рис. П.2.3. Диаграмма отношения сущностей
3. Физическая модель
На рис. П.2.4 приведена физическая модель базы данных, выполненная на основе логической.
Рис. П.2.4. Физическая модель
Далее в табл. 1 - 7 приведено описание физической структуры реляционных таблиц (файлов *.dbf).
Таблица 1
Имя сущности: акция
Имя таблицы: Share
|
Заголовок поля |
Идентифи-катор поля |
Тип поля |
Первичный ключ (PK) |
Внешний ключ (FK) |
|
|
тип акции |
Type_sh |
CHARACTER(1) |
Да |
Нет |
|
|
наименование акции |
Name_sh |
CHARACTER(17) |
Нет |
Нет |
|
Таблица 2
Имя сущности: доллар
Имя таблицы: Dollar
|
Заголовок поля |
Идентификатор поля |
Тип поля |
Первичный ключ (PK) |
Внешний ключ (FK) |
|
|
дата курса |
Date_cours |
DATE |
Да |
Нет |
|
|
курс в руб |
Course |
NUMERIC(7.2) |
Нет |
Нет |
|
Таблица 3
Имя сущности: журнал операций
Имя таблицы: Operatio
|
Заголовок поля |
Идентификатор поля |
Тип поля |
Первичный ключ (PK) |
Внешний ключ (FK) |
|
дата курса |
Date_cours |
DATE |
Да |
Да |
|
тип акции |
Type_sh |
CHARACTER(1) |
Да |
Да |
|
код в РТС |
Code_rts |
CHARACTER(5) |
Да |
Да |
|
код операции |
Code_op |
CHARACTER(1) |
Да |
Да |
|
дата операции |
Date_op |
DATE |
Нет |
Нет |
|
количество ценных бумаг |
Quantity |
NUMERIC(5) |
Нет |
Нет |
|
цена в $ |
Price |
NUMERIC(9.4) |
Нет |
Нет |
Таблица 4
Имя сущности: рынок
Имя таблицы: Stmarket
|
Заголовок поля |
Идентификатор поля |
Тип поля |
Первичный ключ (PK) |
Внешний ключ (FK) |
|
|
дата курса |
Date_cours |
DATE |
Да |
Да |
|
|
тип акции |
Type_sh |
CHARACTER(20) |
Да |
Да |
|
|
окончание табл.4 |
|||||
|
Заголовок поля |
Идентификатор поля |
Тип поля |
Первичный ключ (PK) |
Внешний ключ (FK) |
|
|
код в РТС |
Code_rts |
CHARACTER(20) |
Да |
Да |
|
|
максимальная цена покупки |
Best_bid |
NUMERIC(9.4) |
Нет |
Нет |
|
|
минимальная цена продажи |
Best_offer |
NUMERIC(9.4) |
Нет |
Нет |
|
|
цена последней сделки |
Close |
NUMERIC(9.4) |
Нет |
Нет |
|
|
объем покупок |
Volume |
NUMERIC(8) |
Нет |
Нет |
|
Таблица 5
Имя сущности: справочник операций
Имя таблицы: Code_oper
|
Заголовок поля |
Идентификатор поля |
Тип поля |
Первичный ключ (PK) |
Внешний ключ (FK) |
||||||||
|
код операции |
Code_op |
CHARACTER(1) |
Да |
Нет |
||||||||
|
окончание табл.5 |
||||||||||||
|
Заголовок поля |
Идентификатор поля |
Тип поля |
Первичный ключ (PK) |
Внешний ключ (FK) |
||||||||
|
наименование операции |
Operation |
CHARACTER(7) |
Нет |
Нет |
||||||||
Таблица 6
Имя сущности : эмитент
Имя таблицы: Emitent
|
Заголовок поля |
Идентификатор поля |
Тип поля |
Первичный ключ (PK) |
Внешний ключ (FK) |
|
|
тип акции |
Type_sh |
CHARACTER(1) |
Да |
Да |
|
|
код в РТС |
Code_rts |
CHARACTER(5) |
Да |
Нет |
|
|
наименование эмитента |
Name_em |
CHARACTER(20) |
Нет |
Нет |
|
|
номинал в руб |
Nominal |
NUMERIC(6) |
Нет |
Нет |
|
|
окончание табл.6 |
|||||
|
дивиденды за последний год руб |
div |
NUMERIC(6) |
Нет |
Нет |
|
|
отрасль эмитента |
Branch |
CHARACTER(40) |
Нет |
Нет |
|
|
Дополнительная информация |
Info |
MEMO |
Нет |
Нет |
|
Таблица 7
Имя сущности: остаток на конец дня
Имя таблицы: Saldo
|
Заголовок поля |
Идентификатор поля |
Тип поля |
Первичный ключ (PK) |
Внешний ключ (FK) |
|
дата операции |
date_op |
DATE |
Да |
Нет |
|
сумма остатка на конец, тыс.руб. |
summ_ost |
NUMERIC(9.4) |
Нет |
Нет |
3. Описание запросов к базе данных
Запросы определяются требованиями отчетов, т.е. сформированный запрос в последующем может быть выведен в отчет.
Запрос 1.
Вывести информацию обо всех операциях купли за указанный день (в примере - за 04.08.97 г.).
Имя файла - запроса
: zapros1.qprТекст на SQL:
SELECT Operatio.date_op, Operatio.code_op, Operatio.quantity,;
Operatio.price, Emitent.name_em, Emitent.type_sh, Dollar.course;
FROM Emitent, Operatio, Dollar;
WHERE Operatio.type_sh = Emitent.type_sh;
AND Dollar.date_cours = Operatio.date_cours;
AND (DTOC(Operatio.date_op) = "04.08.97";
AND Operatio.code_op = "+")
Запрос 2.
Вывести информацию обо всех операциях продажи за указанный день (в примере - за 04.08.97 г.).
Имя файла - запроса:
zapros2.qprТекст на SQL:
SELECT Operatio.code_op, Operatio.date_op, Operatio.quantity,;
Operatio.price, Emitent.name_em, Emitent.type_sh, Dollar.course;
FROM Emitent, Operatio, Dollar;
WHERE Operatio.type_sh = Emitent.type_sh;
AND Dollar.date_cours = Operatio.date_cours;
AND (DTOC(Operatio.date_op) = "04.08.97";
AND Operatio.code_op = "-")
Запрос 3.
Информация о количестве ценных бумаг указанного эмитента по типам акций.
Имя файла - запроса: zapros3.qpr
Текст на SQL:
SELECT Emitent.name_em, Emitent.code_rts, Share.*,;
COUNT(Emitent.name_em);
FROM Share, Emitent;
WHERE Emitent.type_sh = Share.type_sh;
GROUP BY Emitent.code_rts, Emitent.type_sh
Запрос 4.
Выбрать данные для “Журнала состояния портфеля”.
Текст на SQL:
SELECT Emitent.name_em, Emitent.code_rts, Share.*, COUNT(Share.name_sh);
FROM Share, Emitent;
WHERE Emitent.type_sh = Share.type_sh
Запрос 5.
Показать итоги совершенных операций за день для получения
“Журнала учета операций”.
Текст на SQL:
SELECT Emitent.type_sh, Emitent.code_rts, Emitent.name_em, Operatio.*,;
Dollar.*;
FROM Emitent, Operatio, Dollar;
WHERE Operatio.type_sh = Emitent.type_sh;
AND Dollar.date_cours = Operatio.date_cours;
GROUP BY Operatio.date_op;
HAVING Operatio.date_op = CTOD("08.04.98")
Перечень отчетов, подробное описание которых приведено далее:
1.
Отчет о совершенных сделках - за день.2. Журнал учета операций - на указанную дату.
3. Журнал состояния портфеля - за день.
Журнал учета операций
В Журнале учета операций (ЖУО) ПМ отражает совершенные за день торгов сделки по каждому виду операций, причем отдельно приводится информация по операциям купли и продажи.
По результатам операций за день торгов определяются уплаченная и полученная суммы денежных средств, в данной работе автор абстрагируется от налогов и комиссий. В отчете должны быть показаны все совершенные за день операции (т.е. требуется группировка данных в таблицах).
Ниже на рис.П.2.5 приведена форма отчета.
Выражения для формирования полей отчета (в скобках указаны номера граф отчета):
(1) Эмитент
- emitent.name_em;(2) Тип
- emitent.type_sh;iif(operatio.code_op=‘+’,... формируем графы (3), (4), (5))
(3) Колич. шт
- operatio.quantity;(4) Цена
, тыс. руб. - operatio.price * dollar.course;(5) Сумма уплач. т.руб
. - operatio.price * dollar.course * operatio.quantity ;iif(operatio.code_op=‘-’, ...формируем графы (6), (7), (8))
(6) Колич. шт
- operatio.quantity;(7)
Цена, тыс. руб. - operatio.price * dollar.course;(8)
Сумма получ. т.руб - operatio.price * dollar.course * operatio.quantity
Рис.П.2.5. Форма отчета “Журнал учета операций”
Журнал состояния портфеля
По данным ЖУО заполняется Журнал состояния портфеля (ЖСП), который отражает состояние капитала на начало и конец дня торгов (начальный и конечный остаток ) с учетом результатов операций купли - продажи, совершенных за торговый день, а также переоценки всех активов и остатка денежных средств. При покупке акций на первичном аукционе переоценка портфеля не производится.
Переоценка может быть сделана в зависимости от учетной политики, принятой в данной инвестиционной компании, либо в ценах закрытия, либо по средневзвешенным ценам торгового дня.
При заполнении ЖСП на текущий день в графу “Начальный остаток” переписываются данные из журнала состояния предыдущего дня из графы “Конечный остаток”.
Начальный остаток денежных средств представляет собой сумму остатка денежных средств и дневной прибыли ( убытка) операций за предшествующий день (этот показатель приводится в ЖУО отдельной строкой).
Конечный остаток на конец текущего дня формируется на основе результатов проведенных операций переоценки акций и остатка денежных средств. Конечный остаток показывает состояние капитала инвестора и позволяет определить наличие прибыли (убытка) капитала, полученной в течение текущего торгового дня.
Эти показатели приводятся в ЖСП отдельной строкой.
Прибыль (убыток) капитала за день торгов определяется по формуле (1):
![]()
где
![]()
![]()
Дневная текущая доходность

где
-
В журнале состояния портфеля должны быть выполнены группировка данных по дате и выборка по текущей дате. Т.е. в отчете должна быть сформирована одна строка, соответствующая условию группировки и выборки. Для получения отчета должен использоваться запрос 5
.На рис. П.2.6 показана форма “Журнала состояния портфеля”
Рис. П.2.6. Журнал состояния портфеля
Выражения для расчета данных в графах отчета (в скобках указаны номера граф):
(2)
Количество, шт - Saldo.quantity;(4) Сумма, тыс.руб
.- Saldo.sum_ost;(5) Количество, шт. -
Operatio.quantity;(7)
Сумма, тыс.руб. - Operatio.price * Dollar.course * Operatio.quantityРезультаты, полученные в “Журнале состояния портфеля” ежедневно переносятся в таблицу Saldo (“Остаток на конец дня”).
Журнал сводных итогов
На основе данных ЖСП составляется журнал сводных итогов (ЖСИ), в котором приводится величина капитала на начало и конец торгового дня, дневное изменение капитала, полное изменение капитала (нарастающим итогом) и денежные средства на конец торгового дня.
ЖСИ ведется от начальной даты инвестирования. Начальный капитал указывается в правом верхнем углу ЖСИ и переписывается в первую графу ЖСИ как начальный остаток первого дня.
ЖСИ позволяет провести анализ финансовых результатов инвестиций и оценить эффективность управления капиталом за отчетный период. На рис. П.2.7 показана форма отчета “Журнал сводных итогов”.
Рис. П.2.7. Форма отчета “Журнал сводных итогов”
Выручка за период, тыс. руб. , прибыль (убыток) за период, тыс. руб. , доходность инвестиций, % год -
рассчитываются с помощью переменных отчета.
Пример 2. Предметная область “Учет работы с клиентами, учет продаж рекламного времени”
1. Описание постановки задачи. Описание бизнес-
Наименование фирмы
: радиостанция “Неро”.Наименование предметной области
: работа отдела маркетинга и рекламы (продажа рекламы на радио), учет работы с клиентами.Цель разработки информационной системы (базы данных): организация оперативного учета состояния работы с клиентами - рекламодателями и рекламными агентами, учет продаж рекламного времени.
Точка зрения: руководитель отдела маркетинга.
Перечень процессов, которые будут далее рассмотрены подробнее:
Перечень выявленных бизнес - процессов:
На рис. П.2.1 показана упрощенная схема взаимосвязи бизнес - компонент с информационными потоками.
Рис. П.2.1. Основные компоненты бизнес - системы и информации.
Описание регламента для некоторых процессов:
Уточнение правил выполнения бизнес-процессов для предметной области:
Перечень выявленных сущностей:
Перечень возможных запросов к базе данных:
Перечень возможных отчетов:
1.
Список рекламодателей (по формам собственности, по количеству контрактов и т.д.)2.
Перечень контрактов, заключенных каждым продавцом.
2. Информационная модель данных
На рис.
П.2.2 представлена концептуальная модель данных.
Рис. П.2.2. Информационная модель предметной области.
.1. Логическая модель
На рис. П.2.3 представлена диаграмма отношения сущностей, выполненная на основе анализа концептуальной модели.

Рис. П.2.3. Диаграмма отношения сущностей (
ERD)Физическая модель
На рис. П.2.4 показана физическая модель данных в отражении
Access.
Рис. П.2.4. Представление физической модели данных в
AccessДля просмотра счетов указанного рекламодателя по указанному контракту показаны отношения между таблицами на рис. П.2.5.:
Рис. П.2.5. Схема, описывающая связь таблиц Рекламодатель-Контракт-Счет
Для просмотра счетов, соответствующих контрактам на определенные позиции радиорекламы показаны следующие отношения:
Рис. П.2.6. Схема, описывающая связь таблиц Наименование рекламных услуг - Радиореклама - Контракт-Счет
Для просмотра сведений (счетов и контрактов) рекламного агента показаны следующие отношения:
Рис. П.2.7. Схема, описывающая связь таблиц Продавец - Контракт - Счет
На основе физической модели выполнено описание структуры таблиц базы данных.
В таблицах 1 - 6 представлено описание структуры таблиц
.Таблица 1
Cчет Зависимая
|
Заголовок поля |
Идентификатор поля |
Ключ |
Тип поля |
Длина |
|
|
1 |
Код услуги |
Код услуги |
FK |
Numeric |
3 |
|
2 |
Номер счета |
Номер счета |
PK |
Numeric |
3 |
|
3 |
Код контракта |
Код контракта |
FK |
Numeric |
3 |
|
4 |
Код рекламодателя |
Код рекламодателя |
FK |
Numeric |
3 |
|
5 |
Код радиорекламы |
Код радиорекламы |
FK |
Numeric |
3 |
|
6 |
Код продавца |
Код продавца |
FK |
Numeric |
3 |
|
7 |
Дата выписки |
Дата выписки |
Date |
8 |
|
|
8 |
Cумма |
Cумма |
Numeric |
5 |
|
|
9 |
Налог на рекламу |
Налог на рекламу |
Numeric |
6.2 |
|
|
10 |
НДС |
НДС |
Numeric |
6.2 |
Таблица 2
Контракт Зависимая
|
Заголовок поля |
Идентификатор поля |
Ключ |
Тип поля |
Длина |
||||||
|
1 |
Код контракта |
Код контракта |
PK |
Numeric |
3 |
|||||
|
2 |
Код радиорекламы |
Код радиорекламы |
FK |
Numeric |
3 |
|||||
|
3 |
Код продавца |
Код продавца |
FK |
Numeric |
3 |
|||||
|
4 |
Код услуги |
Код услуги |
FK |
Numeric |
3 |
|||||
|
5 |
Код рекламодателя |
Код рекламодателя |
FK |
Numeric |
3 |
|||||
Таблица 3
Наименование рекламных услуг
Независимая
|
Заголовок поля |
Идентификатор поля |
Ключ |
Тип поля |
Длина |
|
|
1 |
Код услуги |
Код услуги |
PK |
Numeric |
3 |
|
2 |
Наименование услуги |
Наименование услуги |
Character |
15 |
|
|
3 |
Рекламное время за сутки |
Рекламное время за сутки |
Numeric |
2 |
|
|
4 |
Оплата за сутки |
Оплата за сутки |
Numeric |
4 |
Таблица 4
Продавец
Независимая|
Заголовок поля |
Идентификатор поля |
Ключ |
Тип поля |
Длина |
|
|
1 |
Код продавца |
Код продавца |
PK |
Numeric |
2 |
|
2 |
Фамилия/2 |
Фамилия |
Character |
10 |
|
|
3 |
Имя/2 |
Имя |
Character |
10 |
|
|
4 |
Отчество/2 |
Отчество |
Character |
10 |
|
|
5 |
Наименование продавца |
Наименование продавца |
Character |
15 |
|
|
6 |
Адрес продавца |
Адрес продавца |
Character |
30 |
|
|
7 |
Контактный телефон |
Контактный телефон |
Numeric |
10 |
Таблица 5
Радиореклама Зависимая
|
Заголовок поля |
Идентификатор поля |
Ключ |
Тип поля |
Длина |
||
|
1 |
Код радиорекламы |
Код радиорекламы |
PK |
Numeric |
3 |
|
|
2 |
Код услуги |
Код услуги |
FK |
Numeric |
3 |
|
|
3 |
Дата начала выхода |
Дата начала выхода |
Date |
8 |
||
|
4 |
Дата окончания выхода |
Дата окончания выхода |
Date |
8 |
||
|
5 |
Начало эфира |
Начало эфира |
Numeric |
10 |
||
|
6 |
Окончание эфира |
Окончание эфира |
Numeric |
10 |
||
|
7 |
Продолжительность |
Продолжительность |
Numeric |
10 |
||
|
8 |
Общее количество |
Общее количество |
Numeric |
10 |
||
|
9 |
День недели выхода |
День недели выхода |
Numeric |
10 |
||
|
10 |
Цена |
Цена |
Numeric |
3 |
||
|
11 |
Выполнение |
Выполнение |
Character |
10 |
||
Таблица 6
Рекламодатель Независимая
|
Заголовок поля |
Идентификатор поля |
Ключ |
Тип поля |
Длина |
||
|
1 |
Код рекламодателя |
Код рекламодателя |
PK |
Numeric |
3 |
|
|
|
окончание табл. 6 |
|||||
|
Заголовок поля |
Идентификатор поля |
Ключ |
Тип поля |
Длина |
||
|
2 |
Наименование рекламодателя |
Наименование рекламодателя |
Character |
25 |
||
|
3 |
Признак юридич лица |
Признак юридич лица |
Character |
5 |
||
|
4 |
Адрес |
Адрес |
Character |
30 |
||
|
5 |
Телефон |
Телефон |
Numeric |
15 |
||
|
6 |
Факс |
Факс |
Numeric |
15 |
||
|
7 |
Электронный адрес |
Электронный адрес |
Character |
20 |
||
|
8 |
Должность |
Должность |
Character |
15 |
||
|
9 |
Фамилия |
Фамилия |
Character |
10 |
||
|
10 |
Имя |
Имя |
Character |
10 |
||
|
11 |
Отчество |
Отчество |
Character |
10 |
||
|
12 |
Расчетный счет |
Расчетный счет |
Numeric |
15 |
||
|
13 |
Банк |
Банк |
Numeric |
10 |
||
|
14 |
Корр счет |
Корр счет |
Numeric |
15 |
||
|
15 |
Банк 2 |
Банк 2 |
Numeric |
10 |
||
|
16 |
ОКПО |
ОКПО |
Numeric |
10 |
||
|
17 |
ОКОНХ |
ОКОНХ |
Numeric |
15 |
||
|
18 |
ИНН |
ИНН |
Numeric |
15 |
||
|
19 |
Примечания |
Примечания |
Character |
20 |
||
. Описание запросов к базе данных
Здесь приведены примеры реализации некоторых запросов, перечисленных в описании постановки задачи. Все запросы генерируются в среде
FoxPro.3.1.
Посчитать количество клиентов по указанной формы собственности.SELECT Count(Рекламодатель.[Признак юридического лица]) AS [Count_Признак юридического лица]
FROM Рекламодатель
HAVING (((Рекламодатель.[Признак юридического лица])=[Укажите форму собственности:]));
3.2.
Показать список рекламодателей указанной формы собственности, заключивших контракты .SELECT DISTINCTROW Рекламодатель.[Код рекламодателя], Рекламодатель.[Наименование рекламодателя], Рекламодатель.[Признак юридического лица], Рекламодатель.Адрес, Рекламодатель.Телефон, Рекламодатель.[Электронный адрес]
FROM Рекламодатель INNER JOIN Контракт ON Рекламодатель.[Код рекламодателя] = Контракт.[Код рекламодателя]
WHERE (((Рекламодатель.[Признак юридического лица])=[Укажите форму собственности:]));
3.3.
Список контрактов, заключенных каждым продавцом .
SELECT DISTINCTROW Продавец.[Код продавца], Продавец.[Фамилия продавца], Продавец.[Наименование продавца], Продавец.Имя, Продавец.Отчество, Контракт.[Код контракта], Рекламодатель.[Наименование рекламодателя], Счет.[Номер счета]
FROM Рекламодатель INNER JOIN (Продавец INNER JOIN (Контракт INNER JOIN [Счет] ON Контракт.[Код контракта] = Счет.[Код контракта]) ON Продавец.[Код продавца] = Контракт.[Код продавца]) ON Рекламодатель.[Код рекламодателя] = Контракт.[Код рекламодателя]
GROUP BY Продавец.[Код продавца], Продавец.[Фамилия продавца], Продавец.[Наименование продавца], Продавец.Имя, Продавец.Отчество, Контракт.[Код контракта], Рекламодатель.[Наименование рекламодателя], Счет.[Номер счета];
SELECT DISTINCTROW Продавец.[Фамилия продавца], Продавец.Имя, Продавец.Отчество, Контракт.[Код контракта], Sum(Счет.Сумма) AS [Sum _ Сумма]
FROM Продавец INNER JOIN (Контракт INNER JOIN [Счет] ON Контракт.[Код контракта] = Счет.[Код контракта]) ON Продавец.[Код продавца] = Контракт.[Код продавца]
GROUP BY Продавец.[Фамилия продавца], Продавец.Имя, Продавец.Отчество, Контракт.[Код контракта];
Далее приведены только 3 примера практической реализации отчетов.
Рис. П. 2.8. Структура отчета “Список рекламодателей, счета которых находятся в указанном банке”
На рис. П.2.8 приведена схема размещения полей отчета. Полностью настройку отчета можно посмотреть в среде
Access.Отчет составляется на базе запроса, текст запроса приведен ниже:
SELECT Рекламодатель.[Код рекламодателя], Рекламодатель.[Наименование рекламодателя], Рекламодатель.[Признак юридического лица], Рекламодатель.Адрес, Рекламодатель.Телефон, Рекламодатель.Факс, Рекламодатель.[Электронный адрес], Рекламодатель.Должность, Рекламодатель.Фамилия, Рекламодатель.Имя, Рекламодатель.Отчество, Рекламодатель.[Расчетный счет], Рекламодатель.Банк, Рекламодатель.[Корр счет], Рекламодатель.Банк2, Рекламодатель.ОКПО, Рекламодатель.ОКОНХ, Рекламодатель.ИНН, Рекламодатель.Примечания
FROM Рекламодатель;
Отчет формируется по запросу, текст которого приведен ниже:
SELECT DISTINCTROW Продавец.[Фамилия продавца], Продавец.Имя, Продавец.Отчество, Контракт.[Код контракта], Sum(Счет.Сумма) AS [Sum _ Сумма]
FROM Продавец INNER JOIN (Контракт INNER JOIN [Счет] ON Контракт.[Код контракта] = Счет.[Код контракта]) ON Продавец.[Код продавца] = Контракт.[Код продавца]
GROUP BY Продавец.[Фамилия продавца], Продавец.Имя, Продавец.Отчество, Контракт.[Код контракта];.
На рис.П.2.9 показана схема отчета.
Рис. П.2.9. Схема отчета “Список контрактов, заключенных каждым продавцом”
Отчет формируется по запросу, текст которого приведен ниже
:SELECT DISTINCTROW Рекламодатель.[Код рекламодателя], Рекламодатель.Фамилия, Рекламодатель.[Признак юридического лица], Рекламодатель.[Электронный адрес], Count(*) AS [Count _ Контракт]
FROM Рекламодатель INNER JOIN Контракт ON Рекламодатель.[Код рекламодателя] = Контракт.[Код рекламодателя]
GROUP BY Рекламодатель.[Код рекламодателя], Рекламодатель.Фамилия, Рекламодатель.[Признак юридического лица], Рекламодатель.[Электронный адрес]
HAVING (((Count(*))>1));
На рис. П.2.10 показана схема отчета
Рис. П.2.10. Схема отчета “Список рекламодателей, заключивших более 1 контракта”
Приведено в каталоге с примером
.На рис. П.2.12. приведен пример экранной формы.
Рис. П.2.12. Экранная форма для ввода и просмотра данных о рекламодателях