(8 оценок, среднее: 4,75 из 5)
Загрузка...
Учебная работа. Реферат: Разработка базы данных торговой организации
АКАДЕМИЯ НАРОДНОГО ХОЗЯЙСТВА ПРИ ПРАВИТЕЛЬСТВЕ РФ (Российская Федерация — ФАКУЛЬТЕТ «КОМПЬЮТЕРНЫЕ технологии В БИЗНЕСЕ»
СПЕЦИАЛЬНОСТЬ 071900 «ИНФОРМАЦИОННЫЕ СИСТЕМЫ В ЭКОНОМИКЕ»
351400 «ПРИКЛАДНАЯ ИНФОРМАТИКА В ЭКОНОМИКЕ»
Кафедра___________________
___________________________
___________________________
КУРСОВОЙ ПРОЕКТ (РАБОТА)
ПО ПРЕДМЕТУ
Базы данных
_________________________
НА ТЕМУ «
Разработка базы данных торговой организации»
____
Студента ____3___
курса
группа № _31__
Форма обучения _очная______
___Щербакова_______________
Фамилия
___
Валерия ____________
имя
___
Алекандровна____________
Отчество
Руководитель___________________________
(подпись)
Зав. кафедры___________________________
(подпись)
МОСКВА
2005г.
АКАДЕМИЯ НАРОДНОГО ХОЗЯЙСТВА ПРИ ПРАВИТЕЛЬСТВЕ РФ (Российская Федерация — ФАКУЛЬТЕТ «КОМПЬЮТЕРНЫЕ технологии В БИЗНЕСЕ»
Утверждаю
Декан Факультета ______________ Вартанов М.О.
«___» _________2005г.
ЗАДАНИЕ
на курсовую работу по дисциплине
«Базы данных»
студентке 31 группы Щербаковой Валерии
1. 1. Тема:
Разработка базы данных торговой организации
.
2. Начальные данные к работе:
— программная среда сотворения базы данных – СУБД MS Access;
— организационно-штатную структуру подразделения (отдела, компании, конторы, организации), профиль деятельности найти без помощи других;
— состав и структуру объектов базы данных (таблиц, запросов, форм, отчетов и др.), список автоматизируемых информационных задач найти без помощи других;
— размер работы – 25-30 листов формата А4;
— оформление курсовой работы выполнить в согласовании с «Общими указаниями по организации, методике проведения и правилам дизайна курсовых проектов и работ».
3.Содержание курсовой работы, список вопросцев подлежащих разработке:
a). Доказать и создать инфологическую модель исследуемого подразделения (отдела, компании, конторы, организации).
b). Создать даталогическую модель реляционной базы данных в среде избранной СУБД (найти базисные таблицы, первичные и наружные ключи, выполнить нормализацию таблиц, установить связи меж таблицами, указать ограничения целостности), выполнить ввод инфы в базу данных.
c). Сделать запросы на подборку данных из одной и нескольких таблиц и изменение данных по разным информационным задачкам и формам представления результата с внедрением конструкций языка SQL и наглядно-диалоговых средств СУБД.
d). Создать пользовательские формы и отчеты для ввода, просмотра, редактирования, модификации и вывода данных на печать.
e). Доказать и оценить эффективность практического использования разработанного проекта и пути его предстоящего совершенствования.
4. Список иллюстративных материалов:
a). текст курсовой работы с необходимыми рисунками и диаграммами;
b). компьютерная презентация (по мере необходимости) к работе в среде MS PowerPoint;
c). компьютерная реализация базы данных в среде СУБД MS Access.
5. Управляющий работы:
Захарченко Юрий Федорович
КАЛЕНДАРНЫЙ ПЛАН
№ п.п.
Наименование шагов работы
Срок выполнения шагов работы
При-меча-ние
1.
Обоснование и разработка инфологической модели исследуемого подразделения (отдела, компании, конторы, организации).
1.11 – 10.11.05
2.
Разработка даталогической модели базы данных (определение базисных таблиц, первичных и наружных ключей, выполнение нормализации таблиц, установление связи меж таблицами, определение ограничения целостности), ввод инфы в базу данных.
10.11 – 20.11.05
3.
Создание запросов на подборку и изменение данных по разным информационным задачкам и формам представления результата с внедрением конструкций языка SQL и наглядно-диалоговых средств СУБД.
20.11 – 30.11.05
4.
Разработка пользовательских форм и отчетов для ввода, просмотра, редактирования, модификации и вывода данных на печать.
30.11 – 15.12.05
5.
Обоснование и оценка эффективности практического использования разработанного проекта и путей его предстоящего совершенствования.
15.12 – 20.12.05
6.
Оформление курсовой работы
20.12 – 25.12.05
7.
Представление курсовой работы руководителю
к 27.12.2005
Руководитель______________________________(подпись)
Студент___________________________________(подпись)
Содержание
I. Введение …………………………………………………………………………………………..5
II. 1
.Создание базы данных ……………………………………………………………………6
Этапы проектирования базы данных …………………………………………..6
1.Определение цели сотворения базы данных………………………………………6
2.Определение таблиц, которые обязана содержать база данных…….6
3.Присвоение главных полей ………………………………………………………..7
4.Редактирование структуры базы данных………………………………………7
5.Добавление данных и создание остальных объектов базы данных……..7
Инфологическая модель……………………………………………………………..8
2
. Даталогическая модель…………………………………………………………………..10
структура моей базы данных. Таблицы …………………………………….10
Нормализация ………………………………………………………………………….13
Схема данных …………………………………………………………………………..14
3
. Создание пользовательского интерфейса ……………………………………….16
Запросы ……………………………………………………………………………………16
Формы ……………………………………………………………………………………..25
отчеты ……………………………………………………………………………………..29
Макросы …………………………………………………………………………………..31
4
.Главный интерфейс базы данных …………………………………………………..32
III. Заключение…………………………………………………………………………………….33
Введение
Базы данных — совокупа данных, организованная по определенным правилам, предусматривающая общие принципы описания, хранения, манипулирования данными, независящими от прикладных программ.
СУБД – система управления базами данных – совокупа программ, созданных для управления БД и способности получения юзерами нужной инфы из базы. В задачки СУБД входят последующие задачки:
· Формирование и поддержание БД
· Обработка инфы
· Прием запросов
· Предоставление инфы юзерам
· Обеспечение целостности и реорганизации ценностей БД
· Организация совместной работы юзеров
На нынешний денек существует огромное количество разных систем управления базами данных. Все они употребляют различные средства и функции, но в большей степени у всех СУБД в базе лежат схожие понятия. Потому для обобщения этих понятий, приемов и способов на весь класс СУБД, я желала бы взять программку, входящую в Microsoft Office, Microsoft Access.
Microsoft Access –реляционная СУБД, в какой предусмотрены все нужные средства для определения и обработки данных, также управления ими при работе с огромным объемом инфы.
Access — функционально полная система, имеющая массивные средства для работы в данной нам программке. Ее преимуществом перед иными является простота, наличие всех средств для удачной обработки и управления БД.
1. Создание базы данных
1.1 . Этапы проектирования базы данных
1. Определение цели сотворения базы данных
На первом шаге проектирования базы данных нужно найти цель сотворения базы данных, главные ее функции и информацию, которую она обязана содержать.
Моя база данных разработана для торговой организации, занимающейся поставкой продуктов – женской одежки – клиентам. Схема работы весьма ординарна. Клиент организации ( все данные и контакты находятся в таблице Клиенты
) делает заказ на определенный продукт (к примеру, Майки, Lacoste, Без рисунка, по стоимости 3525 руб., 2 шт.). Этот заказ заносится в таблицу Заказанные_товары
. Организация привозит со склада необходимое количество и дальше осуществляется сама сделка: клиент получает продукт, а мы получаем средства за выполненный заказ. Опосля этого проданный организацией продукт вносится в таблицу Выполненные заказы
с пометкой выполнено. Другими словами практически будут употребляться в главном 2 таблицы – на заказ продукта и его выполнение. Другие таблицы, формы, запросы базы будут необходимы для информационной, правильной, точной, работы. Чтоб можно было сходу выяснить кто заказал, кто производитель, описание продукта , посчитать суммы заказов, создать отбор по определенным данным, обновить, удалить, добавить продукт, получить отчеты по товарам и клиентам и выйти из базы.
2.
Определение таблиц, которые обязана содержать база данных
Один из более сложных шагов в процессе сотворения базы данных — разработка таблиц, потому что результаты, которые обязана выдавать база данных не постоянно дают полное информацию разрабатываемой базы. В моем случае это Клиенты, продукты, Описание продуктов, Выполненные
заказы, Заказанные продукты, Заказы, Производитель продукта. Все таблицы хранят очень полную характеристику, информацию и описание для предстоящей удачной работы с базой данных.
3. Присвоение главных полей
Для связи данных из различных таблиц, к примеру, данные о заказчике и продукции, любая таблица обязана содержать набор полей либо поле, где будет задаваться личное база данных, сопоставляя, связывая и формируя информацию из различных таблиц. количество ключей варьируется от 1-го до нескольких. Совершенно, ключ – это малый набор атрибутов, по значениям которых можно совершенно точно отыскать требуемый экземпляр сути.
4. Редактирование структуры базы данных
Для проверки корректности работы базы нужно сделать несколько таблиц, найти связи меж ними и ввести несколько записей в каждую таблицу, а потом поглядеть, отвечает ли база данных поставленным требованиям. Рекомендуется также сделать предварительные выходные отчеты и формы и проверить, выдают ли они требуемую информацию. Не считая того, нужно исключить различные повторения данных. По другому база не будет работать и выдавать подходящий запрос либо информацию либо будет работать с ошибками, что для суровой организации неприемлемо.
5. Добавление данных и создание остальных объектов базы данных
Если структуры таблиц отвечают поставленным требованиям, то можно вводить все данные (в режиме конструктора таблиц). Опосля ввода создаются любые запросы, формы, отчеты, макросы и модули (удобнее, проще и вернее создавать все при помощи мастеров).
1.2.
Инфологическая модель
До этого чем начинать проектирование базы данных, нужно разобраться, как работает предметная область создаваемой БД. Для этих целей употребляют искусственные формализованные языковые средства. В связи с сиим под инфологической моделью соображают описание предметной области, выполненное с внедрением особых языковых средств, не зависящих от применяемых в предстоящем программных средств. Совершенно, лучше поначалу нарисовать на бумаге таблицы с данными, позже конвертировать их из 1 Обычной Формы во Вторую, и из 2-ой – в Третью. Так удобнее будет.
Определяют три главные класса сущностей:
· стержневые
· ассоциативные
· характеристические.
Стержневая суть
– независящая суть, которая имеет независящее существование, хотя может обозначать остальные сути.
Характеристическая суть
(черта)
– это связь вида «многие-к-одному» либо «одна-к-одной» меж 2-мя сущностями (личный вариант ассоциации). Цель свойства состоит в описании либо уточнении некой иной сути предметной области.
Ассоциативная суть
(ассоциация)
– это связь вида «многие-ко-многим» меж 2-мя либо наиболее сущностями либо экземплярами сути.
Это теория. Для наглядности покажу на примере торговой организации:
Стержневая суть
заказ (Заказ,
код_заказа, количество, стоимость, черта)
заказчик (Заказчик
, телефон, адресок, название_фирмы)
Поставщик (ФИО
, телефон, адресок, страна)
Характеристическая суть
2. Даталогическая модель
2.1. структура моей базы данных
Таблицы
Моя база Данных содержит 7 таблиц:
-Продукт
— Производитель_продукта
— Описание_товара
— Клиенты
— Заказы
— Заказанные_продукты
— Выполненные заказы
Во всех таблицах в режиме конструктора указываются первичные либо наружные ключи.
Таблица продукт:
создана для хранения всех продуктов с полным их описанием. к примеру, кем произведены, по какой стоимости и в котором количестве.
– номер продукта. Поле является счетчиком.
— тип продукта. Он берется из таблицы Описание_продукта
– производитель продукта. Берется из таблицы производитель_товаров.
– поле, где котором содержится описание продукта. Данные вводятся вручную в режиме конструктора.
– стоимость продукта за одну единицу.
– количество продуктов. Если продукта нет в наличие. Стоимость вводится от руки. Чтоб классифицировать столбец, нужно указать формат поля.
– денек, месяц и год поставки продукта. Вводится вручную.
– от руки вводится количество продукта. Поле заполняется при помощи запроса (заказанные_продукты и клиенты)
Таблица Производитель_товара
: содержит 4 поля:
– Поставщик Компанияпроизводитель продукта.
– наиболее подробная информация. Все поля таблицы заполняются юзером.
Таблица Описание_продукта:
состоит из 2-ух полей:
– тип продукта (к примеру: шубы, шорты и т.п.)
– поле предоставляет наиболее полную информацию о товаре.
Таблица Клиенты:
дает описание всех клиентов данной организации.
В таблице указывается ФИО, адресок и телефон клиента.
Таблица Заказы:
состоит из 4 полей :
– код текущего заказа (тип поля – счетчик)
– заказчики (представители компаний). Данные берутся из таблицы Клиенты.
– дата поступления заказа, данное поле заполняется автоматом.
– Да / Нет. Если в этом поле стоит «галочка», то данный заказ уже выполнен (значение true).
Таблица Заказанные_продукты
: содержит три поля :
— код заказа.
код данного продукта. Берется из таблицы Продукт и вводится автоматом.
– количество заказанного продукта, которое не обязано превосходить количество продуктов данного типа в таблице Продукт.
Таблица Выполненные заказы
: содержит 6 полей, заполняется при помощи запроса и дает информацию про выполненные продукты.
– код выполненного заказа
– заглавие фирмы-заказчика.
– дата поступления заказа.
– дата выполнения заказа.
– полное количество заказанных продуктов хоть какого типа.
– стоимость всех продуктов в заказе.
2.2 Нормализация
Нормализация
процесс уменьшения избыточности инфы в таблицах реляционной БД и, как следствие, построения хорошей структуры таблиц и связей.
Можно выделить 4 главных правила, которыми следует управляться при проектировании и следующей нормализации таблиц базы данных:
1. Каждое поле хоть какой таблицы обязано быть неповторимым.
2. Любая таблица обязана иметь неповторимый первичный ключ, который может состоять из 1-го либо нескольких полей таблицы.
3. Для всякого значения первичного ключа обязано быть одно и лишь одно
4. Обязана иметься возможность изменять значения хоть какого поля (не входящего в первичный ключ), и это не обязано повлечь за собой изменение другого поля.
Сделанная мною таблица удовлетворяет вышеизложенным требованиям:
1 НФ (Обычная Форма):
Заглавие таблицы
Ключевое поле
продукт
Производитель_товара
Описание_товара
Клиенты
Заказы
Заказанные_продукты
Выполненные заказы
Номер, Производитель, Черта
Производитель
Тип
Компания
Код заказа
Id
Код заказа
2 НФ:
производятся ограничения 1НФ, и любой не главный атрибут функционально много зависит от составного первичного ключа.
3 НФ:
все неключевые атрибуты дела взаимно независимы и на сто процентов зависят от первичного ключа.
Таковым образом, база данных удовлетворяет всем требованиям нормализации таблиц и 3-я обычная форма – окончательный итог нормализации моей Базы данных.
2.3 Схема данных
– это правила, поддерживаемые на уровне механизма реализации СУБД. Различают три типа отношений:
—
для каждой строчки в одной таблице существует не наиболее одной строчки связанной таблицы.
—
одна таблица не содержит совершенно либо имеет набор связанных «дочерних» записей из иной таблицы.
—
для каждой строчки первой таблицы может существовать набор строк в иной таблице и напротив. Таковая связь организуется, как правило, с помощью третьей, связывающей таблицы, содержащей значения первичных ключей обеих таблиц в качестве наружных ключей.
При разработке БД нужно принимать во внимание правила
(обеспечивает каскадное обновление
записей в связанных таблицах)
В моей схеме данных таблицы соединены последующим образом. При добавлении новейшего продукта, торговец выбирает тип
(продукта), который при помощи мастера подстановки берется из таблицы Описание_продукта
.
Также торговец выбирает производителя
(из таблицы Производитель_продукта
). Дальше он от руки вводит характеристику
продукта, его стоимость
и количество
в таблицу Продукт.
При поступлении новейшего заказа, торговец в таблицу Заказы
вводит заказанные продукты, нажав на «галочку» в графе «выполнен», а потом выбирает Фирму – заказчика.
Таблица Заказанные продукты
заполняется автоматом и хранит информацию, которая нужна для таблицы Заказы
.
Ниже представлена моя схема данных:
Таблица Выполненные заказы
заполняется при помощи запроса, которому не требуются никакие связи, потому в данной схеме данных данной нам таблицы нет.
3. Создание пользовательского интерфейса
3.1 Запросы
В моей БД содержатся 14 запросов всех типов:
· запрос на обновление
· запрос на удаление
· запрос на создание
· запрос на подборку.
Ниже я обрисую любой из запросов.
запрос «Все клиенты»
Данный запрос при выполнении дает информацию обо всех клиентах организации – заглавие конторы, адресок, телефон и e-mail.
Данные для этого запроса берутся из таблицы Клиенты.
В режиме SQL запрос смотрится так:
SELECT Клиенты.Компания, Клиенты.адресок, Клиенты.телефон, Клиенты.[E-mail]
FROM Клиенты;
запрос «Подборка по ценам типа продуктов
»
Данный запрос группирует все записи в таблице Продукт
по типу продуктов и выводит :
· наивысшую стоимость продукта
· минимальную стоимость продукта
· полное количество продуктов в таблице продукт
При выполнении запрос смотрится так:
Данные для сотворения запроса берутся из таблицы продукт, а для подсчета наибольшей и малых цен в режиме SQL вводим данные и при помощи Sum выводятся нужные нам цены.
В режиме SQL запрос смотрится так:
SELECT Продукт.Тип, Min(продукт.Стоимость) AS [Минимальная Цена], Max(Продукт.Стоимость) AS [Максимальная Цена], Sum(продукт.количество) AS [Общее Кол-во]
FROM продукт
GROUP BY Продукт.Тип;
запрос «Добавление заказа
»
Данный запрос добавляет заказы в таблицу Выполненные заказы
невыполненные в таблице Заказы.
запрос заносит в эту таблицу последующие данные ФИО
клиента, Код заказа
и Дату заказа
, которые он берет из таблицы Заказы
. Этот запрос инспектирует, является поле
(в таблице Заказы)
неверным либо нет. Если да, то он берет эти данные, и подставляет в таблицу Выполненные заказы
. Также в эту таблицу
вставляются данные о том, когда был выполнен заказ, количество продуктов, заказанное данным клиентом и сумму покупки.
В режиме SQL запрос смотрится так:
INSERT INTO [Выполненные заказы] ( [Код заказа], Компания, [Дата заказа], [Дата выполнения], количество, [Сумма заказа] )
SELECT Заказы.[Код заказа], Заказы.Компания, Заказы.[Дата заказа], Date() AS [Дата выполнения], Sum(продукт.количество) AS Количество, Sum(Заказанные_товары!Количество*продукт!Стоимость) AS Сумма
FROM Заказы INNER JOIN (продукт INNER JOIN Заказанные_товары ON Продукт.Номер = Заказанные_продукты.[Код товара]) ON Заказы.[Код заказа] = Заказанные_продукты.Номер
GROUP BY Заказы.[Код заказа], Заказы.Компания, Заказы.[Дата заказа], Date(), Заказы.Выполнен
HAVING (((Заказы.Выполнен)=False));
запрос «Заказанные_товары и клиенты
»
Данный запрос при выполнении выводит все заказанные продукты, заглавие конторы – клиента, которая заказала продукт, требуемое количество продукта и его стоимость, также дату поступления заказа на данный продукт. Подборка осуществляется лишь по тем товарам, которые были заказаны хотя бы один раз. А данные для этого запроса находятся в таблицах Заказанные_продукты, Клиенты и Продукт.
В режиме SQL запрос смотрится так:
SELECT Заказы.Компания, Продукт.Тип, Продукт.Производитель, Продукт.Черта, продукт.Стоимость, Заказы.[Дата заказа], Продукт.количество
FROM (Клиенты INNER JOIN Заказы ON Клиенты.Компания=Заказы.Компания) INNER JOIN (Продукт INNER JOIN Заказанные_продукты ON Продукт.Номер=Заказанные_товары.id) ON Заказы.[Код заказа]=Заказанные_продукты.Номер;
«Запрос на
Подборку всех клиентов с введенной буковкы
».
При запуске этого запроса он просит ввести буковку либо несколько букв, с которых начинается заглавие конторы – клиента (данные из таблицы Клиенты). Данный запрос достаточно прост, но нужен. К примеру если торговец помнит первую буковку либо несколько букв, то он запускает данный запрос и вводит, ту буковку, которую помнит, а в ответ на введенную буковку запрос выводит заглавие всех компаний на обозначенную буковку.
В режиме SQL данный запрос смотрится так :
SELECT Клиенты.Компания, Клиенты.адресок, Клиенты.телефон
FROM Клиенты
WHERE (((Клиенты.Компания) Like [Введите] & «*»));
«запрос по типу продукта
»
Обычной запрос, который дозволяет выводить продукты (из таблицы Продукт
) по определенному типу. При всем этом дается описание продукта – производитель, черта, стоимость, количество.
Ниже представлен итог выполнения данного запроса при внедрении продукта «Шубы» :
В режиме SQL запрос смотрится так:
SELECT продукт.Тип, Продукт.Производитель, Продукт.Черта, продукт.Стоимость, Продукт.количество
FROM Продукт
WHERE (((продукт.Тип) Like [Введите тип] & «*»));
запрос на обновление «Обновление заказа
».
Запрос, который обновляет количество продуктов (в том числе и проданных) в таблице продукт
, также он обновляет поле Выполнен
в таблице Заказы
. запрос работает последующим образом: если в таблице Заказы
в поле Выполнен
есть заказы с неверным значением (False), то данный запрос обновляет все продукты, которые содержатся в данном заказе в таблице продукт
.
В таблице Заказы
есть заказ, состоящий из 5 продуктов «Шорты, мини», содержащий заглавие фирмы-заказчика и дату заказа. Данный заказ не выполнен, т.е. в поле Выполнен
стоит Обновление заказа
», происходит последующее: выполнен
в таблице становится правдой (True), количество имеющихся на складе продуктов «Шорты, мини» миниатюризируется на 5, в то время как количество проданных на столько же возрастает.
В режиме SQL запрос смотрится так:
UPDATE Заказы INNER JOIN (продукт INNER JOIN Заказанные_товары ON (Продукт.Номер = Заказанные_продукты.[Код товара]) AND (Продукт.Номер = Заказанные_продукты.[Код товара])) ON Заказы.[Код заказа] = Заказанные_продукты.Номер SET Продукт.количество = Продукт.Количество-Заказанные_продукты.[Количество], Заказы.Выполнен = True, Продукт.[количество проданных] = Продукт.[Количество проданных]+Заказанные_продукты.[количество]
WHERE (((Заказы.Выполнен)=False));
запрос на «Создание таблицы уцененных продуктов
».
Этот запрос делает новейшую таблицу с уцененными продуктами. Он работает последующим образом :
При запуске запроса нужно ввести процент уценения продуктов, а потом дату. запрос выбирает все продукты, дата поставки которых соответствует введенной дате, и копирует их в новейшую таблицу Уцененные продукты
.
К примеру :
Я запускаю запрос и ввожу процент = 15
и дату 07.01.05. В итоге у меня выходит таблица, содержащая 2 записи:
По сопоставлению с таблицей продукт цены вправду снизились на 15%.
В режиме SQL запрос смотрится так:
SELECT Продукт.Тип, продукт.Производитель, Продукт.Черта, Продукт.Стоимость*(1-[Введите процент уценения]/100) AS Выражение2, продукт.[Дата поставки] INTO [Уцененные товары]
FROM продукт
WHERE (((Продукт.[Дата поставки])=[Введите дату]));
запрос «Сумма всех продуктов
»
Этот запрос дозволяет найти, сколько на складе продукта всякого типа и его стоимость, также общую стоимость всей партии всякого продукта. Все данные для запроса из таблицы продукт. Я считаю этот запрос полезным, потому что с его помощью можно найти общую стоимость всех имеющихся
продуктов. Чтоб посчитать сумму всех продуктов, нужно в режиме SQL помножить стоимость всех продуктов на их количество.
(сортировка по типу)
В режиме SQL запрос смотрится так:
SELECT продукт.Тип, Продукт.Производитель, Продукт.Черта, продукт.Стоимость, Продукт.количество, Продукт.Стоимость*продукт.Количество AS [Общая стоимость]
FROM Продукт;запрос на добавление;
Запрос «Сумма покупок клиентов
»
Запрос выбирает всех клиентов, совершивших заказ, и выдает информацию о сумме заказа, о количестве заказанных продуктов и о выполнении заказа.
Данный запрос нужен для определения нередких клиентов и для рассмотрения способности предоставления льгот и скидок неизменным заказчикам. Для построения запроса данные берутся из таблиц Заказы, Заказанные продукты, Клиенты, Продукт.
В режиме SQL запрос смотрится так:
SELECT Заказы.Компания, Заказы.[Дата заказа], Sum(Заказанные_товары.количество) AS [Кол-во], Sum(Заказанные_товары!Количество*продукт!Стоимость) AS Сумма, Заказы.Выполнен
FROM (Клиенты INNER JOIN Заказы ON Клиенты.Компания=Заказы.Компания) INNER JOIN (Продукт INNER JOIN Заказанные_продукты ON Продукт.Номер=Заказанные_товары.id) ON Заказы.[Код заказа]=Заказанные_продукты.Номер
GROUP BY Заказы.Компания, Заказы.[Дата заказа], Заказы.Выполнен;
«продукт, стоимость которого больше данной
»
Запрос, позволяющий выбирать продукты с большей стоимостью. В запросе выводятся продукты (таблица продукт), у каких стоимость выше данной суммы.
Я ввела сумму 14200 и получила итог:
В режиме SQL запрос смотрится так:
SELECT Продукт.Тип, продукт.Производитель, Продукт.Черта, Продукт.Стоимость
FROM продукт
WHERE (((Продукт.Стоимость)=[введите цену] Or (продукт.Стоимость)>[введите цену]));
запрос на «Продукты с высочайшей стоимостью»
запрос делает подборку из таблицы Продукт по цены продуктов и выдает информацию о 10 более дорогостоящих.
При построении запроса я употребляла в режиме SQL предикат TOP10 – вывод на экран 1-ые 10 продуктов (без повторения). Кроме цен и самих продуктов, прилагается еще черта продукта и его Фирмапроизводитель.
В режиме SQL запрос смотрится так:
SELECT TOP 10 продукт.Тип, Продукт.Производитель, Продукт.Черта, продукт.Стоимость
FROM Продукт
ORDER BY Продукт.Стоимость DESC;
запрос на «Удаление Поставщика
»
Данный запрос весьма прост, но полезен. Он дозволяет удалять из базы производителя, с которым мы больше не работаем, не открывая таблицы Производитель_продукта.
В режиме SQL запрос смотрится так:
DELETE Поставщик_продукта.Поставщик, Поставщик_товара.Поставщик
FROM Поставщик_продукта
WHERE (((Поставщик_товара.Поставщик)=[введите поставщика]));
3.2
Формы
Формы создавать довольно просто. Для этого в режиме «мастер форм» выбираются значения из таблиц и формируются по усмотрению разраба базы.
Моя база Данных содержит 11 форм:
Форма «Все заказы».
Обычная форма, выводящая все заказы, как выполненные, так и невыполненные.
Форма «Подборка всех клиентов с введенной буковкы
»
Это обычная форма, которая выводит всех клиентов с введенной буковкы и :
· дозволяет заносить конфигурации о клиентах
· дозволяет добавлять новейших клиентов
Форма «Выполненные заказы продуктов
»
Тоже довольно обычная форма, предназначенная лишь для просмотра выполненных заказов.
Форма «Добавление продуктов
»
Эта форма дозволяет добавлять продукты в таблицу Продукт
. Форма имеет обычное и комфортное оформление и создана для работников склада. Данная форма дозволяет добавлять новейший продукт и изменять имеющийся.
Форма «Заказанные продукты и клиенты
»
Форма создана для просмотра и исправления заказанных продуктов и фирм-клиентов.
Форма «Клиенты и их заказы
»
Эта форма дозволяет просмотреть и поменять информацию о клиенте и его заказах.
Форма «Клиенты организации».
В данной нам форме предоставляется информация о клиентах организации.
Данные берутся из таблицы Клиенты.
Форма «Общая форма»
В общей форме приведены все характеристики продукта – тип, производитель и т.п.
Форма «Отчет по производителям продукта»
В данной форме при запуске возникает вся информация по производителям продуктов – заглавие конторы, страна, адресок, телефон.
Форма «Производители продуктов»
По содержанию таковая же, как и предшествующая, но различается по виду.
3.3 отчеты
Отчеты создаются опосля построения всех таблиц, форм и запросов. отчеты почаще всего являются подведением итогов либо обобщением данных. Создавать отчеты довольно просто в мастере сотворения отчетов. Позже вручную (в режиме конструктора) вводятся выражения (к примеру, Sum), настраивается интерфейс (цвет шрифта, фона и т.п. ).
отчет по выполненным заказам.
Этот отчет создается в конструкторе и весьма комфортен в использовании. С его помощью можно просмотреть заказчика, дату заказа и выполнения заказа, количество продукта и сумму заказа. Также отчет выводит результат по сумме и количеству всех заказов. Данные будут изменяться автоматом зависимо от выполнения новейших заказов (будут добавляться).
отчет по заказам.
Этот отчет выдает свойства заказанных продуктов – тип, описание, производителя, также условия заказа – кем, в котором количестве и на какую сумму был произведен заказ. Также подсчитывается общая сумма заказов. Данные будут изменяться автоматом зависимо от поступления новейших заказов (будут добавляться).
отчет по клиентам организации.
Этот отчет нужен руководителям с целью ознакомления со всеми клиентами организации. Данные будут изменяться автоматом зависимо от возникновения новейших клиентов (будут добавляться).
3.4 Макросы
Для сотворения макроса нужно зайти в режим конструктора макроса и избрать макрокоманду (к примеру, «открыть запрос») и понизу, в аргументах макрокоманды, ввести данные :
—имя таблицы
-Режим
-Режим данных
Проверяется работа макроса при нажатии !
(«пуск»).
— макросы моей базы данных
Эти макросы служат для:
1. Пометки о выполнении готовых, но еще не вписанных заказов
2. Выхода из базы данных
3. Для открытия всех заказов
4. Развертывания странички в полный экран.
4.Главный интерфейс базы данных
Главным интерфейсом для СУБД MS Access служит основная кнопочная форма. Для ее открытия нужно зайти так:
.
При загрузке базы данных раскрывается Кнопочная Форма.
В ней можно:
· Просмотреть перечень всех имеющихся продуктов
· Добавить заказ и обновить перечень выполненных заказов
· Получить информацию обо всех клиентах организации
· Просмотреть перечень о уже выполненных заказах
· И просмотреть все заказы.
· Ну и, естественно, выйти назад.
Заключение
Я разработала базы данных торговой организации по поставке одежки.
При помощи моей базы можно без затруднений и особых познаний вести базу данных, которая дозволяет созодать все операции с клиентами, заказами, производителями. Другими словами добавлять, изменять, обновлять, удалять и просматривать все имеющиеся и вводимые данные.
Кнопочная форма дозволяет просматривать отчеты о клиентах и товарах, созодать заказы и обновлять данные.
На примере моей базы данных для торговой организации, я предоставила к рассмотрению и анализу фактически все функции и способности Microsoft Accsess. Эта программка достаточна ординарна и комфортна в воззвании. Построение таблиц, отчетов, запросов, форм упрощается при использовании мастеров (форм, таблиц и т.п.).
Я считаю, что база данных в среде СУБД MS Access практическом применении комфортна и довольно эффективна. Все зависит от юзера, размера располагаемых им познаний и умения ими пользоваться. Говоря о для себя могу сказать, что эта программка имеет много нужных функций и в предстоящем мне весьма понадобится.
]]>