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

Посмотреть архив целиком


Задание


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

Предполагаются такие решения задач:

выдача информации об определенном товаре;

выдача информации о поставщиках;

выдача информации о покупателях;

закупка товаров

продажа товаров

Также реализованы такие задачи как:

добавление данных

удаление данных

редактирование данных

заключение сделок

некоторые запросы


Реферат


Объем пояснительной записки 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 Разработка реляционной модели базы данных


Реляционная база данных - это набор нормализованных отношений, которые различаются по именам.

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

Эти отношения обладают следующими характеристиками:

отношение имеет имя, которое отличается от имен всех других отношений в реляционной схеме;

каждая ячейка отношения содержит только одно элементарное (неделимое) значение;

каждый атрибут имеет уникальное имя;

значения атрибута берутся из одного и того же домена;

каждый кортеж является уникальным, т.е. дубликатов кортежей быть не может;

порядок следования атрибутов не имеет значения;

теоретически порядок следования кортежей в отношении не имеет значения; (Но практически этот порядок может существенно повлиять на эффективность доступа к ним)

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

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

поскольку отношение является множеством, то порядок элементов не имеет значения. Следовательно, порядок кортежей в отношении несуществен.

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

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

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

В объектно-реляционной модели отдельные записи база данных представляются в виде объектов. Между записями базы данных и функциями их обработки устанавливаются взаимосвязи с помощью механизмов, подобных соответствующим средствам в объектно-ориентированных языках программирования. Объектно-ориентированные модели сочетают особенности сетевой и реляционной моделей и используются для создания крупных БД со сложными структурами данных.

В реляционной модели все данные представляются как факты о сущностях и связях, это и понимают под основными свойствами. Сущность - это, например, человек, место, вещь, событие, концепция, о которых хранится информация. Сущности именуются обычно существительными, такими как "покупатель", "компьютер", "служащий", "продажа".

Более точно, сущность - это множество индивидуальных объектов - экземпляров, причем все эти объекты являются различными.

Связь - это функциональная зависимость между сущностями. Например, "служащий" совершает "продажи".

Каждая сущность обладает атрибутами. Атрибут - это свойство объекта, характеризующее его экземпляр. Сущность "служащий" может иметь атрибуты "имя", "дата рождения" и т.д.

Общепринятым видом графического изображения реляционной модели данных является 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 - Товары на складе


Форма о программе: