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

ЛИЧНЫЙ КАБИНЕТ 

 

Здравствуйте гость!

 

Логин:

Пароль:

 

Запомнить

 

 

Забыли пароль? Регистрация

Повышение уникальности

Предлагаем нашим посетителям воспользоваться бесплатным программным обеспечением «StudentHelp», которое позволит вам всего за несколько минут, выполнить повышение уникальности любого файла в формате MS Word. После такого повышения уникальности, ваша работа легко пройдете проверку в системах антиплагиат вуз, antiplagiat.ru, etxt.ru или advego.ru. Программа «StudentHelp» работает по уникальной технологии и при повышении уникальности не вставляет в текст скрытых символов, и даже если препод скопирует текст в блокнот – не увидит ни каких отличий от текста в Word файле.

Результат поиска


Наименование:


курсовая работа Иерархическая модель данных. Предметная область «Склад продовольственных товаров»

Информация:

Тип работы: курсовая работа. Добавлен: 13.12.2012. Сдан: 2012. Страниц: 25. Уникальность по antiplagiat.ru: < 30%

Описание (план):


?Государственное учреждение высшего профессионального образования
«БЕЛОРУССКО-РОССИЙСКИЙ УНИВЕРСИТЕТ»
 
Кафедра «Экономическая информатика»
 
 
 
Пояснительная записка
к курсовой работе по дисциплине
«Технология организации хранения и обработки данных» на тему:
Иерархическая модель данных. Предметная область «Склад продовольственных товаров»
 
 
 
 
 
Выполнил ст. гр. ЭУПЗС-092
Татьянин А.В.
Шифр 091663
 
Руководитель: Пичугова О.А.
 
 
 
 
 
 
 
 
 
 
Могилев 2010
 
Содержание
Введение              3
Содержание              4
1 Сетевая модель данных.              5
2 Постановка задачи на разработку базы данных              7
2.1 Анализ предметной области              7
2.2 Требования к информационной системе              7
3 Проектирование модели данных              9
3.1 Семантическая модель данных              9
3.2 Логическая модель данных              11
3.3 Определение физических характеристик атрибутов
4 Реализация системы
4.1 Создание, связывание и заполнение таблиц
4.2 Реализация запросов к базе данных
4.3 Создание отчетов
4.4 Создание форм
Заключение              28
Список использованных источников              29
Приложение А
Приложение Б

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Введение
 
База данных (БД) - это  поименованная  совокупность  структурированных данных, относящихся к определенной предметной области.
Согласно данной концепции основой информационной  технологии  являются данные, организованные в БД, адекватно отражающие реалии действительности  в той или иной предметной области  и  обеспечивающие  пользователя  актуальной информацией в соответствующей предметной области.  Под  предметной  областью принято понимать часть реального мира, подлежащего изучению для  организации управления и в конечном счёте автоматизации, например,  предприятие,  ВУЗ  и т.д.
Сегодня существует множество систем управления базами данных (СУБД), которые основываются  на реляционной модели. Одной из наиболее распространенных и доступных из них является СУБД MS Access, которая будет использоваться в данной работе. Ее итогом   будет база данных по товарам, которые поступают на промышленный склад.
     
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1 Иерархическая модель данных
 
Ядром  любой  базы  данных  является  модель  данных.  Модель   данных представляет собой множество  структур  данных,  ограничений  целостности  и операций  манипулирования  данными.  С  помощью  модели  данных  могут  быть представлены объекты предметной области и взаимосвязи между ними.
Модель данных - совокупность структур данных и операций их обработки.  По способу установления связей  между  данными  СУБД  основывается  на использовании  трёх  основных  видов  модели:  иерархической,  сетевой   или реляционной; на комбинации этих моделей или на некотором их подмножестве.
  Однако  различия  между  этими  моделями  постепенно  стираются,   что обусловлено прежде всего интенсивными работами в области баз знаний  (БЗ)  и объектно-ориентированной инфотехнологией, о которой будет идти речь ниже.
