Для определения поставщика определенного товара выдать список поставщиков товаров группы «Мясо/птица» и данные для взаимодействия.

Решение

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

 Исходя из результатов анализа информационной потребности, определяем состав и структуру требуемого сообщения S(Список поставщиков определенного товара на примере поставщиков товаров группы «Мясо/птица» и их данных для взаимодействия)

S(Поставщики.Название, Поставщики.Адрес, Поставщики.Город, Поставщики.Область, Поставщики.Индекс, Поставщики.Страна, Поставщики.Телефон, Поставщики.Факс, Поставщики.ОсновнаяСтраница, Типы.Категория).

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

На выходе процесса представлено сообщение с определенной в предыдущем пункте структурой.

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

С позиций потребителя-пользователя запрос можно охарактеризовать как простой с поэтапным потреблением информации. Для работы с данными результирующая таблица может быть экспортирована в Excel. При реализации в Access данный запрос может быть запросом на выборку. При ведении истории запрос является хранимой процедурой. Он исполняется по мере возникновения потребности в информации в определенной динамике.

 В процессе решения задачи с использованием SQL-проекта NorthwindCS применяется двухуровневая архитектура «клиент/сервер», вариант реализации технологии «клиент/сервер» DBS. В процессе решения задачи с использованием *.mdb-файла применяется RDA-вариант реализации технологии «клиент/сервер».

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

Таблица Типы  имеет простой ключ «КодТипа», таблица Поставщики – простой ключ «КодПоставщика», а таблица Товары – простой ключ «КодТовара».  Таблицы Типы и Поставщики являются главными по отношению к таблице Товары.  Тип связи «один-ко-многим». Связь по полю «КодТипа» и по полю «КодПоставщика» (ключи связи). Целостность по значениям определяется отсутствием в таблице Товары значений поля «КодТипа», которых нет в таблице Типы и  отсутствием значений поля «КодПоставщика», которых нет в таблице Поставщики. Значения поля «КодТипа» и «КодПоставщика» в таблице Товары обновляются автоматически при изменении соответственно значений поля «КодТипа» в таблице Типы и значений поля «КодПоставщика» в таблице Поставщики.

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

Таблица Товары (фрагмент):

Таблица Поставщики (фрагмент):

Таблица Типы (фрагмент):

Результат выполнения реляционной операции произведения (фрагмент):

Результат выполнения реляционной операции соединения – сцепления строк с совпадающими значениями поля «Код Поставщика» и «Код Типа» (фрагмент):

Результат выполнения операции селекции – выбора строк по принадлежности значений поля «Категория»  - введенному нами значению «Мясо/птица»:

Результат выполнения операции проекции (фрагмент):

Полный вариант запроса на выборку поставщиков определенного товара на примере поставщиков товаров группы «Мясо/птица» и данных для взаимодействия.

SELECT DISTINCT Поставщики.Название, Поставщики.Адрес, Поставщики.Город, Поставщики.Область, Поставщики.Индекс, Поставщики.Страна, Поставщики.Телефон, Поставщики.Факс, Поставщики.ОсновнаяСтраница, Типы.Категория

FROM Типы INNER JOIN (Поставщики INNER JOIN Товары ON Поставщики.КодПоставщика = Товары.КодПоставщика) ON Типы.КодТипа = Товары.КодТипа

WHERE (((Типы.Категория)=[Наименование Товара]));

Задача 1.2

Выдать названия клиентов с заказами на октябрь текущего года, их адреса, сведения о месте нахождения.

Решение

    Реквизит «Название клиента» является обязательным по условию задачи, остальные реквизиты используются в процедурах профилизации, сегментации и связи. Адрес в Интернете отсутствует по причине отсутствия соответствующего поля в схеме данных. Сведения о заказах отсутствуют, поскольку запрос на получение соответствующего сообщения уже имеется в составе объектов и в нем содержатся сведения о клиентах. Исходя из результатов анализа информационной потребности, определяем состав и структуру требуемого сообщения S_( Клиенты с заказами на октябрь текущего года, их адреса, местонахождение)

