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

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

Содержание

• Введение
• 1. Описание функционирования магазина напольных покрытий
• 2. Постановка задачи
• 3. Проектирование системы
• 3.1 Инфологическое моделирование предметной области
• 3.1.1 Построение диаграммы потоков данных
• 3.2 Выбор модели представления данных
• 3.2.1 Иерархическая модель данных
• 3.2.2 Сетевая модель данных
• 3.2.3 Реляционная модель данных
• 4. Программная реализация системы
• 4.1 Обоснование выбора СУБД
• 4.2 Описание таблиц
• 4.3 Проектирование пользовательского интерфейса
• 4.3.1 Уровни доступа к БД
• 4.3.2 Модель пользовательского интерфейса
• 4.6 Архивация, восстановление и резервное копирование БД
• Выводы
• Приложение А. Техническое задание
• Перечень обозначений, символов, единиц, сокращений и терминов
• БД - база данных
• СУБД - система управления базой данный
• РМД - реляционная модель данных
• ПО - программное обеспечение
• ДПД - диаграмма потоков данных
• SQL ? Структурированный язык запросов
• Введение
• XXI век - век расцвета компьютерных технологий, так как информация является важнейшим фактором жизни общества. С каждым годом поток информации возрастает, и ее приходится систематизировать, выбирать самую нужную, затратив на это как можно меньше времени. А это возможно с помощью компьютерных средств.
• В настоящее время более удобно хранить и обрабатывать информацию в электронном виде, так как она доступна для пользователя в любое время, ее можно изменять и дополнять, учитывая потребности современности, она занимает мало места, не приходится работать с большим количеством бумажных дел. С каждым днем появляется множество новых программных приложений, позволяющих обеспечивать ее качественное хранение и обработку.
• Хранить информацию, какой- либо определенной области, можно путем использования базы данных. Она удобна в работе, ее можно применять для различных целей, она позволяет контролировать дублирование данных, чем позволяет сокращать объем занимаемой памяти.
• База данных, или файл базы данных представляют собой набор данных из определенной предметной области. База данных содержит все таблицы, запросы, отчеты, формы и другие структурные элементы. Вместо того, чтобы хранить данные на диске отдельно, где их можно потерять, забыть или просто стереть, они группируются и хранятся в одном общем файле.
• Во многих больших магазинах строительных материалов хранится большое количество информации о покрытиях, поэтому проектируемая СУБД станет незаменимым помощником для облегчения работы руководства и работающего персонала строительного магазина. На данный момент использование такой СУБД очень актуально.
• В данной работе будет разработана БД магазина напольных покрытий которая реализует все перечисленные выше свойства, которые помогут в работе данного магазина.

1. Описание предметной области

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

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

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

Поставщик => магазин=> покупатель

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

1. о категории и группе товаров, т.к. покупателя всегда интересует определенный тип продуктов, который он хотел бы приобрести;

2. о цене, т.к. при покупке продуктов покупатель рассчитывает на определенную сумму, которую сможет потратить;

3. о фирме производителе, т.к. в наше время потребители чаще покупают продукцию известных марок, чем неизвестных;

4. о доступном количестве продукции на складе, т.к. покупателю не понравится, если он будет ждать, а так все сразу ясно есть она или нет;

5. о стране производителя, т.к. в каждой стране производится продукция разного качества.

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

Немаловажное значение имеет удобство доступа покупателя к товару и получение информации о товаре.

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

1. поддержание достаточной полноты и стабильности ассортимента;

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

3. повышение скорости обслуживания;

4. снижение количества не покупаемых товаров;

5. быстрая переоценка, например, в связи с изменением закупочных цен на товар.

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

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

2. Постановка задачи

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

Для функционирования Б.Д. магазина необходима информация о персонале, ассортименте, производителе

Данная БД использует информацию о персонале. Она состоит из таких данных:

Должность, ФИО, табельный номер, год рождения, пол, образование, оклад, ставка.

