Разработка базы данных информационной системы склада косметики и парфюмерии компании «Белоснежка»

КУРСОВОЙ ПРОЕКТ

(РАБОТА) по дисциплине «Основы баз данных и знаний»

на тему: Разработка БД информационной системы склада косметики и парфюмерии компании «Белоснежка»

РЕФЕРАТ Пояснительная записка: 48с., 25 рисунков, 3 приложения, 1 таблица.

Объектом разработки является БД информационной системы склада косметики и парфюмерии компании «Белоснежка».

Целью курсового проектирования является повышение эффективности работы компании «Белоснежка».

Задачи курсового проектирования:

— анализ предметной области и разработки спецификации требований к программному обеспечению;

— создание СУБД для управления складом косметики и парфюмерии;

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

В результате работы курсового проектирования будет получена СУБД для управления складом косметики и парфюмерии компании «Белоснежка».

СОДЕРЖАНИЕ ВВЕДЕНИЕ

1.ОПИСАНИЕ ФУНКЦИОНИРОВАНИЯ СКЛАДА КОСМЕТИКИ И ПАРФЮМЕРИИ

2. ПОСТАНОВКА ЗАДАЧИ

3. КОНЦЕПТУАЛЬНОЕ ПРОЕКТИРОВАНИЕ СИСТЕМЫ

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

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

3.1.2 Построение диаграммы «сущность-связь»

3.2 Выбор модели представления данных

3.2.1 Иерархическая модель данных

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

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

3.3 Нормализация таблиц БД

4. ПРОГРАММНАЯ РЕАЛИЗАЦИЯ СИСТЕМЫ

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

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

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

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

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

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

4.5 Комплект поставки и порядок установки системы ВЫВОДЫ СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ ПРИЛОЖЕНИЕ база данный информационный склад ВВЕДЕНИЕ Развитие средств вычислительной техники способствовало созданию и широкому использованию систем обработки данных разнообразного назначения. Потребовалось разработать специальные методы и механизмы управления такого рода совместно используемыми ресурсами данных, которые стали называться базами данных.

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

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

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

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

Цель курсовой работы — разработка базы данных для компании «Белоснежка».

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

— изучить структуру компании;

— собрать необходимую информацию о компании;

— создание таблиц и запросов на основе данных компании;

— автоматизировать базу данных поставок товара;

— исследовать основные понятия;

— разработать пользовательский интерфейс.

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

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

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

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

1. ОПИСАНИЕ ФУНКЦИОНИРОВАНИЯ СКЛАДА КОСМЕТИКИ И ПАРФЮМЕРИИ Компания «Белоснежка» на сегодняшний день — это начинающая в Украине парфюмерно-косметическая компания.

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

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

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

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

Компания принимает участие в разработке и производстве парфюмерии и косметики, тем самым является производственной компанией. Партнеры — это производители парфюмерии с многолетней историей, находящиеся во Франции, Польше, России, ОАЭ. Всего на сегодняшний день имеется в портфолио коллекции 7 производителей. Портфель брендов компании составляют более 10 эксклюзивных марок нишевой парфюмерии и косметики.

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

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

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

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

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

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

Целью создания склада для парфюмерии и косметики, стал большой товарооборот, а также расширение сети магазинов.

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

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

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

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

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

— хранения справочно-номенклатурной информации;

— поставка/закупка товара, его инвентаризация;

— взаимоотношения с поставщиками/покупателями;

— ценообразование и системы лояльности;

— продажа товара, его перемещения;

— оптимизация товаропотоков;

— обмен информационными данными с удаленными подразделениями и региональными офисами;

— консолидация данных и оперативный анализ деятельности.

2. ПОСТАНОВКА ЗАДАЧИ Целью создания данного КП является проектирование и реализация базы данных для повышения качества работы склада косметики и парфюмерии за счёт автоматизации процессов управления. Данная база данных будет содержать подробную информацию о менеджерах склада, о фирмах производителей, о товаре, его видах типах и брендах, о поставках и о магазинах.

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