Каждая из указанных моделей обладает  характеристиками,  делающими  ее наиболее удобной для конкретных приложений. Одно из основных  различий  этих моделей состоит в том, что для иерархических и  сетевых  СУБД  их  структура часто не может быть изменена после ввода данных, тогда как  для  реляционных
СУБД структура может  изменяться  в  любое  время.  С  другой  стороны,  для больших БД,  структура  которых  остается  длительное  время  неизменной,  и постоянно работающих с ними приложений с интенсивными потоками  запросов  на БД-обслуживание  именно  иерархические  и  сетевые  СУБД   могут   оказаться наиболее эффективными решениями, ибо они могут  обеспечивать  более  быстрый доступ к информации БД, чем реляционные СУБД.
Остановимся подробнее на сетевой модели данных. На разработку сетевой модели большое влияние оказал американский ученый Ч.Бахман. Основные принципы сетевой модели данных были разработны в середине 60-х годов, эталонный вариант сетевой модели данных описан в отчетах рабочей группы по языкам баз данных (COnference on DAta SYstem Languages) CODASYL (1971 г.). В сетевой структуре при  тех  же  основных  каждый элемент может быть связан с любым другим элементом.
Сетевая  модель  СУБД  во  многом  подобна   иерархической:   если   в
иерархической модели для каждого сегмента  записи  допускается  только  один входной  сегмент  при  N  выходных,  то  в  сетевой  модели  для   сегментов допускается  несколько  входных  сегментов  наряду  с  возможностью  наличия сегментов без входов с точки зрения иерархической структуры.
         Графическое изображение структуры связей сегментов такого типа, котоая представлена на рисунке 1, моделей представляет  собой  сеть.  Сегменты  данных  в  сетевых  БД   могут   иметь множественные связи с сегментами старшего уровня.  При  этом  направление  и характер связи в сетевых БД не  являются  столь  очевидными,  как  в  случае иерархических   БД.   Поэтому   имена   и    направление    связей    должны идентифицироваться при описании БД.   
           
Рисунок 1-Сетевая модель данных
 
      Таким образом, под сетевой  СУБД  понимается  система,  поддерживающая сетевую организацию:  любая  запись,  называемая  записью  старшего  уровня, может  содержать  данные,  которые  относятся  к  набору   других   записей, называемых записями подчиненного уровня. Возможно обращение ко всем  записям в наборе, начиная с записи  старшего  уровня.  Обращение  к  набору  записей реализуется по указателям.
      В рамках сетевых СУБД легко реализуются и иерархические даталогические модели.
      Сетевые СУБД поддерживают сложные соотношения между типами данных, что делает их пригодными во многих различных  приложениях.  Однако  пользователи таких СУБД ограничены связями,  определенными  для  них  разработчиками  БД- приложений.
      Более того, подобно иерархическим сетевые СУБД предполагают разработку БД приложений опытными программистами и системными аналитиками.
      Среди  недостатков  сетевых  СУБД  следует  особо  выделить   проблему
обеспечения  сохранности  информации  в  БД,   решению   которой   уделяется повышенное внимание при проектировании сетевых БД.
 

2 Постановка задачи на разработку базы данных

2.1 Анализ предметной области

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

2.2 Требования к информационной системе

 
С базой данных могут работать следующие группы пользователей:
1 работники склада, принимающие товар;
2 поставщики товаров;
3 администрация склада промышленных товаров;
4 закупщики товаров со склада.
Обращаясь к данной базе данных пользователи могут получить следующую информацию:
1 получить информация о всех поставляемых товарах;
2 получить информации о поставщиках товаров;
3 получить информацию о стоимости товаров;
4 получить информацию о поставке товаров на любое число;
5 получить информацию о количестве поставленных товаров каждым поставщиком;
6 получить информацию о стоимости поставленных товаров каждым из поставщиком;
7 получить информацию о том, по какой товарно-транспортной накладной был поставлен товар;
8 получить информацию о сотруднике, который имеет материальную ответственность за хранение товара;
9 получить информацию о том, к какой товарной группе относится имеющийся на складе товар.
 

 

 

 

 

 

 

 

 

 

 

 

 

 
 

3  Проектирование модели данных