Данные об ассортименте будут хранить информацию о количестве того или иного товара в хранилище характеристики данного товара.

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

Задачи которые необходимо выполнить при проектировании базы данных данной предметной области:

1. Исследовать предметную область магазина напольных покрытий.

2. Построить диаграмму «сущность - связь» данной предметной области.

3. Построить иерархическую модель данных.

4. Построить сетевую модель данных.

5. Построить реляционную модель данных.

6. Выбор СУБД.

7. Описание таблиц исследуемой предметной области.

8. Создание интерфейса.

9. Реализация функционирования приложения.

10. Организация взаимодействий компонентов системы.

11. Написание руководства пользователю и инструкции по занесению данных.

12. Написание пояснительной записки курсового проекта.

Функциональными требованиями проектируемой базы данных являются:

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

· содержание запросов для получения информации об анализе полученной прибыли, о продажах по поставщикам, о персонале, оказываемом данную услугу;

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

· содержание необходимых запросов, формы и отчетов для обработки существующей информации;

· контроль, сохранность и достоверность существующей информации;

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

3. Концептуальное проектирование СУБД

3.1 Инфологическое моделирование предметной области

Наиболее удобной формой представления информации при анализе предметной области являются графические диаграммы различного рода. На практике при проведении структурного анализа чаще всего используют следующие диаграммы:

? диаграмма потоков данных ДПД, DFD;

? диаграммы «сущность - связь» ERD;

? диаграммы переходов состояний STD.

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

3.1.1 Построение диаграммы потоков данных

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

Диаграмма потоков данных изображена на рисунке 3.1.



Рисунок 3.1- Начальная контекстная диаграмма

В таблице 3.1 приведено соответствие потоков данных на диаграммах двух уровней.

Таблица 3.1 - Соответствие потоков данных на диаграммах

Потоки на диаграмме верхнего уровня	Потоки на диаграмме нулевого уровня
Информация от покупателя	Запрос на имеющийся товар
Информация для покупателю	Ответ на запрос
информация от продавца	ответ на запрос о продажах, данные о продавце
информация для продавца	запрос о продажах
информация поставщику	запрос на поставку продукции
информация от поставщика	ответ на запрос поставки продукции, данные о поставщике

3.2 Обоснование выбора модели данных

Существует три типа модели данных: иерархическая, сетевая и реляционная. Рассмотрим каждый тип модели данных.

3.2.2 Сетевая модель данных

В сетевой модели связи описываются с помощью графа, поэтому все элементы связаны друг с другом.

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

Сетевая модель данных для предметной области «Строительный магазин» приведена на рисунке 3.4.

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

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

Рисунок 3.4 - Сетевая модель данных

3.2.3 Реляционная модель данных

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

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

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

3.3 Схема «объект-отношение»

Данная схема содержит 5 объектов, 16 свойств и 4 отношения. Выбраны основные объекты для данной предметной области.

Объект «Производитель» связан с объектом «Покрытие » как один ко многим, так один производитель может выпускать несколько видов покрытий и один вид покрытия может принадлежать только одному производителю.

Объект «Покрытие » и связан как один ко многим с объектом «Ассортимент», так как в одном объекте покрытие может расположатся несколько ассортиментов и в связи с специализацией магазине ничего кроме покрытия быть не может. Также объект «Покрытие » связан с объектом «Вид покрытия», связан как многие к одному, так как к покрытию может относится множество видов покрытий и к конкретный вид покрытия относится только к одному покрытию

Объект «Вид покрытия связан с объектами «Ассортимент».

Объект «Ассортимент связан как многие ко многим с объектом продавец, так как один ассортимент могут продавать несколько продавцов и один продавец может торговать несколькими ассортиментами товара.

Схема объект-отношение представлена на рисунке 3.6. Эта схема наглядно представляет все свойства и отношения в БД для данной предметной области.

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

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

Рис. 3.6 Схема объект-отношение