Представленная база данных должна содержать следующие требования к системме:

— содержать необходимую информацию о менеджерах склада, о фирмах производителей, о товаре, его видах типах и брендах, о поставках и о магазинах;

— обеспечивать возможность запрашивать, отыскивать, изменять и систематизировать информацию;

— иметь необходимые запросы (на удаление и добавление) и формы (главная форма, формы на добавление информации в таблицы) для обработки хранимой информации;

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

— обеспечение надежного хранения информации;

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

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

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

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

— информация о магазинах;

— информация о фирмах производителей;

— информация о менеджерах склада;

— информация о товаре, его бренде, типе и виде;

— информация о поставках.

3. КОНЦЕПТУАЛЬНОЕ ПРОЕКТИРОВАНИЕ СИСТЕМЫ Концептуальное проектирование систем — начальная стадия проектирования, на которой принимаются определяющие последующий облик решения, и проводится исследование и согласование параметров созданных технических решений с возможной их организацией. При проектировании концептуальной системы мы получим непротиворечивую структурированную интерпретацию реально существующей системы и взаимосвязи её структурных компонентов.

3.1 Инфологическое моделирование предметной области Инфологическое проектирование — построение семантической модели предметной области наиболее высокого уровня абстракции. Такая модель создаётся без ориентации на какую-либо конкретную СУБД и модель данных. В семидесятых годах было предложено несколько моделей данных, названных семантическими моделями. К ним можно отнести семантическую модель данных, предложенную Хаммером (Hammer) и Мак-Леоном (McLean) в 1981 году, функциональную модель данных Шипмана (Shipman), также созданную в 1981 году, модель «сущность-связь», предложенную Ченом (Chen) в 1976 году, и ряд других моделей. У всех моделей были свои положительные и отрицательные стороны. В настоящий момент не существует единой общепринятой системы обозначений для ER-модели и разные CASE-системы используют разные графические нотации.

В данном курсовом проекте мы рассмотри диаграммы потоков данных и диаграмму «сущность-связь»

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

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

Рисунок 3.1 — Диаграммы потоков данных

3.1.2 Построение диаграммы «сущность-связь»

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

На рисунке 3.2 приведена схема для рассматриваемой предметной области склада косметики и парфюмерии.

1)Объект «Менеджер склада»

Его свойства: «ФИО», «№ телефона».

2)Объект «Магазин»

Его свойства: «№ магазина», «ФИО директора», «ФИО контактных лиц», «№ телефона», «адрес».

3)Объект «Бренд»

Его свойство: «название».

4)Объект «Вид косметики и парфюмерии»

Его свойство: «название».

5)Объект «Фирма производителя»

Его свойства: «название», «№ телефона».

6)Объект «Тип косметики и парфюмерии»

Его свойство: «название».

Объекты «Фирма производителя» и «Бренд» связаны между собою отношением «Использует» и связью 1: ?. Так как одна фирма производителя использует много брендов, и наоборот — каждый бренд выпускается одной фирмой производителя.

Объекты «Вид косметики и парфюмерии» и «Тип косметики и парфюмерии» связаны отношением «Содержит» и связью 1: ?. Так как один вид косметики и парфюмерии содержит много типов этих товаров, и наоборот — каждый тип косметики и парфюмерии принадлежит одному виду этих товаров.

Объекты «Бренд» и «Тип косметики и парфюмерии» объединены отношением «Товар», его свойства: «количество в наличии», «название», «емкость», «цена за единицу», «артикул». Связь?: ?. Так как товары одного бренда относятся ко многим типам косметики и парфюмерии, и наоборот — каждый тип косметики и парфюмерии имеет различные бренды товаров.

Объекты «Менеджер склада», «Магазин» и «Товар» объединены отношением «Поставки», его свойство: «дата поставки». Связь?: ?. Так как каждый менеджер склада поставляет различные товары во многие магазины, и наоборот — каждый магазин получает поставки различных товаров от разных менеджеров склада, и наоборот — каждый товар поставками отправляют в магазины различные менеджера склада.

