Информационная поддержка деятельности обувного магазина

Размещено на http://www.allbest.ru/

Задание

Задача - информационная поддержка деятельности Обувного магазина.

База данных должна содержать сведения об ассортименте обуви в магазине.

База данных должна осуществлять формирование запросов на выдачу следующей информации:

ь картинку изображающую этот вид обуви, наличие и стоимость обуви каждого артикула;

ь ассортиментный список дамской обуви с наименованием и имеющегося в наличии числа пар каждой модели;

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

ь список городов и фабрик, изготовляющих женскую (мужскую и детскую) обувь;

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

ь формат деловых писем на фабрику с просьбой о поставке определённого количества пар обуви данного ассортимента, если количество пар в магазине меньше заданного количества < 5.

Введение

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

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

С появлением ПК и использованием их для обработки информации появилась возможность автоматизировать различные сферы человеческой деятельности и производственных процессов.

Постепенно с развитием программного обеспечения ПК появились идеи создания СУБД, которые позволяли бы накапливать, хранить и обновлять взаимосвязанные данные по целому комплексу решаемых задач, например при автоматизации деятельности обувного магазина. Что позволит увеличить производительность магазина, уменьшение времени на обработку различных документов, проведение учёта в магазине и на складе, автоматическую отсылку писем по электронной почте поставщикам товара, а так же многой другой времеёмкой работы, которая представляет для человека большую нагрузку.

1. Этапы разработки баз данных

При разработке базы данных обычно выделяется несколько уровней моделирования, при помощи которых происходит переход от предметной области к конкретной реализации базы данных средствами конкретной СУБД. Можно выделить следующие уровни:

· Сама предметная область;

· Модель предметной области;

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

· Физическая модель данных;

· Собственно база данных и приложения;

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

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

Логическая модель данных. На следующем, более низком уровне находится логическая модель данных предметной области. Логическая модель описывает понятия предметной области, их взаимосвязь, а также ограничения на данные, налагаемые предметной областью. Примеры понятий - «магазин», «поставщик», «склад», «продажа». Логическая модель данных является начальным прототипом будущей базы данных. Логическая модель строится в терминах информационных единиц, но без привязки к конкретной СУБД. Более того, логическая модель данных необязательно должна быть выражена средствами именно реляционной модели данных. Основным средством разработки логической модели данных в настоящий момент являются различные варианты ER-диаграмм (Entity-Relationship, диаграммы сущность-связь). Одну и ту же ER-модель можно преобразовать как в реляционную модель данных, так и в модель данных для иерархических и сетевых СУБД, или в постреляционную модель данных. Однако, т.к. мы рассматриваем именно реляционные СУБД, то можно считать, что логическая модель данных для нас формулируется в терминах реляционной модели данных.

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

Физическая модель данных. На еще более низком уровне находится физическая модель данных. Физическая модель данных описывает данные средствами конкретной СУБД. Мы будем считать, что физическая модель данных реализована средствами именно реляционной СУБД, хотя, как уже сказано выше, это необязательно. Отношения, разработанные на стадии формирования логической модели данных, преобразуются в таблицы, атрибуты становятся столбцами таблиц, для ключевых атрибутов создаются уникальные индексы, домены преображаются в типы данных, принятые в конкретной СУБД.

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

При разработке физической модели данных возникают вопросы: хорошо ли спроектированы таблицы? Правильно ли выбраны индексы?

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

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

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

2. Концептуальное проектирование

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

2.1 Выделение сущностей с перечнем их атрибутов

база атрибут данные проектирование

Выделим базовые сущности этой предметной области:

ь Поставщики. Атрибуты поставщика - код товара, артикул товара, имя фабрики, срок поставки, фирма поставщик, горд поставщик, код поставщика.

ь Склад. Атрибуты склада - код товара, артикул товара, наименование товара, код поставщика.

ь Магазин. Атрибуты магазина - код поставщика, цена товара, наименование товара, артикул товара, код товара, количество в магазине, изображение товара.