4. Программная реализация системы

4.1 Обоснование выбора СУБД

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

В настоящее время существует множество различных СУБД, наиболее известные из которых являются: Microsoft Access, dBase, FoxPro, Paradox, ИНЕС, СЕТОР, ПАЛЬМА и другие. Проведем небольшой обзор самых популярных.

Visual FoxPro отличается высокой скоростью, имеет встроенный объектно-ориентированный язык программирования с использованием xBase и SQL, диалекты которых встроены во многие СУБД. Имеет высокий уровень объектной модели. При использовании в вычислительных сетях обеспечивает как монопольный, так и раздельный доступ пользователей к данным. Применяется для приложений масштаба предприятия для работы на различных платформах: Windows 3.x, Windows 95, Macintosh... Минимальные ресурсы ПК: для Visual FoxPro версии 3.0 - процессор 468DX, Windows 3.1, 95, NT, объем оперативной памяти 8 (12) Мб, занимаемый объем на ЖМД 15-80 Мб, а для Visual FoxPro версии 5.0 (выпущена в 1997 году) - Windows 95 или NT, 486 с тактовой частотой 50 МГц, 10 Мб ОЗУ, от 15 до 240 Мб на ЖМД.

Access входит в состав самого популярного пакета Microsoft Office. Основные преимущества: знаком многим конечным пользователям и обладает высокой устойчивостью данных, прост в освоении, может использоваться непрофессиональным программистом, позволяет готовить отчеты из баз данных различных форматов. Предназначен для создания отчетов произвольной формы на основании различных данных и разработки некоммерческих приложений. Минимальные ресурсы ПК: процессор 468DX, Windows 3.1, 95, NT, объем оперативной памяти 12 (16) Мб, занимаемый объем на ЖМД 10-40 Мб.

SQL Server - сервер баз данных, реализует подход "клиент-сервер" и взаимодействует с указанными пакетами. Главные достоинства: высоая степень защиты данных, мощные средства для обработки данных, высокая производительность. Область применения: хранение больших объемов данных, хранение высокоценных данных или данных, требующих соблюдения режима секретности. Минимальные ресурсы ПК: процессор 468DX-33МГц, Windows NT, объем оперативной памяти 16 (32) Мб, занимаемый объем на ЖМД 80 Мб.

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

Учитывая проработанные СУБД в данном курсовом проекте я буду использовать Microsoft Access.

4.2 Описание таблиц

Схема данных «Магазин напольных покрытий» была построена в Microsoft Access посредством создания таблиц и установления связей между ними.

Схема данных БД «Магазин напольных покрытий» представлена на рисунке4.1.



Рисунок 4.1 -Схема данных БД

Между таблицами установлены связи 1??. Во всех связях присутствует обеспечение целостности данных. Каскадное удаление не установлено в связи между «Страна» и «Производитель» так как при переименовании страны мы не прекращаем работы с производителем. Во всех остальных связях есть каскадное удаление, т.е. при прекращении работы с производителем мы уже не можем предоставлять покрытие их производства, при удалении какого-то покрытия оно уже не должно присутствовать в ассортименте, а при удаление записи из ассортимента продавец уже не может продать его и т. д.

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

Таблица «Ассортимент» показана на рисунке 4.2.

Рисунок 4.2 - Таблица «Ассортимент»

Таблица «Ассортимент» содержит информацию о доступной продукции.

Код ассортимента - тип счетчик, первичный ключ, содержит уникальные значения без повторений.

Артикул-тип текстовый, размер 7 символов, поле обязательное, пустые строки не допускаются, индексированное(совпадения не допускаются), маска ввода-« LLL0000».

Цена - тип текстовый, маска ввода «!####,## грн», условие на значение «>=0», сообщение об ошибке - «Неверный формат», обязательное поле, не индексировано

Начальное количество-тип числовой, размер 5, маска ввода «#####», значение по умолчанию «0», условие на значение «>=0», обязательное поле, не индексировано.