Рисунок 3.2 — Схема «объект-отношение»

3.2 Выбор модели представления данных БД может быть основана на одной модели или на совокупности нескольких моделей. Любую модель данных можно рассматривать как объект, который характеризуется своими свойствами (параметрами), и над ней, как над объектом, можно производить какие-либо действия.

Существуют три основных типа моделей данных:

— реляционная;

— иерархическая;

— сетевая.

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

3.2.1 Иерархическая модель данных Иерархические СУБД — поддерживают древовидную организацию информации.

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

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

К сожалению, определенные знания о физическом порядке хранения записей все же необходимы, так как отношения предок/потомок реализуются в виде физических указателей из одной записи на другую. Это означает, что поиск записи осуществляется методом прямого обхода дерева. Записи, расположенные в одной половине дерева, ищутся быстрее, чем в другой.

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

Иерархическая модель данных для склада косметики и парфюмерии изображена на рис. 3.3, рис. 3.4, рис. 3.5, рис. 3.6.

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

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

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

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

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

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

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

3.2.3 Реляционная модель данных Понятие реляционный связано с разработками известного американского специалиста в области систем баз данных, сотрудника фирмы IBM Е. Кодда, которым впервые был применен термин «реляционная модель данных» .

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

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

РМД в виде нескольких таблиц состоит из 8 таблиц.

Таблица «Менеджер склада» соответствует объекту «Менеджер склада» и содержит 3 поля: ключевое поле #KMC — это первичный ключ, и 2 атрибута, которые есть свойствами объекта «ФИО», «№ тел.» символьного типа. Ключевое поле из таблицы «Менеджер склада», которая связана с таблицей «Поставки» связью 1: ?, помещается в качестве внешнего ключа в таблицу «Поставки», которая соответствует отношению много (?).

Таблица «Поставки» соответствует одноименному отношению. Связана с таблицами «Менеджер склада», «Магазин» и «Товар» связью 1: ?. Содержит 6 полей: ключевое поле #KП — первичный ключ, внешние ключи КТов#, КМ#, КМС# и два атрибута, которые есть свойствами объекта «количество товара» числового типа и «дата» типа время/дата.

Таблица «Магазин» соответствует объекту «Магазин» и содержит 6 полей: ключевое поле #KM — первичный ключ, и 5 атрибутов, которые есть свойствами объекта «№ магазина», «Фио директора», «Фио контактных лиц», «№ телефона» и «Адрес» символьного типа. Ключевое поле из таблицы «Магазин», которая связана с таблицей «Поставки» связью 1: ?, помещается в качестве внешнего ключа в таблицу «Поставки», которая соответствует отношению много (?).

Таблица «Товар» соответствует одноименному отношению. Связана с таблицами «Поставки», «Бренд» и «Тип товара» связью 1: ?. Содержит 8 полей: ключевое поле #KТов — первичный ключ, внешние ключи КБ#, КТ# и 5 атрибутов, которые есть свойствами отношения «количество в наличии», «емкость», «цена за ед.» числового типа и «название», «Артикул» символьного типа.

Таблица «Бренд» соответствует объекту «Бренд» и содержит 3 поля: ключевое поле #KБ — первичный ключ, внешний ключ КФпр# и 1 атрибут, который есть свойством объекта «название» символьного типа. Ключевое поле из таблицы «Бренд», которая связана с таблицей «Товар» связью 1: ?, помещается в качестве внешнего ключа в таблицу «Товар», которая соответствует отношению много (?).

Таблица «Фирма производителя» соответствует объекту «Фирма производителя» и содержит 3 поля: ключевое поле #KФпр — первичный ключ и 2 атрибута, которые есть свойствами объекта «название» и «№ телефона» символьного типа. Ключевое поле из таблицы «Фирма производителя», которая связана с таблицей «Бренд» связью 1: ?, помещается в качестве внешнего ключа в таблицу «Бренд», которая соответствует отношению много (?).

