База данных фруктовый сад

Задание
Существует некоторый фруктовый склад, занимающийся куплей-продажей товара. Товар имеет определенные характеристики, такие как наименование, единица измерения, количество данного товара на складе, цена товара за покупку и др. Покупка и продажа товара выступают в качестве сделки, которые характеризуются датой сделки, общей суммой сделки и др. Оптовый склад имеет своих поставщиков и своих покупателей, с которыми наш склад и совершает сделки. Склад имеет всю информацию о поставщиках и покупателях, которая хранится в базе данных.
Предполагаются такие решения задач:
выдача информации об определенном товаре;
выдача информации о поставщиках;
выдача информации о покупателях;
закупка товаров
продажа товаров
Также реализованы такие задачи как:
добавление данных
удаление данных
редактирование данных
заключение сделок
некоторые запросы
Реферат
Объем пояснительной записки 39 страниц, 18 рисунков. Она включает в себя такие разделы как:
анализ предметной области, разработка информационно-логической схемы базы данных, разработка интерфейса пользователя, разработка выходных форм, выборочный доступ к данным, инструкция администратора, инструкция пользователя
анализ предметной области, разработка модели предметной области, разработка информационного и программного обеспечения, разработка интерфейса пользователя
Тема работы: «Фруктовый склад»
Цель работы: создать средствами Microsoft Access базу данных фруктового склада, предусмотреть реализацию следующих возможностей: добавление данных в записную книжку; удаление данных из записной книжки; поиск данных по конкретным признакам; изменение каких-либо данных
Во время выполнения работы была выучена предметная область: ”Фруктовый склад” и построено бизнес-правила, которым должна соответствовать информационная система. На основании этой информации была построена концептуальная модель данных, которая путем логического проектирования приведена к соответствию реляционной базы данных. Разработан дизайн информационной системы. Требуемая функциональность реализована программными средствами СУБД Access и языком запросов SQL.
НОРМАЛИЗАЦИЯ ОТНОШЕНИЙ, ТАБЛИЦА, ЗАПРОС, ФОРМА, ОТЧЕТ, ИНФОРМАЦИОННАЯ СИСТЕМА, КОНЦЕПТУАЛЬНАЯ МОДЕЛЬ ДАННЫХ, СУЩНОСТЬ, ПЕРВИЧНЫЙ КЛЮЧ, АТРИБУТ, СУБД ACCESS, SQL
Содержание
Задание
Введение
1. Анализ предметной области
2. Разработка информационно-логической схемы базы данных
2.1 Выделение объектов и информационных процессов в данной области
2.2 Разработка реляционной модели базы данных
3. Разработка интерфейса пользователя
4. Разработка выходных форм
5. Выборочный доступ к данным
6. Инструкция администратору, инструкция пользователю
6.1 Инструкция администратору
6.2 Инструкция пользователю
Заключение
Список использованных источников
Введение
В состав пакета Microsoft Office Professional входит приложение Microsoft Access, предназначенное для работы с базами данных. Под базой данных Microsoft Access понимает совокупность данных и объектов, относящихся к определенной задаче. База данных Microsoft Access может содержать таблицы, запросы, формы, отчеты, макросы, модули и ярлыки страниц доступа к данным. Ядро базы данных Microsoft Jet управляет данными, которые содержатся в таблицах, находящихся в базе данных. Данные в связанных таблицах могут содержаться в другой базе данных Access, во внешнем источнике данных, таком как базы данных dBASE или электронная таблица Microsoft Excel, а также в источнике данных ODBC, таком как Microsoft SQL Server.
Microsoft Access позволяет управлять информацией из одного файла базы данных. В рамках этого файла данные можно разделить на отдельные контейнеры, называемые таблицами; просматривать, добавлять и обновлять данные в таблицах с помощью электронных форм; находить и извлекать только нужные данные с помощью запросов; а также анализировать или печатать данные в заданном макете с помощью отчетов. Создание страниц доступа к данным позволяет пользователям просматривать, обновлять или анализировать данные из базы данных через Интернет или интрасеть.
1. Анализ предметной области
Думаю, что каждый из нас когда-либо заходил в супермаркет, чтоб приобрести различные товары, но мало кто из нас задумывается над тем, откуда же эти товары оказываются на полках наших больших магазинов.
Хотелось бы рассмотреть эту проблему на примере моей курсовой работы “Фруктовый склад”. Несомненно, эта база данных будет состоять из таких сущностей взаимоотношений, как клиенты, т.е. закупщики товаров, и поставщики, т.е. те, кто непосредственно предоставляют эти товары.
К этому складу относятся фрукты, которым присвоен определенный код и единица измерения (в килограммах или поштучно). Фрукты расположены на полках, также указана их цена, количество и дата.
Чтоб склад всегда был заполнен, товары приобретают у дилеров. Т.е. в базе данных обязательно должны присутствовать клиенты, за которыми закреплены номер, имя (т.е. название супермаркета), город, адрес и телефон, и поставщики, за которыми также закреплены номер, имя, город, адрес и телефон. Между ними отношения в виде закупки-продажи. Т.е. надо учитывать, у какого поставщика приобретен товар, по какой цене, в каком количестве, в какое время и т.д. Также, когда товары со склада продают, необходимо следить за тем, какой супермаркет какой товар продал, по какой цене, в каком количестве и в какое время. Несомненно, делать вручную все это сложно, потому что надо вести отчеты, а считать и следить за каждой закупкой и продажей не так-то легко.
Поэтому я считаю, что такие базы данных очень важны в наше время, чтоб чего-то не упустить и все верно учесть. В моем курсовом проекте количество наименований товаров не так велико, как должно быть действительно в супермаркете, но эта проблема предусмотрена: можно добавлять-удалять товары, города, дилеров, клиентов, что предоставит легкость изменении склада.
Данная курсовая работа выполнена в среде Microsoft Office Access. Эта информационная система столь удобна, что с ней смогут работать в дальнейшем пользователи-непрограммисты. Эта база данных облегчит работу сотрудников супермаркетов, они смогут получать необходимую информацию, редактировать ее, вести необходимый учет и составлять отчеты, что также сэкономит их время и повысит конкурентоспособность предприятий.
2. Разработка информационно-логической схемы базы данных
2.1 Выделение объектов и информационных процессов в данной области
/>
Рисунок 2.1 — Схема данных в СУБД Access
Существует некоторый фруктовый склад, занимающийся куплей-продажей товара. Товар имеет определенные характеристики, такие как наименование, единица измерения, количество данного товара на складе, цена товара за покупку и др. Покупка и продажа товара выступают в качестве сделки, которые характеризуются датой сделки, общей суммой сделки и др. Оптовый склад имеет своих поставщиков и своих покупателей, с которыми наш склад и совершает сделки. Склад имеет всю информацию о поставщиках и покупателях, которая хранится в базе данных.
Концептуальная модель базы данных имеет следующий вид:
Таблица Покупатель (client) включает в себя такие поля как (ИН_покупателя, город покупателя, фирма покупателя, адрес, телефон);
Таблица Поставщик (diler) включает в себя такие поля как (ИН_поставщика, город поставщика, фирма поставщика, адрес, телефон);
Таблица Покупка (buying) включает в себя такие поля как (ИН_покупки, ИН_товара, фирма поставщика, дата сделки, стоимость за единицу товара, количество);
Таблица Продажа (selling) включает в себя такие поля как (ИН_продажи, ИН_товара_со_склада, фирма покупателя, дата сделки, стоимость за единицу товара, количество);
Таблица Города (cities) включает в себя такие поля как (ИН_города, название города);
Таблица Товары на складе (shelfs) включает в себя такие поля как (ИН_записи, ИН_товара, количество, цена за единицу);
Таблица Множество товаров (products) включает в себя такие поля как (ИН_товара, название, единица измерения, дата);
Для каждой сущности выбран ключ — атрибут, значения которого однозначно идентифицируют кортеж:
1) таблица client — ключевое поле ID_client
2) таблица diler — ключевое поле ID_diler
3) таблица buying — ключевое поле ID_buying
4) таблица selling — ключевое поле ID_selling
5) таблица cities — ключевое поле ID_city
6) таблица shelfs — ключевое поле ID_shelf
7) таблицаproducts — ключевоеполеID_Product
Все ключевые поля являются идентификационным номером, что облегчает работу с данными.
Все таблицы связаны между собой. Все связи таблиц, как видно из схемы, имеют отношение «один ко многим»:
Между таблицей “client” и “selling” существует связь «один ко многим» (в каждой продаже берет участие свой определенный покупатель). Таблица “cities” связана с таблицами “clients” и “dilers” связью «один ко многим» (для каждого покупателя и поставщика есть свой город). Таблица “dilers” связана с таблицей “buying” связью «один ко многим» (при каждой покупке берет участие поставщик). Таблица “buying” связана с таблицей “products” «многие к одному» (т.е. некоторые продукты покупаются, и они включены в список покупок).
Таблица “products” связана с таблицей “shelfs” связью «один ко многим» (т.е. определенные товары находятся на складе фруктов). Сущность “shelfs” так же связана с сущностью “sellings” связью «один ко многим» (это означает, что со склада берутся товары на продажу).
Предполагается также решение следующих задач:
выдача информации об определенном товаре;
выдача информации о сделках;
выдача информации о поставщиках;
выдача информации о покупателях;
закупка товаров
продажа товаров
2.2 Разработка реляционной модели базы данных
Реляционная база данных — это набор нормализованных отношений, которые различаются по именам.
Реляционная база данных состоит из отношений, структура которых определяется с помощью особых методов, называемых нормализацией.
Эти отношения обладают следующими характеристиками:
отношение имеет имя, которое отличается от имен всех других отношений в реляционной схеме;
каждая ячейка отношения содержит только одно элементарное (неделимое) значение;
каждый атрибут имеет уникальное имя;–PAGE_BREAK–
значения атрибута берутся из одного и того же домена;
каждый кортеж является уникальным, т.е. дубликатов кортежей быть не может;
порядок следования атрибутов не имеет значения;
теоретически порядок следования кортежей в отношении не имеет значения; (Но практически этот порядок может существенно повлиять на эффективность доступа к ним)
набор возможных значений для данной позиции отношения определяется множеством, или доменом, на котором определяется эта позиция. В таблице все значения в каждом столбце должны происходить от одного и того же домена, определенного для данного атрибута;
во множестве нет повторяющихся элементов. Аналогично, отношение не может содержать кортежей-дубликатов;
поскольку отношение является множеством, то порядок элементов не имеет значения. Следовательно, порядок кортежей в отношении несуществен.
Реляционная база данных может состоять из произвольного количества нормализованных отношений. Общепринятое обозначение реляционной схемы включает имя отношения, за которым (в скобках) располагаются имена атрибутов. При этом первичный ключ (обычно) подчеркивается.
Достоинствами реляционной модели данных являются простота, гибкость структуры, удобство реализации на компьютере, высокая стандартизация и использование математического аппарата реляционной алгебры и реляционного исчисления.
К недостаткам можно отнести атомарность, ограниченность и предопределенность набора возможных типов данных. Это затрудняет использование реляционных моделей для некоторых современных приложений. Названная проблема решается расширением реляционных моделей в объектно-реляционные.
В объектно-реляционноймодели отдельные записи база данных представляются в виде объектов. Между записями базы данных и функциями их обработки устанавливаются взаимосвязи с помощью механизмов, подобных соответствующим средствам в объектно-ориентированных языках программирования. Объектно-ориентированные модели сочетают особенности сетевой и реляционной моделей и используются для создания крупных БД со сложными структурами данных.
В реляционной модели все данные представляются как факты о сущностях и связях, это и понимают под основными свойствами. Сущность — это, например, человек, место, вещь, событие, концепция, о которых хранится информация. Сущности именуются обычно существительными, такими как «покупатель», «компьютер», «служащий», «продажа».
Более точно, сущность — это множество индивидуальных объектов — экземпляров, причем все эти объекты являются различными.
Связь — это функциональная зависимость между сущностями. Например, «служащий» совершает «продажи».
Каждая сущность обладает атрибутами. Атрибут — это свойство объекта, характеризующее его экземпляр. Сущность «служащий» может иметь атрибуты «имя», «дата рождения» и т.д.
Общепринятым видом графического изображения реляционной модели данных является ER — диаграмма. На такой диаграмме сущности (таблицы) изображаются прямоугольниками, возможно, соединенными между собой линиями (связями). Такое графическое представление облегчает восприятие структуры базы данных по сравнению с текстовым описанием.
Различают целостность по сущностям и целостность по ссылкам. В целостности по сущностям не разрешается, чтобы какой-либо атрибут, участвующий в первичном ключе базового отношения принимал неопределенные значения.
Базовые отношения — это реально существующие модели отношения, которые соответствуют реальному объекту предметной области.
Целостность по ссылкам основана на понятии внешнего ключа.
Пусть даны отношения R1 и R2. Пусть k1, — это первичный ключ отношения R1.
Если в отношении R2 присутствуют атрибуты k1, то для отношения R2, k1 — это внешний ключ. Если базовое отношение R2 содержит внешний ключ k1, то каждое значение k1 в R2 должно быть либо равным какому-либо значению R1, либо полностью неопределенным.
Достоинствами реляционного подхода являются:
1) наличие простого, и в тоже время мощного математического аппарата
2) возможность навигационного манипулирования данными без знания физических основ хранения данных.
Чтобы база данных была надежной, необходимо чтобы существовала нормализация. Существуют три нормальных формы.
Итак, условия первой нормальной формы:
Определить требуемые элементы данных, потому что они становятся столбцами в таблице. Поместить связанные элементы данных в таблицу.
Гарантировать отсутствие повторяющихся групп данных.
Гарантировать наличие первичного ключа.
Значение всех атрибутов атомарны
Информационная система находится в первой нормальной форме.
Условия второй нормальной формы:
отношение в первой нормальной форме
независимость первичных ключей и столбцов
Информационная система находится во второй нормальной форме.
Третья нормальная форма является заключительным шагом. Существуют нормальные формы с более высокими порядковыми номерами, но они гораздо сложнее и не обязательно ведут к созданию более эффективной базы данных. В базе данных требуется выбирать компромисс между минимизации избыточности данных и эффективностью.
Условия третьей нормальной формы:
отношение во второй нормальной форме.
все поля, не входящие в первичный ключ, зависят от первичного ключа.
Информационная система находится в третьей нормальной форме.
Таким образом, нормализация отношений успешно достигнута.
После нормализации отношений было создано 7 таблиц. Проиллюстрируем эти таблицы в режиме конструктора:
/>
Рисунок 2.2 — таблица покупки в режиме конструктора
/>
Рисунок 2.3 — таблица города в режиме конструктора
/>
Рисунок 2.4 — таблица клиенты в режиме конструктора
/>
Рисунок 2.5 — таблица поставщики в режиме конструктора
/>
Рисунок 2.6 — таблица товары в режиме конструктора
/>
Рисунок 2.7 — таблица продажи в режиме конструктора
/>
Рисунок 2.8 — таблица склад в режиме конструктора
3. Разработка интерфейса пользователя
/>
Рисунок 3.1 — Главная кнопочная форма
Дизайн разработан на основе понятия о “диалоговых окнах”. Существует главное окно, или так называемая “Главная форма”. Открыв ее, пользователю предлагаются следующие действия:
добавить поставщика товаров;
добавить покупателя товаров;
добавить товар;
добавить города;
просмотреть запросы;
просмотреть таблицы;
просмотреть отчеты.
Существуют также связанные с ней формы, о которых говорилось выше.
Форма на добавление города:
/>
Рисунок 3.2 — Добавление города
Форма на добавление поставщика:
/>
Рисунок 3.3 — Добавление поставщика
Форма на покупателя:
/>
Рисунок 3.4 — Добавление покупателя
Форма для добавления товара во множество товаров:
/>
Рисунок 3.5 — Добавление товара
Форма на добавление покупки:
/>
Рисунок 3.6 — Добавление сделки
Форма на добавление продажи:
/>
Рисунок 3.7 — Добавление продажи
Форма товаров на складе:
/>
Рисунок 3.8 — Товары на складе
Форма о программе:
/>
Рисунок 3.9 — Форма «О программе»
Требуемая функциональность определяется удобным интерфейсом и написанием запросов, которые бы осуществляли важные действия над базой данных. Разработан ряд основных запросов, которые осуществляют такие действия:
узнать сколько покупателей в каждом городе;
узнать сколько поставщиков в каждом городе;
узнать какие клиенты не совершали покупок;
узнать какие поставщики не поставляли на склад товар;
узнать сумму всех сделок с каждым поставщиком;
узнать сумму сделок с клиентами;
узнать стоимость всех товаров на складе.
Благодаря созданию запросов, база данных оптового склада, значительно упрощает работу пользователя и делает ее более понятной.
4. Разработка выходных форм
В любой базе данных для эффективности работы создаются отчеты. Чтоб конкретно знать результаты проделанной работы за определенный период времени, надо проводить подсчеты. Но в нашем случае все намного проще, когда можно создать отчеты. Для еще более удобной работы пользователя на главной форме созданы кнопочки печати отчетов. В нашем случае эти кнопочки называются “отчет по покупкам” и “отчет по продажам”. После того, пользователь составил быстро отчет, он так же с легкостью может вывести его на печать.
/>
Рисунок 4.1 — главная форма, где присутствуют кнопки печати
5. Выборочный доступ к данным
Язык манипулирования данными (DML) является сердцем SQL. Для каждого добавления, изменения или удаления данных из базы данных выполняется команда DML. Совокупность команд DML, результаты действия которых еще не стали постоянными, организуют транзакцию.
Рассмотрим следующие операторы языка SQL DML:
1) SELECT — выборка данных из базы;
2) INSERT — вставка данных в таблицу;
3) UPDATE — обновление данных в таблице;
4) DELETE — удаление данных из таблицы.
Назначение оператора SELECT состоит в выборке и отображении данных одной или более таблиц базы данных. Это исключительно мощный оператор, способный выполнять действия, эквивалентные операторам реляционной алгебры выборки, проекции и соединения, причем в пределах единственной выполняемой команды. Оператор SELECT является чаще всего используемой командой языка SQL. Общий формат оператора SELECT имеет следующий вид:    продолжение
–PAGE_BREAK–
SELECT [DISTINCT| ALL] {* I [columnExpression [AS newName]] [,…] }
FROM TableName [alias] [,…]
[WHERE condition]
[GROUP BY columnList] [HAVING condition]
[QRDER BY columnList]
Здесь параметр columnExpressionпредставляет собой имя столбца или выражение из нескольких имен. Параметр TableNameявляется именем существующей в базе данных таблицы (или представления), к которой необходимо получить доступ. Необязательный параметр alias — это сокращение, устанавливаемое для имени таблицы TableName. Обработка элементов оператора SELECT выполняется в следующей последовательности:
1) FROM — определяются имена используемой таблицы или нескольких таблиц;
2) WHERE — выполняется фильтрация строк объекта в соответствии с заданными условиями;
3) GROUP BY — образуются группы строк, имеющих одно и то же значение в указанном столбце;
4) HAVING — фильтруются группы строк объекта в соответствии с указанным условием;
5) SELECT — устанавливается, какие столбцы должны присутствовать в выходных данных;
6) ORDER BY — определяется упорядоченность результатов выполнения оператора.
Порядок конструкций в операторе SELECT не можетбыть изменен. Только две конструкции оператора — SELECT и FROM — являются обязательными, все остальные конструкции могут быть опущены. Операция выборки с помощью оператора SELECT является замкнутой, в том смысле, что результат запроса к таблице также представляет собой таблицу.
Существуют две формы оператора INSERT. Первая предназначена для вставки единственной строки в указанную таблицу. Эта форма оператора INSERT имеет следующий формат:
INSERT INTO TableName[ (columnList)]
VALUES (dataValueList)
Здесь параметр TableNameможет представлять либо имя таблицы базы данных, либо имя обновляемого представления. Параметр colunmListпредставляет собой список, состоящий из имен одного или более столбцов, разделенных запятыми. Параметр coIumnList является необязательным. Если он опущен, то предполагается использование списка из имен всех столбцов таблицы, указанных в том порядке, в котором они были описаны в операторе CREATE TABLE. Если в операторе INSERT указывается конкретный список имен столбцов, то любые опущенные в нем столбцы должны быть объявлены при создании таблицы как допускающие значение NULL — за исключением случаев, когда при описании столбца использовался параметр DEFAULT. Параметр dataValueListдолжен следующим образом соответствовать параметру columnList:
1) количество элементов в обоих списках должно быть одинаковым;
2) должно существовать прямое соответствие между позицией одного и того же элемента в обоих списках, поэтому первый элемент списка dataValuelist считается относящимся к первому элементу списка columnList, второй элемент списка dataValuelist — ко второму элементу списка columnListи т.д.;
3) типы данных элементов списка dataValueListдолжны быть совместимы с типом данных соответствующих столбцов таблицы.
Вторая форма оператора INSERT позволяет скопировать множество строк одной таблицы в другую. Этот оператор имеет следующий формат:
INSERT INTO TableName [ (columnList)]
SELECT …
Здесь параметры TableName и columnListимеют тот же формат и смысл, что и при вставке в таблицу одной строки. Конструкция SELECT может представлять собой любой допустимый оператор SELECT. Строки, вставляемые в указанную таблицу, в точности соответствуют строкам результирующей таблицы, созданной при выполнении вложенного запроса. Все ограничения, указанные выше для первой формы оператора INSERT, применимы и в этом случае.
Оператор UPDATE позволяет изменять содержимое уже существующих строк указанной таблицы. Этот оператор имеет следующий формат:
UPDATE TableName
SET columnName1= dataValue1 [,columnName2= dataValue2…]
[WHERE searchCondition]
Здесь параметр TableNameпредставляет либо имя таблицы базы данных, либо имя обновляемого представления. В конструкции SET указываются имена одного или более столбцов, данные в которых необходимо изменить. Конструкция WHERE является необязательной. Если она опущена, значения указанных столбцов будут изменены во всехстроках таблицы. Если конструкция WHERE присутствует, то обновлены будут только те строки, которые удовлетворяют условию поиска, заданному в параметре searchCondition. Параметры dataValue1, dataValue2… представляют новые значения соответствующих столбцов и должны быть совместимы с ними по типу данных.
Оператор DELETE позволяет удалять строки данных из указанной таблицы. Этотоператоримеетследующийформат:
DELETE FROM TableName
[WHERE searchCondition]
Как и в случае операторов INSERT и UPDATE, параметр TableNameможет представлять собой либо имя таблицы базы данных, либо имя обновляемого представления. Параметр searchConditionявляется необязательным — если он опущен, из таблицы будут удалены всесуществующие в ней строки. Однако сама по себе таблица удалена не будет. Если необходимо удалить не только содержимое таблицы, но и ее определение, следует использовать оператор DROP TABLE. Если конструкция WHERE присутствует, из таблицы будут удалены только те строки, которые удовлетворяют условию отбора, заданному параметром searchCondition
В данном курсовом проекте для удобства доступа к данным также созданы запросы:
Запроснабаланс:
SELECT shelfs. quantity-selling. quantity AS quantity
FROM shelfs INNER JOIN selling ON shelfs. ID_shelf=selling. ID_shelf
WHERE selling. ID_selling = (SELECT MAX (ID_selling) FROM selling);
Запрос на Города с покупателями:
SELECT cities. cityName AS Город, COUNT (ID_client) AS [Количествоклиентов]
FROM clients INNER JOIN cities ON clients. clientCity=cities. ID_city
GROUP BY clients. ID_client, cities. cityName;
Запрос на города с поставщиками:
SELECT cities. cityName AS Город, COUNT (ID_diler) AS [Количествопоставщиков]
FROM dilers INNER JOIN cities ON dilers. dilerCity=cities. ID_city
GROUP BY dilers. ID_diler, cities. cityName;
Запрос на дату покупки товара:
SELECT ID_shelf AS Стеллаж, products. name AS Товар, shelfs. quantity AS Количество, shelfs. price AS Стоимость, shelfs. date AS [Дата покупки]
FROM shelfs INNER JOIN products ON products. ID_product=shelfs. ID_product;
Запрос на клиентов без покупки:
SELECT clients. clientName AS [Покупатели, не совершавшие покупки]
FROM clients
WHERE ID_client NOT IN (SELECT DISTINCT ID_client FROM Selling)
ORDER BY clientName;
Запрос на отчет по покупкам:
SELECT dilers. dilerName AS Поставщик, products. name AS Товар, buying. quantity AS [Количество товара], buying. sum*buying. quantity AS [Сумма сделки], buying. date AS [Дата сделки]
FROM (buying INNER JOIN dilers ON buying. ID_diler=dilers. ID_diler) INNER JOIN products ON buying. ID_product=products. ID_product;
Запрос на отчет по продажам:
SELECT clients. clientName AS Клиент, products. name AS Товар, selling. quantity AS [Количество товара], selling. sum*selling. quantity AS [Сумма сделки], selling. date AS [Дата сделки]
FROM ( (selling INNER JOIN clients ON selling. ID_client=clients. ID_client) INNER JOIN shelfs ON shelfs. ID_shelf=selling. ID_shelf) INNER JOIN products ON shelfs. ID_product=products. ID_product;
Запрос на поставщиков и закупки:
SELECT dilers. dilerName AS Поставщик, COUNT (ID_buying) AS [Количество сделок], SUM (buying. quantity*buying. sum) AS [Сумма всех сделок]
FROM dilers INNER JOIN buying ON dilers. ID_diler=buying. ID_diler
GROUP BY dilers. ID_diler, dilers. dilerName;
Запрос на поставщиков без поставок:
SELECT dilers. dilerName AS [Поставщики, не совершавшие поставок]
FROM dilers
WHERE ID_diler NOT IN (SELECT DISTINCT ID_diler FROM buying)
ORDER BY dilerName;
Запрос на продажи с клиентами:
SELECT clients. clientName AS Покупатель, COUNT (ID_selling) AS [Количествосделок], SUM (selling. quantity*selling. sum) AS [Суммавсехсделок]
FROM clients INNER JOIN selling ON clients. ID_client=selling. ID_client
GROUP BY clients. ID_client, clients. clientName;
Запрос на стоимость товаров на складе:
SELECT SUM (price*quantity) AS [Стоимость всех товаров на складе]
FROM shelfs;
Запрос на вставку обновлений продажи:
INSERT INTO selling (ID_client, ID_shelf, quantity, [sum])
SELECT ID_client, (SELECT ID_shelf FROM shelfs WHERE ID_shelf= (SELECT MAX (ID_shelf) FROM shelfs)), quantity, sum
FROM selling
WHERE ID_selling = (SELECT MAX (ID_selling) FROM selling);
Запрос на обновление товара (добавление):
INSERT INTO shelfs (ID_product, price, quantity)
SELECT ID_product, price, (SELECT shelfs. quantity-selling. quantity AS quantity FROM shelfs INNER JOIN selling ON shelfs. ID_shelf=selling. ID_shelf WHERE selling. ID_selling = (SELECT MAX (ID_selling) FROM selling))
FROM shelfs
WHERE ID_shelf = (SELECT ID_shelf FROM selling WHERE ID_selling = (SELECT MAX (ID_selling) FROM selling));
Запрос на обновление товара (удаление):
DELETE *
FROM shelfs
WHERE ID_shelf = (SELECT ID_shelf FROM selling WHERE ID_selling = (SELECT MAX (ID_selling) FROM selling));
Запрос на откат продажи:
DELETE *
FROM selling
WHERE ID_selling = (SELECT MAX (ID_selling) FROM selling);    продолжение
–PAGE_BREAK–
Запроснапокупкутовара:
INSERT INTO shelfs (ID_product, quantity, price)
SELECT ID_product, quantity, sum
FROM buying
WHERE ID_buying =
(SELECT MAX (ID_buying) FROM buying);
Запрос на удаление товара:
DELETE *
FROM shelfs
WHERE ID_shelf = (SELECT ID_shelf FROM selling WHERE ID_selling = (SELECT MAX (ID_selling) FROM selling));
Запрос на удаление старой продажи:
DELETE *
FROM selling
WHERE ID_selling = (SELECT MAX (ID_selling) — 1 FROM selling);
Почти все эти запросы можно увидеть на главной форме в виде таблиц при нажатии кнопки.
6. Инструкция администратору, инструкция пользователю
6.1 Инструкция администратору
Работать с нашей базой данных достаточно легко, зная основные свойства пакета Microsoft Office Access. Запуская наш курсовой проект, мы видим главную форму, на которой расположены различные кнопки, отвечающие за функции, указанные на них. Таким образом, можно достаточно легко работать с таблицами, отчетами и т.д. Если же необходимо что-то изменить в корне таблиц, то открываем их с помощью конструктора. Также в этом режиме можно создавать новые таблицы. При этом указываем имя поля, тип данных, и устанавливаем ключевой атрибут. Чтоб внести какие-либо данные в новую таблицу, необходимо открыть ее уже в режиме таблицы и заносить данные. Затем таблицу сохраняют, после чего успешно можно выполнять работу. Можно создавать также запросы, формы, отчеты, макросы для удобства работы с базой данных. Это все объекты базы данных, которыми можно с легкостью манипулировать. Желательно, чтоб в главной форме были кнопки всех таблиц, чтоб был кратчайший доступ к ним, но также, чтоб эти таблицы были в виде формы, чтоб можно было, используя кнопки, добавлять запись или удалять ее, что предусмотрено в курсовом проекте. Чтоб создать кнопку на форме, мы выбираем ее, отме6чаем на форме и назначаем в процессе ей какие-то функции. Запросы же пишем с помощью SQL.
6.2 Инструкция пользователю
Наша база данных создана так, что она с легкостью доступна не только программисту или человеку, который хорошо разбирается в компьютерах, а и простому пользователю. Дважды нажимаем на базу данных и видим главную форму, на которой расположено множество кнопочек, отвечающих за функции, указанные на них. Слева на форме указаны кнопки, отвечающие за таблицы. При нажатии на них у нас выпадают таблички, где можно добавлять или удалять компоненты, что также делается с помощью кнопок. Также мы можем увидеть на главной форме запросы на кнопках, также нажимаем их, где в следствии видим объединенные некоторые таблицы. Ниже можно открыть отчеты о покупках и продажах, что является очень удобным при работе. Справа внизу расположены кнопочки о программе, где можно посмотреть, кто создал программу, а также кнопки печати отчетов, что является простым в печатании отчетов на бумаге. Если необходимо просмотреть таблицы не в главной форме, а просто так, внести какие-то изменения, то открываем их в режиме таблиц в базе данных и изменяем то, что требуется. Итак, этим можно сказать, что с помощью этого курсового проекта можно элементарно просмотреть все данные, с легкостью проделать отчеты о выполненной работе, вносить изменения и делать корректировку данных.
Заключение
Проделав работу по созданию базы данных, можно подвести итог, что данная область IT — индустрии просто незаменима в создании серьезных проектов в любой сфере деятельности современных предприятий, фирм, заводов. Владея таким мощным средством как проектирование баз данных, языком запросов SQL, можно создавать гибкие, а самое главное, надежные информационные системы.
При проектировании информационных систем использование реляционной модели базы данных является самым подходящим методом. Нормализация отношений разработанной базы данных позволила устранить ошибки внесения, удаления, обновления, дублирования данных, что особенно важно при работе с базой данных пользователей непрофессионалов.
В ходе данной курсовой работы была разработана автоматизированная информационно-справочная система хранения и обработки информации оптового склада, которая способствует быстрому поиску необходимых данных при минимальных затратах времени.
Практическая реализация информационной системы, в основе которой лежит проектирование предметной области «Оптовый склад», и логической схемы БД, являющейся информационным ресурсом разрабатываемой системы, была выполнена с использованием СУБД Access, однако ее разработку можно было реализовать в любом другом коммерческом пакете реляционного типа. Разработанная база данных является законченным программным продуктом для поддержания информационных потребностей, и может быть легко расширена при изменении информационных потребностей пользователя без потери ранее занесенной информации.
Список использованных источников
1. Вейкас Д. Эффективная работа с Microsoft Access 2/ Перев. с англ. — СПб.: Питер, 1995. — 864 с.: ил.
2. Базы данных: модели, разработка, реализация/ Т.С. Карпова — СПб.: Питер, 2001. — 304 с.: ил.
3. Манфред Хоффбауер, Кристоф Шпильман Access: сотни полезных рецептов: пер. с нем. — К.: BHV, 1997 — 400 с