Приложение 2

Пример 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.1. Концептуальная модель

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

· журнал операций (сделок);

· справочник операций;

· эмитент;

· доллар;

· акция (справочник типов ценных бумаг);

· рынок.

Информацию из отчета трейдера портфельный менеджер заносит в “Журнал операций ”, где код операции обозначается “+” или “- ”. Для расшифровки необходима сущность “Справочник операций”. В сущности “Эмитент” хранится информация об эмитентах, с ценными бумагами которых работает портфельный менеджер. В этой сущности тип акции обозначается “о” / “п” (общая, привилегированная). Для расшифровки нужна сущность “Акция”.

В Российской Торговой Системе (РТС) цена акции устанавливается в долларах США ($). Для составления отчетов портфельного менеджера необходимо переводить цену в рубли. Для перевода необходима сущность “Доллар”, в которой содержится обменный курс доллара (руб/ $) на определенную дату. Для отслеживания состояния портфеля необходимо проводить переоценку финансовых активов, содержащихся в нем, каждый день (рабочий). Для этого отслеживают рынок ценных бумаг, т.е. информацию о результатах торгов в РТС вносят в сущность “Рынок”.

На рис. 2 показана концептуальная информационная модель предметной области.

Рис. П.2.2. Концептуальная информационная модель предметной области

 

2.2. Логическая модель

На основе анализа концептуальной модели выполнена диаграмма отношения сущностей (ERD) по стандарту IDEF1X, показанная на рис. П.2.3. В диаграмме появилась сущность “Остаток на конец дня”, необходимая для составления отчетов.

Рис. П.2.3. Диаграмма отношения сущностей

 

2.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")

 

4. Описание отчетов

Перечень отчетов, подробное описание которых приведено далее:

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):

(1)

где - прибыль (убыток)капитала за i-тый день торгов;

- остаток капитала на конец i- того дня;

- начальный остаток капитала на i-тый день торгов;

Дневная текущая доходность рассчитывается по формуле (2):

, (2)

где - дневная доходность, % в год;

- день торгов (=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. Описание постановки задачи. Описание бизнес-

процессов.

Наименование фирмы: радиостанция “Неро”.

Наименование предметной области : работа отдела маркетинга и рекламы (продажа рекламы на радио), учет работы с клиентами.

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

Точка зрения: руководитель отдела маркетинга.

Перечень процессов, которые будут далее рассмотрены подробнее:

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

Перечень выявленных бизнес - процессов:

На рис. П.2.1 показана упрощенная схема взаимосвязи бизнес - компонент с информационными потоками.

 

Рис. П.2.1. Основные компоненты бизнес - системы и информации.

Описание регламента для некоторых процессов:

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

Уточнение правил выполнения бизнес-процессов для предметной области:

Перечень выявленных сущностей:

  1. Рекламодатель
  2. Наименование рекламных услуг
  3. Радиореклама
  4. Контракт
  5. Продавец (рекламный агент)
  6. Счет

Перечень возможных запросов к базе данных:

Перечень возможных отчетов:

1. Список рекламодателей (по формам собственности, по количеству контрактов и т.д.)

2. Перечень контрактов, заключенных каждым продавцом.

 

2. Информационная модель данных

На рис. П.2.2 представлена концептуальная модель данных.

Рис. П.2.2. Информационная модель предметной области.

 

2.1. Логическая модель

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

Рис. П.2.3. Диаграмма отношения сущностей (ERD)

 

2.2. Физическая модель

На рис. П.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

 

 

3. Описание запросов к базе данных

Здесь приведены примеры реализации некоторых запросов, перечисленных в описании постановки задачи. Все запросы генерируются в среде 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 Продавец.[Код продавца], Продавец.[Фамилия продавца], Продавец.[Наименование продавца], Продавец.Имя, Продавец.Отчество, Контракт.[Код контракта], Рекламодатель.[Наименование рекламодателя], Счет.[Номер счета];

  1. Сумма контрактов, заключенных каждым продавцом .

SELECT DISTINCTROW Продавец.[Фамилия продавца], Продавец.Имя, Продавец.Отчество, Контракт.[Код контракта], Sum(Счет.Сумма) AS [Sum _ Сумма]

FROM Продавец INNER JOIN (Контракт INNER JOIN [Счет] ON Контракт.[Код контракта] = Счет.[Код контракта]) ON Продавец.[Код продавца] = Контракт.[Код продавца]

GROUP BY Продавец.[Фамилия продавца], Продавец.Имя, Продавец.Отчество, Контракт.[Код контракта];

 

4. Описание отчетов

Далее приведены только 3 примера практической реализации отчетов.

  1. Список рекламодателей, счета которых находятся в указанном банке.

 

Рис. П. 2.8. Структура отчета “Список рекламодателей, счета которых находятся в указанном банке”

На рис. П.2.8 приведена схема размещения полей отчета. Полностью настройку отчета можно посмотреть в среде Access.

Отчет составляется на базе запроса, текст запроса приведен ниже:

SELECT Рекламодатель.[Код рекламодателя], Рекламодатель.[Наименование рекламодателя], Рекламодатель.[Признак юридического лица], Рекламодатель.Адрес, Рекламодатель.Телефон, Рекламодатель.Факс, Рекламодатель.[Электронный адрес], Рекламодатель.Должность, Рекламодатель.Фамилия, Рекламодатель.Имя, Рекламодатель.Отчество, Рекламодатель.[Расчетный счет], Рекламодатель.Банк, Рекламодатель.[Корр счет], Рекламодатель.Банк2, Рекламодатель.ОКПО, Рекламодатель.ОКОНХ, Рекламодатель.ИНН, Рекламодатель.Примечания

FROM Рекламодатель;

  1. Список контрактов, заключенных каждым продавцом

 

Отчет формируется по запросу, текст которого приведен ниже:

SELECT DISTINCTROW Продавец.[Фамилия продавца], Продавец.Имя, Продавец.Отчество, Контракт.[Код контракта], Sum(Счет.Сумма) AS [Sum _ Сумма]

FROM Продавец INNER JOIN (Контракт INNER JOIN [Счет] ON Контракт.[Код контракта] = Счет.[Код контракта]) ON Продавец.[Код продавца] = Контракт.[Код продавца]

GROUP BY Продавец.[Фамилия продавца], Продавец.Имя, Продавец.Отчество, Контракт.[Код контракта];.

На рис.П.2.9 показана схема отчета.

 

Рис. П.2.9. Схема отчета “Список контрактов, заключенных каждым продавцом”

  1. Список рекламодателей, заключивших более 1 контракта

Отчет формируется по запросу, текст которого приведен ниже:

SELECT DISTINCTROW Рекламодатель.[Код рекламодателя], Рекламодатель.Фамилия, Рекламодатель.[Признак юридического лица], Рекламодатель.[Электронный адрес], Count(*) AS [Count _ Контракт]

FROM Рекламодатель INNER JOIN Контракт ON Рекламодатель.[Код рекламодателя] = Контракт.[Код рекламодателя]

GROUP BY Рекламодатель.[Код рекламодателя], Рекламодатель.Фамилия, Рекламодатель.[Признак юридического лица], Рекламодатель.[Электронный адрес]

HAVING (((Count(*))>1));

 

На рис. П.2.10 показана схема отчета

 

Рис. П.2.10. Схема отчета “Список рекламодателей, заключивших более 1 контракта”

 

6. Описание экранных форм

Приведено в каталоге с примером.

На рис. П.2.12. приведен пример экранной формы.

 

Рис. П.2.12. Экранная форма для ввода и просмотра данных о рекламодателях