Таблица «Тип товара» соответствует объекту «Тип товара» и содержит 3 поля: ключевое поле #KТов — первичный ключ, внешний ключ КВ# и 1 атрибут, который есть свойством объекта «название» символьного типа. Ключевое поле из таблицы «Тип товара», которая связана с таблицей «Товар» связью 1: ?, помещается в качестве внешнего ключа в таблицу «Товар», которая соответствует отношению много (?).

Таблица «Вид товара» соответствует объекту «Вид товара» и содержит 2 поля: ключевое поле #KВ — первичный ключ и 1 атрибут, который есть свойством объекта «название» символьного типа. Ключевое поле из таблицы «Вид товара», которая связана с таблицей «Тип товара» связью 1: ?, помещается в качестве внешнего ключа в таблицу «Тип товара», которая соответствует отношению много (?).

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

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

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

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

Вот три наиболее распространенных нормальных формы, в которых может находиться база данных в процессе нормализации:

— Первая нормальная форма;

— Вторая нормальная форма;

— Третья нормальная форма.

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

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

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

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

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

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

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

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

4. ПРОГРАММНАЯ РЕАЛИЗАЦИЯ СИСТЕМЫ

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

Microsoft Access — это самая популярная сегодня настольная система управления базами данных.

Ее успех можно связывать с великолепной рекламной кампанией, организованной Microsoft, или включением ее в богатое окружение продуктов семейства Microsoft Office. Вполне возможно, что это так. Но корень успеха, скорее всего, заключается в прекрасной реализации продукта, рассчитанного как на начинающего, так и квалифицированного пользователя. Не будем сейчас вдаваться в подробности сравнения отдельных характеристик Access и его основных конкурентов, например Paradox for Windows или Lotus Approach. Эта тема прекрасно освещена в периодической компьютерной печати. СУБД Access 2003 для работы с данными использует процессор баз данных Microsoft Jet 4.0, объекты доступа к данным и средство быстрого построения интерфейса — Конструктор форм.

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

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

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

Для коммерческого распространения приложений, разработанных на Access, предназначен пакет Access Developer Toolkit, вместе с которым поставляются некоторые дополнения и несколько дополнительных объектов ActiveX.

Главное качество Access, которое привлекает к нему многих пользователей, — тесная интеграция с Microsoft Office. К примеру, скопировав в буфер графический образ таблицы, открыв Microsoft Word и применив вставку из буфера, мы тут же получим в документе готовую таблицу с данными из БД. Вся работа с базой данных осуществляется через окно контейнера базы данных. Отсюда осуществляется доступ ко всем объектам, а именно: таблицам, запросам, формам, отчетам, макросам, модулям.

Посредством драйверов ISAM можно получить доступ к файлам таблиц некоторых других форматов: DBASE, Paradox, Excel, текстовым файлам, FoxPro 2. x, а посредством технологии ODBC — и к файлам многих других форматов. Access 2002 может выступать как в роли OLE контролера, так и ОЕЕ сервера. Это значит, что вы можете контролировать работу приложений Access из любого приложения, при условии, что оно может выступать в роли OLE контролера и наоборот.

Встроенный SQL позволяет максимально гибко работать с данными и значительно ускоряет доступ к внешним данным.

Пользователям, малознакомым с понятиями реляционных баз данных, Access дает возможность разделять свои сложные по структуре таблицы на несколько, связанных по ключевым полям. Процесс построения систем обработки данных значительно различается на разных предприятиях и фирмах в зависимости от объема данных, которые они обрабатывают. Естественно, Access — это типичная настольная база данных.

В то же время на небольшом предприятии с количеством компьютеров не больше 10, ресурсов Access вполне может хватить для обслуживания всего делопроизводства, естественно, в связке с Microsoft Office.

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

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

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

4.2 Описание таблиц В данном курсовом проекте реализовано 8 таблиц. Ниже приведено их описание и вид.

