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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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