Код покрытия - тип числовой,обязательное поле, подстановка из таблицы «Покрытие» связь по полю код покрытия, подпись «покрытие», отображается таблица « Производителя и название продукта ».

Таблица «Вид покрытия» показана на рисунке 4.3.

Рисунок 4.3 - Таблица «Вид покрытия»

Таблица «Вид покрытия» содержит информацию о названии вида покрытия

Код вида покрытия - тип счётчик, первичный ключ, содержит уникальное значение без повторений.

Название вида - размер 15, тип текстовый, обязательное поле, индексированное поле (без повторений).

Таблица «Покрытие» показана на рисунке 4.4.

Рисунок 4.4 - Таблица «Покрытие»

Таблица «Покрытие»- содержит информацию о покрытии

Код покрытия - тип счётчик, первичный ключ, содержит уникальное значение без повторений.

Название продукта - тип текстовый, размер 10 символов, обязательное поле, индексированное (без повторений),

Ширина - тип числовой, размер 5 цифр, маска ввода «###,## », условие на значение «>=0», сообщение об ошибке «Значение должно быть положительным и состоять из цифр », обяз. поле, индексировано (допускаются)

Толщина-- тип числовой, размер 4 цифр, маска ввода «##,## », условие на значение «>=0», сообщение об ошибке «Значение должно быть положительным и состоять из цифр », обяз. поле, индексировано (допускаются).

Длинна - тип числовой, размер 5 цифр, маска ввода «###,## », условие на значение «>=0», сообщение об ошибке «Значение должно быть положительным и состоять из цифр », обяз. поле, индексировано (допускаются).

Тип модели- тип числовой, обязательное поле, подстановка из таблицы «Тип модели» связь по полю «Код типа модели», подпись «тип модели», отображает название типа модели

Класс- тип числовой, обязательное поле, подстановка из таблицы «Производитель» связь по полю «Код производителя», подпись «производитель», отображает название производителя

Код производителя -тип числовой, обязательное поле, подстановка из таблицы «Производитель» связь по полю «Код производителя», подпись «производитель», отображает название производителя.

Код вида покрытия - тип числовой, обязательное поле, подстановка из таблицы «Вид покрытия » связь по полю «Код вида покрытия», подпись «Вид покрытия», отображает название вида покрытия.

Таблица «Продавец» показана на рисунке 4.5.

Рисунок 4.5 - Таблица «Продавец»

Таблица «Продавец» отображает информацию о продавце

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

Ф.И.О.- тип текстовый, размер 35 символов, обязательное поле, индексированное нет

Табельный номер- тип текстовый, размер 9 символов, обязательное поле, индексированное нет.

Таблица «Продаёт» показана на рисунке 4.6.



Рисунок 4.6 - Таблица «Продаёт»

Таблица «Продаёт» хранит информацию о количестве проданных товаров в определённое время и конкретным продавцом

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

Код ассортимента - тип числовой, обязательное поле, подстановка из таблицы «Ассортимент и Покрытие» связь по полю «Код ассортимента», подпись «Ассортимент», отображает артикул, название и цену.

Код продавца- тип числовой, обязательное поле, подстановка из таблицы «Продавец» связь по полю «Код продавца», подпись «Продавец», отображает Ф.И.О. продавца.

Дата-тип дата/время,краткий формат, маска ввода «00.00.0000;0;_»,условие на значение «Date()», обязательное поле.

Количество-числовой, поле целого типа обязательное поле, условие на значение «>=0», значение по умолчанию «0».

Таблица «Производитель» показана на рисунке 4.7.

Рисунок 4.7 - Таблица «Производитель»

Таблица «Производитель»-содержит информацию о производителе.

Код производителя- тип счётчик, первичный ключ, содержит уникальное значение без повторений.

Название марки- тип текстовый, размер 11 символов, обязательное поле, индексированное(нет)