Таблица «Бренд»: содержит название брендов товара (см. рис. 4.1).

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

Название — название бренда, размер 40 символов, тип текстовый, поле обязательное, индексированное, без повторений.

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

Рисунок — 4.1 Таблица «Бренд»

Таблица «Вид»: содержит название видов товара (см. рис. 4.2).

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

Название — название вида, размер 30 символов, тип текстовый, поле обязательное, индексированное, без повторений.

Рисунок — 4.2 Таблица «Вид»

Таблица «Магазин»: содержит информацию о магазинах фирмы (см.

рис. 4.3).

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

№ магазина — номер магазина, размер 1 символ, тип текстовый, поле обязательное, индексированное, без повторений, маска ввода 0.

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

ФИО конт. лиц — фамилия, имя и отчество контактных лиц определенного магазина, размер 100 символов, тип текстовый, поле не обязательное, индексированное, без повторений.

№ телефона — содержит номера телефонов магазинов, размер 10 символов, тип текстовый, маска ввода «(» 000″)-" 000−00−00.

Адрес — адрес магазинов, размер 45 символ, тип текстовый, поле обязательное, индексированное, без повторений.

Рисунок — 4.3 Таблица «Магазин»

Таблица «Менеджер склада»: содержит информацию о менеджерах складов (см. рис. 4.4).

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

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

№ телефона — содержит номер телефонов менеджеров склада, размер 10 символов, тип текстовый, маска ввода «(» 000″)-" 000−00−00.

Рисунок — 4.4 Таблица «Менеджер склада»

Таблица «Поставки»: содержит информацию о поставках товара (см.

рис. 4.5).

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

Количество — количество товара в поставке, тип текстовый, размер 5 символов, поле необязательное.

Установлено условие на значение: >0 And <=10 000, то есть количество не должно быть меньше 0 и не превышать 10 000, сообщение об ошибке: «Невозможное количество товаров в поставке».

Дата — тип дата/время, имеет краткий формат даты, маска ввода 00.00.0000;0;-,.

Установлено условие на значение через свойства таблицы: >Date ()-365*3, то есть дата не должна быть меньше, чем год возникновения фирмы, сообщение об ошибке: «Неверно введенная дата».

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

Склеивание полей:

Выражение1: Бренд![Название] & «-» & Товар![Название] & «-» & Тип![Название].

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

Склеивание полей:

Выражение1: «№» & Магазин![№ магазина] & «» & Магазин![Адрес].

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

Рисунок — 4.5 Таблица «Поставки»

Таблица «Тип»: содержит название типов товара (см. рис. 4.6).

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

Название — название типа, размер 30 символов, тип текстовый, поле обязательное, индексированное, без повторений.

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

Рисунок — 4.6 Таблица «Тип»

#КТов — код товара, тип счетчик, первичный ключ, содержит уникальные значения без повторений (см. рис. 4.7).

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

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

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

Название — название товара, размер 30 символов, тип текстовый, поле обязательное, индексированное, без повторений.

Емкость — емкость товара, размер 4 символов, тип текстовый, поле необязательное, установлено условие на значение: >0 And <=1000, то есть емкость не должна быть меньше ноля и больше чем 1000, сообщение об ошибке: «Неверно введенная емкость».

Цена за единицу — цена за единицу товара, тип числовой, формат поля #"грн." (стоимость указывается в гривнах), обязательное поле, установлено условие на значение: > 0 And <1000, сообщение об ошибке «Недопустимое значение цены».

Артикул — название фирмы производителя, размер 11 символов, тип текстовый, поле необязательное, индексированное, без повторений.

Рисунок — 4.7 Таблица «Товар»

Таблица «Фирма производителя»: содержит информацию о фирмах производителях (см. рис. 4.8).

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

Название — название фирмы производителя, размер 30 символов, тип текстовый, поле обязательное, индексированное, без повторений.