ь Продажи. Атрибуты продажи - код товара, наименование товара, дата продажи, количество проданного, артикул проданного товара.

Описание связей данной предметной области:

1. Поставщики - Склад.

Между этими сущностями существует связь «поставляет».

Это связь между сущностью поставщик и сущностью склад. Сущность поставщики существует, не зависимо от сущности склад. В данной связи реализуется тип связи (1:М).

Рис. 2.1

2. Склад - Магазин.

Между этими сущностями существует связь «снабжает».

Будем рассматривать как связь между сущностью Склад и сущностью Магазин, в наличии склада имеется весь ассортиментный список поставляемого товара, но магазин не обязательно имеет в наличии весь ассортиментный список товара находящегося на складе. В данной связи реализуется (1:1) тип связи.

Рис. 2.2

3. Магазин - Продажи

Между этими сущностями существует связь «продаёт».

Это связь между сущностью магазин и продажи. В данной связи сущность магазин существует, не зависимо от продаж, а продажи без магазина существовать не могут. В данной связи реализуется тип связи (М:1).

Рис. 2.3

Построим ER - диаграмму соответствии с выделенными сущностями.

Рис. 2.4 Обобщенная ER - диаграмма БД обувного магазина

2.2 Анализ информационных задач и круга пользователей системы

Система создаётся для обслуживания следующих групп пользователей:

ь Администратор БД: имеет доступ ко всем данным, может изменять структуру базы данных и связи между отношениями. Устанавливает права доступа для всех остальных групп пользователей.

ь Менеджер и Директор магазина: имеют доступ для чтения всех данных.

ь Бухгалтер: имеет доступ для чтения и изменения БД.

ь Оператор: имеет доступ ко всем данным, но ни имеет права изменения структуры БД.

Определим границы информационной поддержки пользователей:

1. Функциональные возможности:

ь ведение БД (запись, чтение, модификация, удаление в архив);

ь обеспечение логической непротиворечивости БД;

ь обеспечение защиты данных от несанкционированного или случайного доступа (определение прав доступа);

ь реализация наиболее часто встречающихся запросов в готовом виде;

ь предоставление возможности сформировать произвольный запрос на языке манипулирования данными.

2. База данных содержит готовые запросы на выдачу следующей информации:

БД должна содержать сведения об ассортименте обуви в магазине.

БД должна осуществлять формирование запросов на выдачу следующей информации:

ь Изображение этого вида обуви, наличие и стоимость обуви каждого артикула;

ь Ассортиментный список дамской обуви с наименованием и имеющегося в наличии числа пар каждой модели;

ь Определение модели обуви, и её количества в магазине;

ь Список городов и фабрик, изготовляющих женскую (мужскую и детскую) обувь;

ь Количество пар обуви любого артикула и любого наименования с указанием сроков поставки;

ь Формат деловых писем на фабрику с просьбой о поставке определённого количества пар обуви данного ассортимента, если количество пар в магазине меньше заданного количества < 5.

3. Отчеты:

ь Магазин;

ь Поставщики;

ь Продажа;

ь Количество товара в магазине;

ь Склад;

3. Выбор СУБД

Анализ информационных задач показывает, что для реализации требуемых функций подходят почти все СУБД для ПК (FoxPro, MS Access и др.). Все они поддерживают реляционную модель данных и предоставляют разнообразные возможности для работы с данными.

Для реализации БД магазина наиболее эффективным будет использование СУБД MS Access, так как эта СУБД была изучена нами на практических занятиях по её изучению, она работает с реляционными БД, наиболее проста в описании данной БД, поддерживает язык запросов, также имеет более наглядный интерфейс. MS Access является частью стандартного пакета MS Office который очень широко распространён среди пользователей ПК.MS Access позволяет успешно применять данный пакет для решения практических задач

Microsoft Access - это функционально полная реляционная СУБД. В ней предусмотрены все необходимые вам средства для определения и обработки данных, а также для управления ими при работе с большими объемами информации. Что касается легкости использования, то Microsoft Access совершил здесь настоящий переворот, и многие для создания своих собственных баз данных и приложений обращаются именно к нему.

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