S_(Клиенты.КодКлиента, Клиенты.Название, Клиенты.Адрес, Клиенты.Город, Клиенты.Область, Клиенты.Индекс, Клиенты.Страна, Клиенты.Телефон, Клиенты.Факс, Заказы.ДатаНазначения).

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

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

На выходе процесса представлено сообщение с определенной в предыдущем пункте структурой.

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

С позиций потребителя-пользователя запрос можно охарактеризовать как простой с поэтапным потреблением информации. Для работы с данными результирующая таблица может быть экспортирована в Excel. При реализации в Access данный запрос может быть запросом на выборку. При ведении истории запрос является хранимой процедурой. Он исполняется по мере возникновения потребности в информации в определенной динамике.

 В процессе решения задачи с использованием SQL-проекта NorthwindCS применяется двухуровневая архитектура «клиент/сервер», вариант реализации технологии «клиент/сервер» DBS. В процессе решения задачи с использованием *.mdb-файла применяется RDA-вариант реализации технологии «клиент/сервер».

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

Таблица Заказы имеет простой ключ «КодЗаказа», таблица Клиенты – простой ключ «КодКлиента». Таблица Клиенты является главной, Заказы – подчиненной. Тип связи «один-ко-многим». Связь по полю «КодКлиента» (ключ связи). Целостность по значениям определяется отсутствием в таблице Заказы значений поля «КодКлиента», которых нет в таблице Клиенты. Значения поля «КодКлиента» в таблице Заказы обновляются автоматически при изменении значений поля «КодКлиента» в таблице Клиенты.

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

Таблица Заказы (фрагмент):

Таблица Клиенты (фрагмент):

Результат выполнения реляционной операции произведения (фрагмент):

Результат выполнения реляционной операции соединения – сцепления строк с совпадающими значениями поля «Код Клиента» (фрагмент):

Результат выполнения операции селекции – выбора строк по принадлежности значений поля «ДатаНазначения»  интервалу от 01.10.2004 до 31.10.2004 включительно (фрагмент):

Результат выполнения операции проекции (фрагмент):

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

SELECT Клиенты.КодКлиента, Клиенты.Название, Клиенты.ОбращатьсяК, Клиенты.Должность, Клиенты.Адрес, Клиенты.Город, Клиенты.Область, Клиенты.Индекс, Клиенты.Страна, Клиенты.Телефон, Клиенты.Факс, Заказы.ДатаНазначения

FROM Клиенты INNER JOIN Заказы ON Клиенты.КодКлиента=Заказы.КодКлиента