№ телефона — содержит номер телефонов фирм производителей, размер 10 символов, тип текстовый, маска ввода «(» 000″)-" 000−00−00.

Рисунок — 4.8 Таблица «Фирма производителя»

4.3 Проектирование пользовательского интерфейса Перед этапом проектирования пользовательского интерфейса необходимо провести анализ характеристик пользователей. От этого будет зависеть визуальный вид интерфейса и его содержимое.

4.3.1 Уровни доступа к БД На предприятии с СУБД работают различные пользователи. В зависимости от конкретного пользователя соответственно определяются уровни доступа к формам и элементам форм.

При входе в СУБД пользователю предоставляется возможность выбрать пользователя из предложенного списка и ввести пароль для входа.

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

«Директор» имеет разрешение на просмотр любой интересующей его информации, его уровень доступа приравнивается к администратору.

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

«Менеджер» имеет разрешение на просмотр любой информации, поставляет и добавляет новый товар, принимает заказы.

При запуске базы данных, открывается окно для идентификации пользователя. Пароль администратора — «1», директора — «2», клиента — «3», менеджера — «4».

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

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

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

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

1) уровнем подготовки в предметной области разрабатываемого про-граммного обеспечения;

2) интуитивными моделями выполнения операции в этой предметной об-ласти;

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

4) устоявшимися стереотипами работы с компьютером.

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

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

Рисунок 4.9 — Диаграмма последовательности форм

4.4 Описание функционирования приложения Форма «Авторизация» (см. рис. 4.10):

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

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

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

«Выйти» — закрывает форму.

Рисунок 4.10 — Форма Авторизация Форма «Главная кнопочная форма» (см. рис. 4.11).

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

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

«Информация о магазинах» — открывает форму «Магазины», которая содержит все данные о магазинах компании.

«Ассортимент компании» — открывает форму «Ассортимент компании», которая содержит все данные о товарах компании.

«Добавление нового товара» — открывает форму «Добавление товара», с помощью которой можно добавить новый товар.

«Архивация» — заносит информацию в архив.

«Заказ товара» — открывает форму «Заказы», при помощи которой клиент может заказать товар.

«Закрытие формы» — главная кнопочная форма закрывается.

Рисунок 4.11 — Форма «Главная кнопочная форма»

Форма «Магазины» (см. рис. 4.12).

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

Источник данных: таблица «Магазин».

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

«Предыдущая запись», «Следующая запись», «Первая запись» и «Последняя запись» — пролистывают страницу информации о магазинах.

«Поставки в магазины» — открывает дочернюю связанную форму «Поставки в магазины», которая содержит данные обо всех поставках в каждый магазин.

«Архивация» — заносит информацию в архив.

«Отчет» — открывает параметрический отчет «Поставки», который содержит все поставки в магазины по определенным датам.

«Печать отчета» — выводит отчёт на печать.

«Закрытие формы» — производит закрытие данной формы и возврат на главную форму.

Форма «Поставки в магазины» (см. рис. 4.13).

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

Источник данных: таблица «Поставки».

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

Рисунок 4.12 — Форма «Магазины»

собой определенные действия.

«Закрытие формы» — производит закрытие данной формы и возврат на главную форму.

Рисунок 4.13 — Форма «Поставки в магазины»

Отчет «Поставки» (см. рис. 4.14).

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

Источник данных: таблица «Поставки» «Товар», «Магазин», форма «Магазины».

SELECT Поставки. Дата, Магазин. № магазина], Товар. Артикул, Поставки. Код товара], Поставки. Количество, Товар. Цена за ед]

FROM Товар INNER JOIN (Магазин INNER JOIN Поставки ON Магазин. Код магазина] = Поставки. Код магазина]) ON Товар. Код товара] = Поставки. Код товара]

WHERE (((Магазин. № магазина])=[Forms]![Магазины]![№ магазина]));

Содержит группировку по датам поставки и магазинам, в которые она приходила.

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

Рисунок 4.14 — Отчет Форма «Ассортимент компании» (см. рис. 4.15)