Microsoft Access предоставляет вам максимальную свободу в задании типа ваших данных (текст, числовые данные, даты, время, денежные значения, рисунки, звук, документы, электронные таблицы). Можете осуществлять вставку различных объектов, из Word, Excel. Вы можете задать также форматы хранения (длина строки, точность представления чисел и даты времени) и предоставления этих данных при выводе на экран или печать.

4. Логическое проектирование реляционной БД

4.1 Преобразование ER-диаграммы в схему базы данных

База данных создаётся на основании схемы базы данных. Для преобразования ER-диаграммы в схему БД приведём уточнённую ER-диаграмму.

Полученная схема реляционной базы данных (РБД) приведена на рисунке 4.

Рис. 4.3 Схема РБД, полученная из ER-диаграммы Обувного магазина.

4.2 Составление реляционных отношений

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

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

Потенциальным ключом отношения Поставщик является атрибут:
Имя поставщика. Этот атрибут уникален, поэтому для сущности Поставщик необходимо ввести суррогатный ключ - код поставщика.

Отношения приведены в табл. 1 - 3. Для каждого отношения указаны атрибуты с их внутренним названием, типом и длиной. Типы данных обозначаются так: N - числовой, C - символьный, D - дата (последний имеет стандартную длину, зависящую от СУБД, поэтому она не указывается).

Таблица 1. Схема отношения Поставщик.

Содержание поля	Имя поля	Тип	Примечания
Код поставщика	kod tovara	N(4)	ключевое поле
Наименование	Naumenovanie	C(50)	обязательное поле
Артикул	Artukul	C(50)	обязательное поле
Сроки поставки	Srok post	C(50)	обязательное поле

Таблица 2. Схема отношения Склад

Содержание поля	Имя поля	Тип	Примечания
Код товара	kod tovara	N(4)	ключевое значение
Код поставщика	kod postavchika	N(4)	вторичный ключ
Артикул	Artukul	C(50)	обязательное поле
Наименование	Naumenovanue	C(50)	обязательное поле
Количество на складе	kolvonacklade	N(4)	обязательное поле

Таблица 3. Схема отношения Магазин

Содержание поля	Имя поля	Тип, длина	Примечания
Код товара	kod tovara	N(4)	ключевое поле
Наименование	Naumenovanie	C(50)	обязательное поле
Артикул	Artukul	C(50)	обязательное поле
Цена	cena	D(4)	обязательное поле
Код поставщика	kodpostavchika	N(4)	обязательное поле
Кол-во в магазине	kol-vovmagazune	N(4)	обязательное
Изображение	Uzobrazenue	D(4)	не обязательное поле

Таблица 4. Схема отношения Продажи

Содержание поля	Имя поля	Тип	Примечания
Код товара	kod tovara	N(4)	Вторичный ключ
Наименование	kod postavchika	C(50)	обязательное поле
Артикул	Artukul	C(50)	обязательное поле
Кол-во проданного	kolvoprodgo	N(4)	обязательное поле
Дата	Data	D(4)	обязательное поле

4.3 Нормализация полученных отношений (до 3НФ)

Первая нормальная форма(1НФ).

БД находится в 1НФ если соблюдены два условия:

ь Атомарность атрибутов.

ь Все таблицы являются отношениями.

Для приведения таблиц к 1НФ требуется составить прямоугольные таблицы (один атрибут - один столбец) и разбить сложные атрибуты на простые, а многозначные атрибуты вынести в отдельные отношения.

Первоначально, по условию задания атрибут Артикул должен давать представление о наименовании поставляемого товара, имя поставщика, город поставщика и название фабрики изготовителя. Если атрибут артикул реализовать через поле MEMO, это было бы проще, но при осуществлении работы с полями могут возникнуть проблемы, будет трудоемко, например, осуществить поиск по городу поставщику. Поэтому в отношении Поставщик целесообразно разбить атрибут Артикул на атрибуты: имя поставщика, город поставщика, фабрика изготовитель. После разбиения атрибута Артикул на отдельные поля, станет проще осуществлять обработку данных полей.