3.1 Семантическая модель данных

 
Разработку модели начнем с выделения основных сущностей и связей между ними. Сущность — это некоторый объект реального мира, который может существовать независимо. Сущность имеет экземпляры, отличающиеся друг от друга значениями атрибутов и допускающие однозначную идентификацию. Атрибут — это поименованная характеристика сущности. В соответствии с анализом предметной области выделяем необходимые сущности и их атрибуты.
Прежде всего необходимо выделить сущность «Товары». Каждый товар, поступивший на склад, имеет уникальный код, который и является ключом cущности, а также обладает рядом атрибутов, которые перечислены в описании предметной области. Каждый товар может поступать от разных поставщиков, в разное время и в разном количестве. Для этого вводится сущность «Накладные. Следовательно, каждый товар, поступающий на склад, имеет свою товарно-транспортную накладную, каждая из которых обладает уникальным номером. Этот уникальный номер накладной и будет ключевым атрибутом сущности «Накладная».
Так как каждый поступающий товар обязательно соответствует определенной товарной группе, то необходимо ввести сущность «Группа товаров». Каждая товарная группа имеет название и свой уникальный код, с помощью которого можно будет ее идентифицировать. Следовательно, этот атрибут и будет являться ключевым для сущности «Группа товаров».
Так как каждый товар поступает от поставщика, необходимо ввести сущность «Поставщики». Каждый поставщик имеет название, контактный телефон и находится в определенном городе. Главным атрибутом данной сущности является наличие у каждого поставщика уникального кода, с помощью которого происходит его идентификация.
Наборы атрибутов отразим в таблице 1, ключевые атрибуты выделим жирным шрифтом.
 
Таблица 1 - Наборы атрибутов сущностей семантической модели
Товары
Ведомости
Группы товаров
Поставщики
Авто
код товара
номер ведомости
код группы
код поставщика
Код автомобиля
Название товара
дата
название группы
название поставщика
Название
Код группы
Код товара
 
город
Гос номер
Страна производитель
Количество
Оптовая стоимость
 
контактный телефон
Водитель
Оптовая цена
ФИО МОЛ
 
УНП
 
Категория
Код поставщика
 
Автомобиль
 
Срок хранения
Автомобиль
 
 
 
 
 
Между сущностями существуют связи. Связь представляет взаимодействие между сущностями. Исходя из этих связей, построим семантическую модель предметной области «Склад продовольственных товаров», которая представлена на рисунке 2.
 
 
 
 
 
 
 
 
 
 
 
Рисунок 2 - Семантическая модель предметной области «Склад  
                     продовольственных товаров»
Между сущностями «Группа товаров» и «Товары» существует связь (1:M), так одна товарная группа может содержать несколько наименований товаров. Связь обязательная с двух сторон, так как каждый товар обязательно соответствует определенной товарной группе и каждая группа содержит определенный перечень товаров.
Между сущностями «Товары» и «Ведомости» также связь (1:М), так как каждый один товар может поставляться на склад в разные дни, в разном количестве, по разной цене, что будет фиксироваться в разных Ведомостях. Связь обязательная с двух сторон. Так как каждый товар обязательно имеет свою ведомость, и в каждой ведомости фиксирует определенный товар.
Между сущностями «Ведомости» и «Поставщики» существует связь (1:М), так как один поставщик может поставлять товары на склад в разные дни, в разном количестве, по разной цене, что будет фиксироваться в разных ведомостях. Связь между сущностями тоже обязательная с двух сторон, так как каждый поставщик поставляет товар по ведомостью (накладной), и в каждой ведомости указывается, кто является поставщиком.

3.2 Логическая модель данных

 
              После того, как мы построили семантическую модель, необходимо ее преобразовать в логическую. Рассмотрим соответствие нашей модели правилам формирования отношений, которые определяют преобразование семантической модели данных в реляционную модель.
Так как в нашей модели присутствуют только связи типа (1:М), необходимо обратиться к следующему правилу:
Правило 4. Если связь типа (1:М) и степень участия сущности на стороне М является обязательной, то необходимо создать две таблицы – по одной для каждой сущности. Первичные ключи таблиц соответствуют первичным ключам сущностей. Для установления связи между ними необходимо добавить в подчиненную таблицу копию ключевого атрибута из главной таблицы, который станет внешним ключом подчиненной таблицы.
В нашем примере данному правилу соответствует связь ГРУППЫ ТОВАРОВ-ТОВАРЫ. Тогда согласно правилу 4 должны быть сгенерированы две таблицы следующей структуры, они представлены на рисунке 3.
 
 
 
 
 
 
 
Рисунок 3- создание связи ГРУППА ТОВАРОВ-ТОВАРЫ
Данному правилу также соответствует связь ТОВАРЫ-НАКЛАДНЫЕ. Преобразовываем таблицы согласно правилу, таблицы представлены на рисунке 4.
 
 
 
 
 
 
 
 
 