Код страны - тип числовой, обязательное поле, подстановка из таблицы «Страна» связь по полю «Код страны », подпись «Страна», отображает название страны.

Справочная таблица «Страна» показана на рисунке 4.8.

Рисунок 4.8 - Справочная таблица «Страна»

Таблица «Страна» справочная таблица.

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

Название страны- тип текстовый, размер 25 символов, не обязательное поле, индексированное (нет).

Справочная таблица «Класс» показана на рисунке 4.9.

Рисунок 4.9 - Справочная таблица «Класс»

Таблица «Класс» справочная таблица.

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

Класс- тип текстовый, размер 10 символов, не обязательное поле, индексированное (нет).

Справочная таблица «Тип модели» показана на рисунке 4.10.

Рисунок 4.10 - Справочная таблица «Тип модели»

Таблица «Тип модели» справочная таблица.

Код типа модели- тип счётчик, первичный ключ, содержит уникальное значение без повторений.

Тип модели- тип текстовый, размер 12 символов, не обязательное поле, индексированное (нет).

4.3 Проектирование пользовательского интерфейса

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

При проектировании выделяют аспекты, приведенные ниже.

1. Для кого и для чего предназначена разрабатываемая система. Кто ее основной пользователь, и какие задачи пользователя она решает. С какими целями создается база и какие задачи стоят перед ней. Что является важным, а что второстепенным в разработке данной программы.

2. Что должно быть в системе и что она должна уметь программа. Какие возможности она предоставляются пользователю, и какие функции нужны для этого.

3.Как выглядит и работает система. Как распределить функции системы по конкретным страницам и какова их последовательность.

4.3.1 Уровни доступа к БД

Уровни доступа -- определенный комплекс функций, доступный для выполнения пользователем. Они предназначены для создания системы управления пользователями. Уровни доступа определяются администратором. Могут быть созданы и изменены. Обладают свойством «наследования», то есть если для текущего раздела/страницы явно не задан уровень прав, тогда устанавливается то право, которое задано для вышележащего раздела.

В разработанной базе данных 3 уровня доступа: администратор продавец и менеджер.

Менеджер - сотрудник магазина, которому доступны все вилы работ кроме изменения структуры БД.

Продавец - сотрудник магазин, ему доступно просмотр, поиск и добавление новой записи.

Администратор - сотрудник магазина, которому доступен просмотр, редактирование и внесение новых данных в базу, а также сам доступ к БД.

При входе в пользовательскую базу необходимо ввести пароль продавцу не доступно изменение, и редактирование данных, а возможен лишь просмотр информации и добавление продажи.

Пользователю доступны только отчет прайс-лист, продажи по поставщикам, отчёт об ассортименте.

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

Несколько уровней доступа необходимы для безопасного хранения личной информации о клиентах и мастерах. Форма доступа к базе данных имеет вид (рис.4.11):

Рисунок 4.11 - Форма «Уровни доступа»

4.3.2 Модель пользовательского интерфейса

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

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

Форма предоставляет возможности для:

? ввода и просмотра информации базы данных;

? изменения данных;

? печати;

? создания сообщений.

Для магазина напольных покрытий были разработаны определенные формы.

При входе в пользовательскую базу продавец может просмотреть форму(рис.4.12):

Рисунок 4.12 - Форма «Главная_польз»

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

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



Рисунок 4.13 - Форма «Меню с правами администратора»

Администратору магазина напольных покрытий доступны все данные, он имеет возможность внесения и редактирования данных. На приведенной форме расположены кнопки: бланк, ассортимент, продавец, добавить продажу, покрытие, открыть отчёты, продажи, закрыть, дополнения, о программе. Рассмотрим каждую позицию более детально.

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

Рисунок 4.28 - Форма «Покрытие»

Рисунок 4.29 - Форма «продаёт»

Даная форма служит для добавления новых продаж.

Рассмотрим позицию «Открыть отчёты» (рис.4.30)

Рисунок 4.30 - Форма «Отчёты»