Вторая нормальная форма(2НФ).

БД находится в 2НФ если соблюдены два условия:

ь БД должна находится в 1НФ;

ь Каждый не ключевой атрибут должен функционально зависеть от всего первичного ключа.

В данной Базе Данных во всех отношениях каждый не ключевой атрибут функционально зависит от первичного ключа. Таким образом, можно сделать вывод, что БД находится в 2НФ.

Третья нормальная форма(3НФ).

БД находится в 3НФ если соблюдены два условия:

ь БД находится в 2НФ;

ь Если внутри одного отношения между не ключевыми атрибутами нет транзитивных зависимостей, анализ всей базы данных показал что, ни в одном отношении не существуют транзитивные зависимости между не ключевыми атрибутами. Отсюда можно сделать вывод, что БД находится в 3НФ.

В данной БД во всех отношениях между не ключевыми атрибутами нет транзитивных зависимостей. Таким образом, можно сделать вывод, что БД находится в 3НФ.

Окончательные схемы отношений базы данных с указанием ключей и других ограничений целостности приведены в табл. 5-8.

Таблица 5. Схема отношения Поставщик

Содержание поля	Имя поля	Тип	Примечания
Код поставщика	kod tovara	N(4)	ключевое поле
Наименование	Naumenovanie	C(50)	обязательное поле
Артикул	Artukul	C(50)	обязательное поле
Имя поставщика	Umjapost	C(50)	уникальное поле
Город	Gorodpos	C(50)	обязательное поле
Фабрика	Fabrika	C(50)	обязательное поле
Сроки поставки	Srok post	C(50)	обязательное поле

Таблица 6. Схема отношения Склад

Содержание поля	Имя поля	Тип	Примечания
Код товара	kod tovara	N(4)	ключевое значение
Код поставщика	kod postavchika	N(4)	вторичный ключ
Артикул	Artukul	C(50)	обязательное поле
Наименование	Naumenovanue	C(50)	обязательное поле
Количество на складе	kolvonacklade	N(4)	обязательное поле

Таблица 7. Схема отношения Магазин

Содержание поля	Имя поля	Тип, длина	Примечания
Код товара	kod tovara	N(4)	ключевое поле
Наименование	Naumenovanie	C(50)	обязательное поле
Артикул	Artukul	C(50)	обязательное поле
Цена	Cena	D(4)	обязательное поле
Код поставщика	kodpostavchika	N(4)	обязательное поле
Кол-во в магазине	kol-vovmagazune	N(4)	обязательное
Изображение	Uzobrazenue	D(4)	не обязательное поле

Таблица 8. Схема отношения Продажи

Содержание поля	Имя поля	Тип	Примечания
Код товара	Kod tovara	N(4)	Вторичный ключ
Наименование	Naumenovanie	C(50)	обязательное поле
Артикул	Artukul	C(50)	обязательное поле
Кол-во проданного	kolvoprodgo	N(4)	обязательное поле
Дата	Data	D(4)	обязательное поле

4.4 Определение дополнительных ограничений целостности

Перечислим ограничения целостности, которые не указаны в табл. 5-8.

1. Значения всех числовых атрибутов - больше 0 (или null, если атрибут необязателен).

2. В отношении Склад атрибут Количество на складе может принимать значения только больше ноля.

4.5 Описание групп пользователей и прав доступа

Опишем для каждой группы пользователей права доступа к каждой таблице и к каждому полю (атрибуту).

ь Администратор БД: имеет доступ ко всем данным, может изменять структуру базы данных и связи между отношениями. Устанавливает права доступа для всех остальных групп.

ь Менеджер и Директор магазина: имеют доступ по чтению ко всем данным.

ь Бухгалтер: имеет доступ по чтению и изменению данных БД.

Оператор: имеет доступ ко всем данным, но ни имеет права изменения структуры БД.

5. Физическое проектирование

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