WHERE ((Заказы.ДатаНазначения) Between #10/1/2004# And #10/31/2004#);

Задача 5.5

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

Решение:

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

S([Основные фонды].КодОсновныхФондов, [Основные фонды].ОписаниеОсновныхФондов, [Основные фонды].НомерМодели, [Основные фонды].СерийныйНомер, [Основные фонды].[Штрих-код], [Основные фонды].ДатаПриобретения, [Основные фонды].ЦенаПокупки, [Основные фонды].СрокАмортизации, [Основные фонды].СуммаСтраховки, [Типы фондов].ТипОсновныхФондов).

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

На выходе процесса представлено сообщение с определенной в предыдущем пункте структурой.

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

С позиций потребителя-пользователя запрос можно охарактеризовать как простой с поэтапным потреблением информации. Для работы с данными результирующая таблица может быть экспортирована в Excel. При реализации в Access данный запрос может быть запросом на выборку. При ведении истории запрос является хранимой процедурой. Он исполняется по мере возникновения потребности в информации в определенной динамике.

 В процессе решения задачи с использованием SQL-проекта NorthwindCS применяется двухуровневая архитектура «клиент/сервер», вариант реализации технологии «клиент/сервер» DBS. В процессе решения задачи с использованием *.mdb-файла применяется RDA-вариант реализации технологии «клиент/сервер».

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

Таблица Типы фондов  имеет простой ключ «КодТипаОсновныхФондов», таблица Основные фонды – простой ключ «КодОсновныхФондов».  Таблица Типы фондов является главной, а таблица Основные фонды – подчиненной.  Тип связи «один-ко-многим». Связь по полю «КодТипаОсновныхФондов» (ключ связи). Целостность по значениям определяется отсутствием в таблице Основные фонды значений поля «КодТипаОсновныхФондов», которых нет в таблице Типы фондов. Значения поля «КодТипаОсновныхФондов» в таблице Основные фонды обновляются автоматически при изменении соответственно значений поля «КодТипаОсновныхФондов» в таблице Типы фондов.

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

Таблица Типы фондов (фрагмент):

Таблица Основные фонды (фрагмент):

Результат выполнения реляционной операции произведения (фрагмент):

Результат выполнения реляционной операции соединения – сцепления строк с совпадающими значениями поля                                   «Код Типа Основных Фондов» (фрагмент):

Результат выполнения операции селекции – выбора строк по принадлежности значений поля «Тип Основных Фондов» значению «Компьютер» и поля «Сумма Страховки» - значению 0,00р. :

Результат выполнения операции проекции (фрагмент):

Полный вариант запроса на выборку сведений о незастрахованных компьютерах.

SELECT [Основные фонды].КодОсновныхФондов, [Основные фонды].ОписаниеОсновныхФондов, [Основные фонды].НомерМодели, [Основные фонды].СерийныйНомер, [Основные фонды].[Штрих-код], [Основные фонды].ДатаПриобретения, [Основные фонды].ЦенаПокупки, [Основные фонды].СрокАмортизации, [Основные фонды].СуммаСтраховки, [Типы фондов].ТипОсновныхФондов

FROM [Типы фондов] RIGHT JOIN [Основные фонды] ON [Типы фондов].КодТипаОсновныхФондов = [Основные фонды].КодТипаОсновныхФондов

WHERE ((([Основные фонды].СуммаСтраховки)=0) AND (([Типы фондов].ТипОсновныхФондов)="Компьютер"));

Задача 4.5

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

Решение

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

S(Затраты.КодЗатрат, Затраты.ОписаниеЗатрат, Проекты.НазваниеПроекта, Партнеры.Страна, Проекты.ОценочнаяСтоимость, Проекты.ДатаНачалаПроекта, Проекты.ДатаЗавершенияПроекта).

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

На выходе процесса представлено сообщение с определенной в предыдущем пункте структурой.

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

С позиций потребителя-пользователя запрос можно охарактеризовать как простой с поэтапным потреблением информации. Для работы с данными результирующая таблица может быть экспортирована в Excel. При реализации в Access данный запрос может быть запросом на выборку. При ведении истории запрос является хранимой процедурой. Он исполняется по мере возникновения потребности в информации в определенной динамике.

 В процессе решения задачи с использованием SQL-проекта NorthwindCS применяется двухуровневая архитектура «клиент/сервер», вариант реализации технологии «клиент/сервер» DBS. В процессе решения задачи с использованием *.mdb-файла применяется RDA-вариант реализации технологии «клиент/сервер».

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

Таблица Партнеры  имеет простой ключ «КодКлиента», таблица Проекты – простой ключ «КодПроекта», а таблица Затраты – простой ключ «КодЗатрат».  Таблица Партнеры является главной по отношению к таблице Проекты, а таблица Проекты является главной по отношению к таблице Затраты.  Тип связи «один-ко-многим». Связь по полю «КодКлиента» и по полю «КодПроекта» (ключи связи). Целостность по значениям определяется отсутствием в таблице Проекты значений поля «КодКлиента», которых нет в таблице Партнеры и отсутствием значений поля «КодПроекта» в таблице Затраты, которых нет в таблице Проекты. Значения поля «КодКлиента» в таблице Проекты обновляются автоматически при изменении соответственно значений поля «КодКлиента» в таблице Партнеры и значения поля «КодПроекта» в таблице Заказы обновляются автоматически при изменении соответственно значений поля «КодПроекта» в таблице Проекты.

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

Таблица Проекты (фрагмент):

Таблица Заказы (фрагмент):

Таблица Партнеры (фрагмент):

Результат выполнения реляционной операции произведения (фрагмент):

Результат выполнения реляционной операции соединения – сцепления строк с совпадающими значениями поля «Код Клиента» и «Код Проекта» (фрагмент):

Результат выполнения операции селекции – выбора строк по принадлежности значений поля «Страна»  значению «Германия» и значений поля «Дата завершения проекта» - значению большему, чем значение текущей даты, возвращаемой выражением Date():

Результат выполнения операции проекции (фрагмент):

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

SELECT Затраты.КодЗатрат, Затраты.ОписаниеЗатрат, Проекты.НазваниеПроекта, Партнеры.Страна, Проекты.ОценочнаяСтоимость, Проекты.ДатаНачалаПроекта, Проекты.ДатаЗавершенияПроекта

FROM (Партнеры INNER JOIN Проекты ON Партнеры.КодКлиента = Проекты.КодКлиента) INNER JOIN Затраты ON Проекты.КодПроекта = Затраты.КодПроекта

WHERE (((Партнеры.Страна)="Германия") AND ((Проекты.ДатаЗавершенияПроекта)>Date()));

Задача 6.6

Сравнить данные о продажах по бумагам. По какой бумаге объем продаж максимален?

Решение

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

S([Заявки на продажу].КодБум, Бумаги.НаимБум, Sum([Заявки на продажу].[Объем заявкиПрНач]) AS [Sum-Объем заявкиПрНач]).

Определяем состав полей и таблиц, используемых в запросе из схемы № 6 (база данных Бумаги). Представляем в графическом виде обобщенную функционально-технологическую схему задачи (рис.5).

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

На выходе процесса представлено сообщение с определенной в предыдущем пункте структурой.

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

С позиций потребителя-пользователя запрос можно охарактеризовать как простой с поэтапным потреблением информации. Для работы с данными результирующая таблица может быть экспортирована в Excel. При реализации в Access данный запрос может быть запросом на выборку. При ведении истории запрос является хранимой процедурой. Он исполняется по мере возникновения потребности в информации в определенной динамике.

 В процессе решения задачи с использованием SQL-проекта NorthwindCS применяется двухуровневая архитектура «клиент/сервер», вариант реализации технологии «клиент/сервер» DBS. В процессе решения задачи с использованием *.mdb-файла применяется RDA-вариант реализации технологии «клиент/сервер».

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

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

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

Таблица Бумаги (фрагмент):

Таблица Типы (фрагмент):

Результат выполнения реляционной операции произведения (фрагмент):

Результат выполнения реляционной операции соединения – сцепления строк с совпадающими значениями поля «Код Бумаги» (фрагмент):

Результат выполнения операций группировки и суммирования по полю «Объем заявки» для каждой отдельной бумаги и последующего выполнения операции TOP 1 – выбора первой строки из списка, отсортированного по убыванию (с помощью операции DESC) поля «Sum-Объем заявкиПрНач» (суммарное значение объема для каждой бумаги по заявкам на продажу), т.е. выбор максимального суммарного значения:

Результат выполнения операции проекции (фрагмент):

Полный вариант запроса на выборку бумаги, по которой объем продаж максимален.

SELECT DISTINCTROW TOP 1  Бумаги.НаимБум, Sum([Заявки на продажу].[Объем заявкиПрНач]) AS [Sum-Объем заявкиПрНач]

FROM Бумаги INNER JOIN [Заявки на продажу] ON Бумаги.КодБум = [Заявки на продажу].КодБум

GROUP BY [Заявки на продажу].КодБум, Бумаги.НаимБум

ORDER BY Sum([Заявки на продажу].[Объем заявкиПрНач]) DESC;

Список литературы

1.     Информационные системы в экономике / Под ред. В.Дика. – М.: Финансы и статистика,1996. -272 с.

2.     Информатика: Учебник / Под ред. проф. Н.В. Макаровой. – М.: Финансы и статистика, 1998. – 768 с.

3.     Карпова Т. Базы данных: модели, разработка, реализация. – СПб.: Питер, 2001. – 304 с.

4.     Острейковский В. А. Информатика. -  М.: Высшая школа, 1999. – 510 с.

5.     Робинсон С. Microsoft Access 2000. – СПб.: Питер, 2001. – 512