В данной форме сосредоточены все доступные отчёты, что упрощает поиск и работу с ними. Существует возможность распечатать каждый

Перейдём к позиции Дополнения (рис.4.31):

Рисунок 4.31 - Форма «Справка»

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

Форма справка (рис.4.32) содержит справочные таблицы а так-же информацию о то как заполнять БД. В данной форме содержится 3 справочных формы.

Рисунок 4.32 - Форма «Помощь»

Рисунок 4.33 - Форма «Должность»

Рисунок 4.34 - Форма «Страна»

Рисунок 4.35 - Форма «Касс1»

Форма «Продаёт1 » (рис.4.36) предназначена для внесения новой записи.

Рисунок 4.36 - Форма «Продаёт1»

Форма «Остаток на складе» предназначена для просмотра остатка на складе. (рис.4.37)

Рисунок 4.37 - Форма «Остаток на складе»

Для удобства выбора необходимого покрытия создана форма «Подчинение по стране». (рис.4.38)

Рисунок 4.38 - Форма «Остаток на складе»

4.4 Описание запросов

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

Опишем использованные запросы.

Для создания формы «Продаёт» используется следующий запрос:

SELECT Продавец.[Код продавца], Продавец.ФИО, Ассортимент![цена м2]*Продаёт!Количество AS Выражение1, Продавец.[Табельный номер]

FROM Ассортимент INNER JOIN (Продавец INNER JOIN Продаёт ON Продавец.[Код продавца] = Продаёт.[код продавца]) ON Ассортимент.[Код ассортимента] = Продаёт.[Код ассортимента];

Для создания формы «Продажи» используется следующий запрос:

SELECT Ассортимент.Артикул, Покрытие.[Название продукта], Покрытие.[Тип модели], Покрытие.Класс, Производитель.[Название марки], Ассортимент.[цена м2], Ассортимент.Цвет, Ассортимент.[Начальное количество], Продаёт.Дата, Продаёт.[код продавца], Продавец.ФИО

FROM Производитель INNER JOIN (Продавец INNER JOIN ((Покрытие INNER JOIN Ассортимент ON Покрытие.[Код покрытия] = Ассортимент.[Код покрытия]) INNER JOIN Продаёт ON Ассортимент.[Код ассортимента] = Продаёт.[Код ассортимента]) ON Продавец.[Код продавца] = Продаёт.[код продавца]) ON Производитель.[Код производителя] = Покрытие.[Код производителя];

4.5 Описание отчетов

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

1. Продавец

Отчет построен на основе таблицы «Продаёт».

Предназначен для просмотра продаж конкретным продавцом за определенный период.

2. Прайс лист

Отчёт построен на основе запроса «Прайс».

Отчёт предназначен для выбора товара по определённой ценовой отметке.

3. Покрытие

Отчёт основан на таблице «Покрытие».

Отчет предназначен для просмотра какое покрытие есть в ассортименте

4. Продажи по поставщикам

Отчёт построен на основе запроса «Продажи по поставщикам»

Предназначен для просмотра самых продаваемых производителей и товаров.

5. Продавцы

Отчёт построен на основе таблицы «Продавец»

Предназначен для просмотра списка продавцов со всеми данными

4.6 Архивация, резервное копирование и восстановление данных БД

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

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

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

Для удобной работы архивации будем использовать макрос «архив дата» (рис. 4.39)

Рисунок 4.,9 - Макрос «Архив дата»

Для работы макроса «Архив дата» используется следующие запросы:

Первый запрос записывает днанные в архивную таблицу:

INSERT INTO Архив_Продаёт ([Код продаёт], [Код ассортимента], [код продавца], Количество, Дата)

SELECT Продаёт.[Код продаёт], Продаёт.[Код ассортимента], Продаёт.[код продавца], Продаёт.Количество, Продаёт.Дата

FROM Продаёт

WHERE (((Продаёт.Дата)<[Архивировать транзакции, выполненные до:]));