Для определения объёма внешней и оперативной памяти, требующийся для функционирования СУБД, выполнения этого этапа необходимо знать (хотя бы ориентировочно) объём работы магазина (т.е. количество товара в магазине, цена, наименование), а также иметь представление о характере и интенсивности запросов.

Объём внешней памяти, необходимый для функционирования системы, складывается из двух составляющих: память, занимаемая модулями СУБД (ядро, утилиты, вспомогательные программы), и память, отводимая под данные (М_Д). Наиболее существенным обычно является М_Д. Объём памяти М_Д, требуемый для хранения данных, можно приблизительно оценить по формуле

,

где l_i - длина записи в i-й таблице (в байтах), N_i - примерное (максимально возможное) количество записей в i-й таблице, N_a - количество записей в архиве i-й таблицы. Коэффициент 2 перед суммой нужен для того, чтобы выделить память для хранения индексов, промежуточных данных, для выполнения объёмных операций (например, сортировки) и т.п.

Посчитаем приблизительно, какой объём внешней памяти потребуется для хранения данных. Примем ориентировочно, что:

· в день принимается около 3 поставок на склад (по 0,4К);

· примерно около 5 единиц товара (по 0,5К на каждого);

· около 20 разновидностей цен (по 0,2К);

Тогда объём памяти для хранения данных за первый год примерно составит:

M_c = 2*(3*0,4+5*0,5+20*0,2)+200*(7*0,4)) = 575.4 К

где 200 - количество рабочих дней в году, а 12 мес./2 мес. = 6. Объём памяти будет увеличиваться ежегодно на столько же при сохранении объёма работы.

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

6. Реализация проекта базы данных

1. База данных запускается вызовом главной формы, которая имеет следующий вид:

Рис. 6.1. Главная форма

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

Вкладка Просмотр записей позволяет просмотреть данные по поставщикам (Рис. 6.1), магазину (Рис. 6.2), складу (Рис. 6.3) и продажам (Рис. 6.4). Формы данной вкладки предназначены для просмотра данных, без их изменения.

6.1 Вкладка Магазин

Рис. 6.2 Вкладка магазин.

6.2 Вкладка Склад

Рис. 6.3 Вкладка склад

6.3 Вкладка Продажи

Рис. 6.4 Вкладка Продажи

2. Вкладка добавления записей предназначена для добавления, редактирования и удаления записей БД. Она содержит в себе вкладки: поставщики, склад, магазин, продажи.

Рис. 6.5 Вкладка добавление записей

3. Вкладка запросы предназначена для просмотра запросов БД.

Данная вкладка содержит запросы на вывод следующей информации:

3.1 Список городов изготовителей (Приложение1, Рис1);

3.2 Вывод ассортимента дамской обуви (Приложение1, Рис2);

3.3 Определения количества обуви в магазине (Приложение1, Рис3;

3.4 Вывод сроков поставки обуви (Приложение1, Рис. 4);

3.5 Отправка деловых писем поставщикам, если количество обуви <5 (Приложение1, Рис5);

3.6 Вывод отчёта по магазину (Приложение1, Рис. 6);

Вкладка запросы

4. Вкладка отчёты предназначена для просмотра отчётов БД.

Данная вкладка содержит отчёты на вывод следующей информации:

4.1 Отчёта по магазину (Приложение1, Рис. 7);

4.2 Отчёта по продажам (Приложение1, Рис. 8);

4.3 Отчёта по склад (Приложение1, Рис9);

4.4 Отчёта по поставщикам (Приложение1, Рис10);

Вкладка Отчёты

Заключение

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

БД позволяет:

ь создавать и хранить информацию о поставщиках;

ь проверять данные на корректность;

ь создавать разнообразные отчёты;

ь обеспечивает быстрый доступ к любой необходимой информации;

ь повысить работоспособность обувного магазина;

ь избегать дублирование информации;

БД имеет удобный интерфейс, позволяющий пользователю работать более эффективней и производительней, по сравнению с работой с бумажными документами.

Размещено на Allbest.ru