Рисунок 4 – создание связи ТОВАРЫ-ВЕДОМОСТИ
Связь ПОСТАВЩИКИ-ВЕДОМОСТИ также соответствует данному правилу. В итоге получаем следующие таблицы, изображенные на рисунке 5.
 
 
 
 
 
 
 
 
Рисунок 5-создание связи ПОСТАВЩИКИ-ВЕДОМОСТИ
Связь АВТО-ПОСТАВЩИКИ-ВЕДОМОСТИ также соответствует данному правилу. В итоге получаем следующие таблицы, изображенные на Рис 6
 
 
 
 
В результате получим реляционную модель для ER-модели предметной области «Склад промышленных товаров», которая изображена на рисунке 7.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
При создании модели БД необходимо предусмотреть минимизацию избыточности данных. В базе данных присутствует избыточность, если одни и те же данные находятся в нескольких местах, в нашей модели такого не наблюдается.
Теперь необходимо проверить полученные отношения на соответствие трем нормальным формам. Реляционная база данных считается эффективной, если все ее таблицы находятся как минимум в 3НФ.
Определение 1НФ: Таблица находится в 1НФ, если все ее поля содержат только неделимые значения. Для созданной нами модели это выполняется, так как нет неделимых значений полей.
Определение 2НФ: Таблица находится в 2НФ, если она удовлетворяет требованиям 1НФ и неключевые поля функционально полно зависят от первичного ключа. Для данной модели это выполняется, так как неключивые поля функционально полно зависят от первичного ключа, то есть каждое поле каждой таблицы зависит только от ключевого поля.
Определение 3НФ: Отношение находится в третьей нормальной форме тогда и только тогда, когда оно находится во второй нормальной форме и не содержит транзитивных зависимостей, то есть зависимостей неключевых атрибутов от неключевых. Для созданной нами модели это выполняется, так как транзитивные зависимости между неключевыми атрибутами нет, то есть неключевые поля не имеют зависимости между собой и зависят только от ключевого поля.
Достижение третьей нормальной формы обычно является достаточным для окончания процесса нормализации отношений. После приведения созданной модели в соответствие рассмотренным правилам мы получили логическую модель данных, которая приведена в Приложении А (в виде схемы данных из СУБД Microsoft Access).

3.3 Определение физических характеристик атрибутов

 
Определяем параметры каждого атрибута построенной нами логической модели базы данных: тип, размер и обязательность заполнения.
Параметры атрибутов для всех таблиц базы данных представлены в таблице 2.
Таблица 2 - Атрибуты таблиц базы данных
Имя атрибута
Тип
Размер
Обязательный
товары
КОД ТОВАРА
Числовой
Длинное целое
Да
НАЗВАНИЕ ТОВАРА
Текстовый
50
Да
КОД ГРУППЫ
Числовой
Длинное целое
Да
СТРАНА-ПРОИЗВОДИТЕЛЬ
Текстовый
Длинное целое
Да
ОПТОВАЯ ЦЕНА ЗА 1 кг(шт)
Денежный
-
Да
КАТЕГРИЯ
Текстовый
50
Да
СРОК ХРАНЕНИЯ
Текстовый
50
Да
ВЕДОМОСТИ
НОМЕР ВЕДОМОСТИ
Числовой
Длинное целое
Да
ДАТА
Дата/время
-
Да
КОД ТОВАРА
Числовой
Длинное целое
Да
КОЛИЧЕСТВО
Числовой
Длинное целое
Да
Имя атрибута
Тип
Размер
Обязательный
ОПТОВАЯ СТОИМОСТЬ
Денежный
-
Да
ФИО МОЛ
Текстовый
15
Да
КОД ПОСТАВЩИКА
Числовой
Длинное целое
Да
КОД АВТОМОБИЛЯ
Числовой
Длинное целое
Да
МАРКА
Текстовый
50
Да
ГРУППЫ ТОВАРОВ
КОД ГРУППЫ
Числовой
Длинное целое
Да
НАЗВАНИЕ ГРУППЫ
Текстовый
40
Да
ПОСТАВЩИКИ
КОД ПОСТАВЩИКА
Числовой
Длинное целое
Да
НАЗВАНИЕ ПОСТАВЩИКА
Текстовый
40
Да
ГОРОД
Текстовый
40
Да
КОНТАКТНЫЙ ТЕЛЕФОН
Числовой
Длинное целое
Нет
УНП
Текстовый
8
Да
КОД АВТОМОБИЛЯ
Числовой
Длинное целое
Да
АВТОМОБИЛЬ
Текстовый
50
Да
Авто
КОД АВТОМОБИЛЯ
Числовой
Длинное целое
Да
НАЗВАНИЕ АВТОМОБИЛЯ
Текстовый
40
Да
ГОС НОМЕР
Текстовый
40
Да
ВОДИТЕЛЬ
Текстовый
15
Да
 
 
 
 
 
 
 
 