Второй запрос удаляет из искомой таблицы занесённые в архив данные:

DELETE Продаёт.[Код продаёт], Продаёт.Дата, Продаёт.[код продавца], Продаёт.Количество, Продаёт.[Код ассортимента]

FROM Продаёт

WHERE (((Продаёт.Дата)<[Архивировать транзакции, выполненные до:]));

Для работы кнопки «Восстановление» используется следующий запрос:

INSERT INTO Продаёт ([Код продаёт], [Код ассортимента], [код продавца], Дата, Количество)

SELECT Архив_Продаёт.[Код продаёт], Архив_Продаёт.[Код ассортимента], Архив_Продаёт.[код продавца], Архив_Продаёт.Дата, Архив_Продаёт.Количество

FROM Архив_Продаёт

WHERE (((Архив_Продаёт.Дата)<[Востановить продажи, выполненные до:]));

Макрос "Востоновление"(рис 4.40).

Рисунок 4.40 - Макрос «Восстановление»

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

INSERT INTO Продаёт ([Код продаёт], [Код ассортимента], [код продавца], Дата, Количество)

SELECT Архив_Продаёт.[Код продаёт], Архив_Продаёт.[Код ассортимента], Архив_Продаёт.[код продавца], Архив_Продаёт.Дата, Архив_Продаёт.Количество

FROM Архив_Продаёт

WHERE (((Архив_Продаёт.Дата)<[Востановить продади, выполненные до:]));

информационная система магазин

Макрос «Резервное копирование» необходим для сохранения определенных данных. Содержит макрокоманды «Копировать объект». Копирует указанные данные и сохраняет в новую базу копии указанных таблиц. Относится к категории «Работа с объектами», назначение копирование, переименование и сохранение объекта (рис.4.41):

Рисунок 4.41 - Макрос «Резерв»

4.7 Описание функционирования приложения

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



Все разработанные формы, таблицы, запросы, макросы напрямую взаимодействуют между собой. Главная форма с паролем взаимодействует с формами клиентская база и административная база. В свою очередь с формой "МЕНЮ" связаны "Магазины", "Клиенты", "Накладная", "Поставщики", "Сотрудники", "Товар", сервисные функции, "Справочники". Форма "Данные о магазине" связана с формой "Сотрудники". Форма "Клиенты" связана с формой "Добавления нового клиента". Форма "Накладная" содержит связана с формой "Добавить заказ" и справочниками "Добавить город", "Добавить тип батареи","Добавить тип корпуса".

Форма «Поставщики» взаимодействует с формой «Добавить нового поставщика».

Форма «Сотрудники» взаимодействует с формой "Добавить сотрудника" и отчетом "Оформить отчет по продажам данного сотрудника".

Форма «Товар» содержит сведения о имеющимся товаре.

Форма «Справочники» содержит в себе формы справочные формы "Города","Тип Батареи", "Тип корпуса", "Должность".

Архив продаж связан с макросами «Архивация ».

Резервное копирование связано с макросом «Резервное копирование».

В разработанных формах задействованы все созданные таблицы, макросы, запросы и отчеты.

4.8 Комплект поставки и порядок установки системы

Для функционирования и установки разработанной базы данных «Магазин по продаже мобильных телефонов "Мобилочка"» необходим компьютер и программа «Microsoft Access», файл БД.

При входе в клиентскую базу пользователю необходимо ввести логин "User" и пароль "2222" не доступно изменение, добавление и редактирование данных, а возможен лишь просмотр информации.

При входе в административную базу необходимо ввести логин "Admin" и пароль"1111". Администратору базы данных магазина по продаже мобильных телефонов доступна вся информация.

4.9 Работа с пустой базой данных

При входе в пустую базу данных пользователь может вносить данные, необходимые для деятельности салона красоты. В формах «Сотрудники», «Клиенты», доступно добавление новых сотрудников, клиентов.