Предназначена для просмотра информации о каждом товаре и добавления нового, содержит подчиненную форму «Поставки подчиненная форма».

Источник данных: таблицы «Товар», «Фирма производителя», «Бренд», «Тип».

SELECT Товар. Артикул, [Фирма производителя]. Название AS [Фирма производителя_Название], Бренд. Название AS Бренд_Название, Тип. Название AS Тип_Название, Товар. Название AS Товар_Название, Товар. Емкость, Товар. Цена за ед], Товар. Код товара]

FROM [Фирма производителя] INNER JOIN (Тип INNER JOIN (Бренд INNER JOIN Товар ON Бренд. Код бренда] = Товар. Код бренда]) ON Тип. Код типа] = Товар. Код типа]) ON [Фирма производителя]. Код фирмы произв] = Бренд. Код фирмы произв];

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

«Предыдущая запись», «Следующая запись», «Первая запись» и «Последняя запись» — пролистывают страницу информации о товарах.

«Добавить товар» — открывает форму «Добавление товара», на которой можно ввести и сохранить новый товар.

«Закрытие формы» — производит закрытие данной формы и возврат на главную форму.

Рисунок 4.15 — Форма «Ассортимент компании»

«Поставки подчиненная форма» (см. рис. 4.16).

Предназначена для просмотра информации о поставках определенного товара, в зависимости, какой выбран на форме «Ассортимент компании».

Источник данных: таблицы «Магазин», «Поставки».

SELECT Магазин. № магазина], Поставки. Количество, Поставки. Дата, Поставки. Код товара]

FROM Магазин INNER JOIN Поставки ON Магазин. Код магазина] = Поставки. Код магазина];

Рисунок 4.16 — Форма «Поставки подчиненная форма»

Форма «Добавление товара» (см. рис. 4.17).

Предназначена для добавления и сохранения нового товара.

Источник данных: таблица «Товар».

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

«Сохранение» — сохраняет нововведенные данные.

«Закрытие формы» — производит закрытие данной формы и возврат на главную форму.

Рисунок 4.17 — Форма «Добавление товара»

Форма «Заказы» (см. рис. 4.18).

Предназначена для заказа товаров клиентами.

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

«Заполнение заказа» — открывает бланк заказов для заполнения клиентом в удобной для него программе.

«Обработка заказа» — обрабатывает и сохраняет заказ.

«Закрытие формы» — производит закрытие данной формы и возврат на главную форму.

Рисунок 4.18 — Форма «Заказы»

Макрос «Архивация»

Предназначен для реализации занесения информации в архив.

Описание макрокоманд с параметрами:

Макрокоманда 1: Открыть Запрос Осуществляет выполнение запроса «Создание архива поставок»

в виде таблицы с изменением данных.

Макрокоманда 2: Открыть Запрос Осуществляет выполнение запроса «Простое удаление устаревших данных».

Макрокоманда 3: Сообщение Выводит информацию о проведенной операции при помощи макроса: «Архивация успешно завершена»;

Макрокоманды применяется к таблице «Архив поставок» при нажатии на кнопку «Архивация» формы «Магазины».

4.5 Комплект поставки и порядок установки системы Для работы с разработанной БД необходимо иметь установленное приложение Microsoft Access 2003 и выше. При запуске базы данных, открывается окно для идентификации пользователя. Пароль администратора — «1», директора — «2», клиента — «3», менеджера — «4».

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

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

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

В целом, БД склада косметики и парфюмерии отвечает следующим требованиям:

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

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

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

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

обеспечивает подсказки в процессе работы;

достаточно прост в эксплуатации;

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

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

имеется справочная информация по работе с системой.

Данная база данных имеет так же ряд недостатков, наиболее существенными из которых являются:

несовершенный интерфейс;

2) сравнительно малое количество отчетов и форм;

несовершенство в владении и использовании макросов.

В дальнейшем имеющиеся недостатки могут быть устранены и возможности БД могут быть расширены.

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