4. Реализация системы

4.1 Создание, связывание и заполнение таблиц

 
Реализацию системы производим на основе модели, разработанной в разделе 3. Атрибуты и их характеристики берем из таблицы 2. Сначала создаем базу данных, называем ее «Склад продовольственных товаров», все таблицы создаем в режиме конструктора.
Сначала создаем таблицу «Товары»,  типы и параметры полей берем из раздела 3.3. Поле «Код товары» выбираем ключевым. Все действия отображены на рисунке 7.
        
Рисунок 8-Изображение таблицы «Товары»
              Затем создаем таблицу «Ведомость», поля и их значения берем из раздела 3.3, ключевое поле выбираем «Номер ведомости»,  итоговая таблица изображена на рисунке 9.
                 
                   Рисунок 9-Таблица «Накладные» в режиме конструктора
Следующую создаем таблицу «Группы товаров». Поля и их значения  берем из раздела 3.3. Ключевое поле выбираем «Код группы». Итоговая таблица изображена на рисунке 10.

                      Рисунок 10- Таблица «Группы товаров» в режиме конструктора
              Следующую создаем таблицу «Поставщики», поля них значения берем из раздела 3.3, ключевое поле «Код поставщика», таблица изображена на рисунке 11.
                
                     Рисунок 11 –Таблица «Поставщики» в режиме конструктора.
И в конце создаем таблицу «Авто», поля них значения берем из раздела 3.3, ключевое поле «Код автомобиля», таблица изображена на рисунке 12.

Рисунок 12 –Таблица «Авто» в режиме конструктора
 
              После создания таблиц необходимо установить связи между ними. Для этого на панели инструментов нажимаем кнопку «Схема данных» и добавляем туда все имеющиеся таблицы. Теперь создаем связи согласно нашей логической модели:
              1 поле «Код группы» таблицы «Группы товаров», которое является первичным ключом, связываем с полем «Код группы» таблицы «Товары», которое является ее внешним ключом, в результате образуется связь «Один ко многим». В свойствах необходимо включить пункт «Обеспечивание целостности данных»;
2 поле «Код поставщика» таблицы «Поставщики», которое является первичным ключом, связываем с полем «Код поставщика» таблицы «Ведомость», которое является ее внешним ключом, в результате образуется связь «Один ко многим». В свойствах необходимо включить пункт «Обеспечение целостности данных»;
3 поле «Код товара» таблицы «Товары», которое является первичным ключом, связываем с полем «Код товара» таблицы «Ведомости», которое является ее внешним ключом, в результате образуется связь «Один ко многим». В свойствах необходимо включить пункт «Обеспечение целостности данных».
4 поле «Код автомобиля» таблицы «Авто», которое является первичным ключом, связываем с полем «Код автомобиля» таблицы «Поставщики», и полем «Код автомобиля» таблицы «Ведомости» которое является ее внешним ключом, в результате образуется связь «Один ко многим». В свойствах необходимо включить пункт «Обеспечение целостности данных».
Разработанная схема приведена в Приложении А.
Теперь, когда таблицы и связи созданы, необходимо перейти к их заполнению.  Таблицы заполняем в режиме ввода данных. В таблице «Товары», в поле «Код группы» используем «Мастер подстановок» и выбираем значения из списка, составленного на основе таблицы «Группы товаров». Для лучшей читаемости таблицы, выбираем для отображения не номер кода группы, а название  товарной группы, но на самом деле у нас будет введен именно код группы.
В таблице «Ведомости» используем мастер подстановок для полей «Код товара» и «Код поставщика» и выбираем значение из списка, составленного из таблицы «Поставщики». Для лучшей читаемости, выбираем,  чтобы отражались не цифры, а название товара и поставщика соответственно, хотя на самом деле у нас будут введены в таблицы именно коды товара и поставщика. Заполненные таблицы «Товары» и «Ведомости» изображены на рисунке 13.


 
              Рисунок 13 – Заполненные таблицы «Товары» и «Ведомости»