Предусмотрено занесение информации в справочники, создание персональных отчетов для отчетности перед клиентами и руководством салона красоты.

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

Вывод

За время выполнения курсового проекта «разработка БД информационной системы «Система управления базами данных»» была изучена предметная область. Разработаны иерархическая, сетевая и реляционные модели данных. В результате сравнений этих моделей, за основу реализации СУБД была выбрана реляционная модель. В ходе выполнения курсовой работы были получены навыки создания пользовательского интерфейса и навыки организации взаимодействия объектов системы.

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

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

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

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

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

Список использованной литературы

1. Пасько В. Access 97 - К.: Издательская группа BHV, 2000. - 368с.

2. В. Е. Кошелев, Access 2007. Эффективное использование - М.; Издательский дом «Бином», 2008. - 592 с.

3. Конноли Томас. Базы данных: проектирование, реализация и сопровождение. Теория и практика, 2-е издание. - М.: Издательский дом “Вильямс”, 2001. - 1120 с.

4. Методические указания к курсовому проектированию по дисциплине «Базы данных» / [Сост.: Е.А. Маслова, Н.В. Ногина].-Донецк: ГУИиИИ, 2010г.-32c

Приложение А

ТЕХНИЧЕСКОЕ ЗАДАНИЕ

А.1 Общие сведения

Данный курсовой проект был разработан студентом 3 курса институту информатики и искусственного интеллекта Донецкого национального технического университета КСУ-10, Корольковым Максимом Сергеевичем. Тема курсового проекта: «Разработка базы данных информационной системы магазина напольных покрытий»

Плановый срок начала работы по созданию системы имитационного моделирования: 07.09.12, срок окончания: 11.01.13. Курсовой проект должен выполняться согласно графику, приведенному в таблице А.1.

Таблица А.1 - Стадии разработки ПП

№ этапа	Содержание этапа программирования	Срок выполнения
1	Определение требований к программному продукту. Формулировка постановки задачи	07.09.12
2	Составление технического задания	20.09.12
3	Разработка диаграммы потоков данных	10.10.12
4	Разработка схемы объект/отношение	14.10.12
5	Описание концептуальной модели. Обеспечение целостности данных	18.10.12
6	Выбор и обоснование типа моделей данных. Обоснование выбора СУБД	30.10.12
7	Создание запросов. Обеспечение безопасности данных	4.11.12
8	Обоснование использования режима архивации	18.11.12
9	Написание программных модулей	28.11.12
10	Тестирование и отладка реализованной базы данных	10.12.12
11	Написание пояснительной записки	25.12.12
12	Защита курсового проекта.	09.01.13

А.2 Назначение и цель создания СУБД

Назначением СУБД является хранение основных данных о персонале (ФИО, табельный номер, год рождения, пол, образование, ставка, оклад), покрытии (название,.., вид покрытия), продажах (ассортимент, продавец, дата количество, стоимость), ассортименте (артикул,…, цена).

Цель работы заключается в разработке программного продукта - СУБД «Магазин напольных покрытий» и овладении навыками работы в СУБД ACCESS. Для достижения поставленной цели необходимо решить следующие задачи:

1) провести концептуальное проектирование системы;

2) провести нормализацию БД;

3) осуществить программную реализацию системы.

А.3 Требования к функциональным характеристикам системы

Для выполнения задач и их функционирования, выполняемым ПП, предъявляются следующие требования:

- реализация функций записи, хранения, изменения и удаления информации;

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

- наличие форм, позволяющих обрабатывать информацию в удобном виде;

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

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

А.4.1 Требования к программному обеспечению

Программное обеспечение (ПО) должно обеспечить независимость программных средств от используемых средств вычислительной техники и позволять работать под управлением ОС Windows 7.

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

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

- операционная система - Microsoft Windows 7;

- прикладная программа Access из программного пакета Microsoft Office 2003;

? компьютерная мышь;

? клавиатура;

? компьютер любой модели;

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