Заполненные таблицы «Группы товаров» и «Поставщики» изображены на рисунке 14.


              Рисунок 14 - Заполненные таблицы «Группы товаров» и «Поставщики»

4.2 Реализация запросов к базе данных

             
После того, как мы заполнили таблицы, необходимо создать запросы к нашей базе данных.
Сначала нам необходимо создать запросы на выборку.
Первым создаем запрос «Время и дата», в котором будут показаны товары, поступившие на склад после 10.11.2010 и стоимостью общей суммой 50 000 руб. Для этого добавляем в окно запроса таблицы «Товары» и «Ведомости». В бланк запроса добавляем поля «Название товара», «Дата», «Количество», «Оптовая цена за единицу». В строке «Условия отбора» для столбца «Дата» налагаем ограничение по дате, а для столбца «Оптовая цена за единицу» ограничение по стоимости.
Переключаемся в режим SQL и просматриваем текст запроса:
SELECT Товары.[Название товара], Ведомость.[Дата составления], Ведомость.Количество, Ведомость.[Оптовая стоимость]
FROM Товары INNER JOIN Ведомость ON Товары.[Код товара] = Ведомость.[Код товара]
WHERE (((Ведомость.[Дата составления])>#9/10/2010#) AND ((Ведомость.[Оптовая стоимость])>50000))
ORDER BY Ведомость.[Дата составления];
Запрос в режиме конструктора на рисунке 14, рисунок с результатами запроса представлен на рисунке 15.

Рисунок 14- запрос «Время и дата» в режиме конструктора

Рисунок 15 – Результаты запроса  «Время и дата»
Далее создаем запрос на выборку. В запросе «Страна» будут выводиться на экран только те товары, которые произведены в России. Для этого добавляем в окно запроса таблицы «Товары» и «Поставщики». В бланк запроса добавляем поля «Название товара», «Страна -производитель» и «Поставщик». В строке «Условия отбора» для столбца «Страна-производитель» налагаем ограничение по стране, в которой произведен поставляемый товар.
Просматриваем запрос в режиме SQL:
SELECT Товары.[Название товара], Товары.[Страна- производитель], Поставщики.[Название поставщика]
FROM Товары, Поставщики
WHERE (((Товары.[Страна- производитель])="Россия"))
ORDER BY Товары.[Страна- производитель];
Запрос в режиме конструктора на рисунке 16, рисунок с результатами запроса представлен на рисунке 17.
   
Рисунок 16- запрос «Страна »в режиме конструктора
 
          
Рисунок 17-Результаты запроса «Страна»
Далее нам нужно построить запросы с подведением итогом. Создаем запрос «Средняя стоимость по группе», в котором будет отражаться средняя стоимость поставленных товаров в пределах каждой группы. Для этого добавляем в окно запроса таблицы «Группы товаров» и «Товары». В бланк запроса добавляем поля «Название группы», «Оптовая цена за единицу». Выбираем в контекстном меню «Групповые операции», для поля «Название группы» выбираем группировку по возрастанию, для поля «Оптовая цена за единицу», в строке «Сортировка» выбираем «Avg» (среднее значение).
Просматриваем запрос в режиме SQL:
SELECT [Группы товаров].[Название группы], Avg(Товары.[Оптовая цена за 1 кг(шт)]) AS [Avg-Оптовая цена за единицу]
FROM [Группы товаров] INNER JOIN Товары ON [Группы товаров].[Код группы] = Товары.[Код группы]
GROUP BY [Группы товаров].[Название группы]
ORDER BY [Группы товаров].[Название группы], Avg(Товары.[Оптовая цена за 1 кг(шт)]);
Запрос в режиме конструктора на рисунке 18, рисунок с результатами запроса представлен на рисунке 19.

Рисунок 18-Запрос «Средняя стоимость по группе» в режиме   
                            конструктора

              Рисунок 19-Результат запроса «Средняя стоимость по группе»
Далее создаем запрос «Вычисляемое поле», в котором должны будем посчитать общую стоимость поставленных товаров по конкретной ведомости. Для этого добавляем в окно запроса таблицы «Товары» и «Ведомости». В бланк запроса добавляем поля «Номер ведомости», «Дата», «Название товара», «Количество», «Оптовая цена за 1». Далее выбираем построитель выражений, в результате которого у нас появится новое поле «Стоимость», в котором будет отображаться стоимость товаров по каждой ведомости. Для этого ваыбираем из таблицы «Ведомости» поле «Количество» и умножаем его на поле «Оптовая стоимость за единицу» из таблицы «Товары».
Просматриваем запрос в режиме SQL:
SELECT Ведомость.[Номер ведомости], Ведомость.[Дата составления], Товары.[Название товара], Ведомость.Количество, Товары.[Оптовая цена за 1 кг(шт)], Ведомость!Количество*Товары![Оптовая цена за 1 кг(шт)] AS Стоимость
FROM Товары INNER JOIN Ведомость ON Товары.[Код товара] = Ведомость.[Код товара];
Запрос в режиме конструктора на рисунке 20, рисунок с результатами запроса представлен на рисунке 21.
 

Рисунок 20 –Запрос «Вычисляемое поле» в режиме конструктора

Рисунок 21 – Результат запроса «Вычисляемое поле»
Создаем запрос «Стоимость поставок», в котором будет показана средняя стоимость поставки каждым поставщиком. Для этого добавляем в окно запроса таблицы «Товары» и «Ведомость». В бланк запроса добавляем поля «Код поставщика», «Оптовая цена за единицу». В строке «Сортировка» для поля «Оптовая цена за единицу»выбираем «Avg» (среднее значение).
Просматриваем запрос в режиме SQL:
SELECT Ведомость.[Код поставщика], Avg(Товары.[Оптовая цена за 1 кг(шт)]) AS [Avg-Оптовая цена за единицу]
FROM Товары INNER JOIN Ведомость ON Товары.[Код товара]=Ведомость.[Код товара]
GROUP BY Ведомость.[Код поставщика];
Запрос в режиме конструктора на рисунке 22, рисунок с результатами запроса представлен на рисунке 23.

Рисунок 22 –Запрос «Стоимость поставок» в режиме конструктора

Рисунок 23- Результат запроса «Стоимость поставок»
И в конце создаем перекрестный запрос «Поставки». Результатом запроса будет таблица, отображающая какое количество каждого из товаров поставил каждый из поставщиков и общее количество поставленных товаров каждым поставщиком. Для удобства создания перекрестного запроса, сначала создаем простой запрос «Товары», добавляем таблицы «Товары», «Поставщики» и «Ведомости». Затем в запрос добавляем поля «Название товара», «Код товара», «Название поставщика», «Код поставщика». Теперь на основе имеющегося запроса делаем перекрестный запрос «Поставки». Выбираем «Создать», «Перекрестный запрос», и выбираем поля из уже имеющегося запроса «Товары». В столбцах у нас будет поле «Название поставщика», в строках выбираем «Название товара», в поле «Итоговое значение» выбираем функцию «Count» для того, чтобы посчитать общее количество поставленных товаров каждым из поставщиков.
Просматриваем запрос в режиме SQL:
TRANSFORM Count(перекрестный.[Код товара]) AS [Count-Код товара]
SELECT перекрестный.[Название поставщика], Count(перекрестный.[Код товара]) AS [Итоговое значение Код товара]
FROM перекрестный
GROUP BY перекрестный.[Название поставщика]
PIVOT перекрестный.[Название товара];
Запрос в режиме конструктора на рисунке 24, рисунок с результатами запроса представлен на рисунке 25.
 

Рисунок 24- Запрос «Поставки» в режиме конструктора

Рисунок 25-Результат запроса «Поставки»

4.3 Создание отчетов

 
              После создания запросов необходимо создать отчет,  который будет отражать поставки товаров на склад продовольственных товаров по месяцам.
Разрабатываем отчет в следующей последовательности:
              1 выбираем команду «Создать отчет с помощью мастера»;
              2 из запроса «Вычисляемое поле» выбираем поля «Номер ведомости», «Месяц», «Название товара», «Количество», «Стоимость»;
              3 производим группировку данных по месяцам;
              4 далее выбираем «Итоги» и функцию «Count», чтобы посчитать общую сумму поставок за каждый месяц и общую за все месяца;
              5 далее выбираем стиль вид и стиль макета;
6 вводим имя отчета «Отчет о поставках по месяцам» и сохраняем его.
Далее отчет необходимо подкорректировать в режиме конструктора, а именно, изменить текст заголовка, изменяем размер полей и перемещаем их для наглядности.  Результат отчета приведен в Приложении Б.
 

4.4 Создание форм

 
В этом разделе создаем пользовательские формы.
              Создаем форму «Поставщики», в которой будут отображаться все данные о каждом из поставщиком и поставленных им товарах.
              Разрабатываем форму в следующем последовательности:
              1 выбираем «Мастер форм»;
              2 из таблицы «Поставщики» выбираем поля «Код поставщика», «Название поставщика», «Город»;
              3 из таблицы «Товары» выбираем поля «Название товара», «Страна-производитель», «Оптовая цена за 1 кг(шт)».
              4 выбираем стиль и вид формы и сохраняем результат.
              В режиме конструктора добавляем на форму две кнопки. Первая кнопка, при нажатии на нее, будет закрывать форму. Для этого в режиме конструктора на панели элементов выбираем кнопка, затем в графе «Категории» выбираем «Работа с формой», в «Действие» выбираем «Закрыть форму», далее выводим на кнопку текст.
              Далее создаем кнопку для пролистывания формы. Для этого в режиме конструктора на панели элементов выбираем кнопка, затем в графе «Категории» выбираем «Переходы по записям», «Действие» выбираем «Перейти к следующей».
Форма в режиме конструктора изображена на рисунке 26, в режиме ввода данных – на рисунке  27.
 

                            Рисунок 26 – форма «Поставщики» в режиме конструктора

Рисунок 27 – форма «Поставщики» в режиме выполнения
Далее создаем форму «Группы товаров», в которой будет содержаться информация о каждой товарной группе и товарах, в нее входящих.
Создаем форму в следующей последовательности:
1 выбираем «Мастер форм»;
2 из таблицы «Группы товаров» выбираем поля «Код группы», «Название группы»;
              3 из таблицы «Товары» выбираем поля «Код товара», «Название товара», «Страна-производитель», «Оптовая цена за единицу».
              4 выбираем стиль и вид формы и сохраняем результат.
В режиме конструктора добавляем на форму кнопку, при нажатии на которую, форма будет закрываться. Для этого в режиме конструктора на панели элементов выбираем кнопка, затем в графе «Категории» выбираем «Работа с формой», в «Действие» выбираем «Закрыть форму», далее выводим на кнопку текст.
Форма в режиме конструктора изображена на рисунке 28, в режиме ввода данных – на рисунке  29.

              Рисунок 28 – форма «Группы товаров» в режиме конструктора

              Рисунок 29 –форма «Группы товаров» в режиме выполнения
 
 
 
 
 
 
 
 
Заключение
              Результатом курсовой работы стала база данных «Склад продовольственных товаров», созданная для обработки данных о товарах, поступающих на склад. В процессе работы были созданы таблицы, установлены связи между ними, созданы запросы, отчет и формы. Чтобы создать данную базу данных сначала мы мысленно обрисовали ситуацию, далее определили требования к базе данных и составили семантическую модель,  которую затем преобразовали в логическую с помощью правил формирования отношений. Далее проверили модель на соответствие трем нормальным формам и на отсутствие избыточности данных. Теперь любой пользователь может получить необходимую  ему информацию  о складе промышленных товаров по средствам обращения к данной базе данных.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Список использованных источников
1        Ивасенко, А. Г. Информационные технологии в экономике и управлении: Учеб. пособие / А. Г. Ивасенко, А. Ю. Гридасов, В. А. Павленко. – 2-е изд., стер. – М.: КНОРУС, 2007. – 160 с.
2        Карпова, Т. С. Базы данных: модели, разработка, реализация / Т. С. Карпова. –  СПб: Питер, 2002. – 304 с.
3        Информационные технологии управления: Учеб. пособие / Под ред. проф. Г. А. Титоренко. – 2-е изд., доп. – М.: ЮНИТИ-ДАНА, 2003. – 440 с.

4        Автоматизированные информационные технологии в экономике / Под ред. И. Т. Трубилина: Учебник. – М.: Финансы и статистика, 2001. – 416 с.

5        Кириллов, В. В. Введение в реляционные базы данных / В. В. Кириллов, Г. Ю. Громов. – СПб. : БХВ-Петербург, 2009. – 464 с.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Приложение А

Логическая модель данных

 

 

 

 

 

 

 

 

 

 

 

 

Приложение А

Отчет

 

35

 




и т.д.................


Перейти к полному тексту работы


Скачать работу с онлайн повышением уникальности до 90% по antiplagiat.ru, etxt.ru или advego.ru


Смотреть полный текст работы бесплатно


Смотреть похожие работы


* Примечание. Уникальность работы указана на дату публикации, текущее значение может отличаться от указанного.