Целью написания данного курсового проекта является проектирование базы данных «Поставка овощей», которая будет содержать подробную информацию о функционировании системы заказа и поставки товара, предоставлять подробную информацию об овощах.
2.2 Функциональные требования к СУБД «Поставка овощей»
Основной задачей данного программного продукта является создание базы данных, реализующей электронное управление процессов учета поставки и реализации овощей. Программный продукт должен содержать информацию о поставках овощей, их классификации и реализации, а также информацию о менеджерах. Также возможно изменение информации хранящейся в базе данных.
2.3 Требования к СУБД «Поставка овощей»
Полученная база данных «Поставка овощей» должна:
1) обеспечивать хранение и предоставление по требованию данных о товарах;
2) обеспечивать возможность добавления, изменение и удаления данных об имеющихся товарах на складе;
3) иметь удобный пользовательский интерфейс для работы с базой данных пользователя, не являющегося специалистом в области обработки данных;
4) содержать необходимые запросы к информации (например, запрос на добавление информации или на получение списка доступных товаров по категориям), формы и отчеты для обработки хранимой информации о продуктах;
5) обеспечивать защиту данных о продукте от несанкционированного доступа (использовать пароли и защиту на уровне пользователей);
6) контролировать целостность, непротиворечивость, сохранность и достоверность информации о продуктах, содержащихся на складе;
7) содержать систему помощи и информацию о программе.
Выходные данные предоставляются в виде различных форм и отчетов. Добавление данных происходит путем ввода с клавиатуры.
3 КОНЦЕПТУАЛЬНОЕ ПРОЕКТИРОВАНИЕ СИСТЕМЫ
3.1 Инфологическое моделирование предметной области
Моделирование данных – это процесс создания логической структуры данных. Этап инфологического моделирования предполагает выделение информационных объектов в заданной предметной области и определение отношений между ними. Инфологическое моделирование может выполняться в соответствии с построением одной из следующих моделей:
− модели «сущность-связь»;
− диаграмма потока данных.
Моделирование предметной области базируется на использовании графических диаграмм, включающих разнородные компоненты. В рамках данного курсового проекта будет построена модель «сущность-связь» (ER - диаграмма) и диаграмма потока данных (DFD).
3.1.1 Построение диаграммы потоков данных
Диаграммы потоков данных (Data Flow Diagrams — DFD) представляют собой иерархию функциональных процессов, связанных потоками данных. Цель такого представления — продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами.
Диаграмма потоков данных изображена на рисунке 3.1
Рисунок 3.1 – Начальная контекстная диаграмма
В таблице 3.1 приведено соответствие потоков данных на диаграммах двух уровней.
Таблица 3.1 – Соответствие потоков данных на диаграммах
Потоки на диаграмме
верхнего уровня
Потоки на диаграмме
нулевого уровня
информация для изготовителя
ответ на запрос об виде фасовки и имеющихся овощей
информация от изготовителя
запрос на имеющийся овощи, данные о производителе
информация от менеджера
ответ на запрос о поставке, данные о менеджере
информация для менеджера
запрос о поставках
информация ппроизводителю
запрос на поставку овощей
информация от производителя
ответ на запрос поставки овощей, данные о производетеле
На рисунке 3.2 приведена контекстная диаграмма первого уровня.
Рисунок 3.2 – Контекстная диаграмма первого уровня
3.1.2 Построение диаграммы «обьект-отношение»
По изученной предметной области была выделена точная модель объект-отношение, представленная на рисунке 3.3
Рисунок 3.3 - Схема «объект-отношение»
Описание схемы объект-отношение
В данной схеме в виде прямоугольников обозначены объекты, в виде овалов – их свойства, а в виде ромбов – отношения между объектами.
В состав данной схемы входят четыре объекта: «Категории овощей», «Овощи», «Производитель», «Менеджер».
Объект «Категория овощей» имеет свойство «Название» и связан как один ко многим с объектом «Овощи», так как в одной категории овощей могут находиться несколько овощей и один овощ может относиться только к одной группе овощей.
Объект «Овощи» имеет свойства: «Вид овощей», «Вид фасовки», «Артикул». И связан связью многие ко многим с объектами «Производитель», «Менеджер». Так как один продукт может производиться многими производителями один производитель может производить разные продукты. Также, один вид овощей может поставляться разными производителями и один производитель может поставлять многие виды овощей.
Объект «Производитель» имеет свойства: «Название», «Город», «Адрес», «Телефон».
Объект «Менеджер» имеет свойства: «Ф.И.О.», «Телефон». И связан как многие ко многим с объектом овощи, так как один заказ может быть сделан на несколько магазинов и один магазин может принимать много заказов.
Связь «Поставка» имеет следующие свойства: «Дата поставки», «Цена за единицу», «Количество».
В ходе проектирования могут быть получены разные варианты организации одной базы данных. Это связано с рассмотрением предметной области с разных сторон. Предлагаемый вариант базы данных содержит всю необходимую информацию для работы овощного магазина.
3.2 Обоснование выбора модели данных
В настоящее время существует большое количество систем управления базами данных, это связано с существованием различных моделей данных. При проектировании базы данных необходимо выбрать наиболее подходящую модель данных для заданной предметной области. Существует три основных типа моделей данных – реляционная, иерархическая и сетевая.
3.2.1 Иерархическая модель данных
Иерархическая модель БД представляет собой совокупность элементов, расположенных в порядке их подчинения от общего к частному и образующих перевернутое дерево. Данная модель характеризуется такими параметрами, как уровни, узлы, связи. Принцип работы модели таков, что несколько узлов более низкого уровня соединяются при помощи связи с одним узлом более высокого уровня.
Производитель
Название
Изготовляется
Вес
Артикул
Вид фасовки
Категория овощей
Название
Овощи
Вид овощей
Менеджер
ФИО
Телефон
Поставка
Цена за единицу
Кол-во
Дата поставки
Рисунок 3.4 – Иерархическая модель данных
3.2.2 Сетевая модель данных
В сетевой модели связи описываются с помощью графа, поэтому все элементы связаны друг с другом.
Основным недостатком сетевой модели данных является: сложность и тяжелая наглядность схемы (данная схема наглядно не показывает это, так как содержит достаточно малое количество объектов), ослаблен контроль целостности связей вследствие допустимости установления произвольных связей между записями, любое изменение в схеме ведут к изменению всей базы. К основным достоинствам относится: экономия памяти, быстродействие, возможность обрабатывать произвольные связи.
Заказ на поставку
Поставляют
Сетевая модель данных для предметной области «Строительный магазин» приведена на рисунке 3.5
Отчет о поставке
Поставляется
Производители
Овощи
Менеджер
Категория овощей
Относится к
Взят из категории
Изготовитель
Прием заказа
Отчет о поставляемом продукте
Рисунок 3.4 – Сетевая модель данных
3.2.3 Реляционная модель данных
Реляционная база данных – это совокупность отношений, содержащих всю информацию, которая должна храниться в БД. Однако пользователи могут воспринимать такую базу данных как совокупность таблиц.
1. Каждая таблица состоит из однотипных строк и имеет уникальное имя;
2. Строки имеют фиксированное число полей (столбцов) и значений (множественные поля и повторяющиеся группы недопустимы). Иначе говоря, в каждой позиции таблицы на пересечении строки и столбца всегда имеется в точности одно значение или ничего;
3. Строки таблицы обязательно отличаются друг от друга хотя бы единственным значением, что позволяет однозначно идентифицировать любую строку такой таблицы;
4. Столбцам таблицы однозначно присваиваются имена, и в каждом из них размещаются однородные значения данных (даты, фамилии, целые числа или денежные суммы);
5. Полное информационное содержание базы данных представляется в виде явных значений данных, и такой метод представления является единственным. В частности, не существует каких-либо специальных «связей» или указателей, соединяющих одну таблицу с другой;
6. При выполнении операций с таблицей ее строки и столбцы можно обрабатывать в любом порядке безотносительно к их информационному содержанию. Этому способствует наличие имен таблиц и их столбцов, а также возможность выделения любой их строки или любого набора строк с указанными признаками.
4 ПРОГРАМНАЯ РЕАЛИЗАЦИЯ СИСТЕМЫ
4.1 Обоснование выбора СУБД
СУБД – это программа, предназначенная для создания, ведения и совместного использования БД несколькими пользователями. Основными функциями СУБД являются создание и удаление файлов данных и информации, поиск и изменение необходимых данных.
В настоящее время существует множество различных СУБД, наиболее известные из которых являются: Microsoft Access, dBase, FoxPro, Paradox, ИНЕС, СЕТОР, ПАЛЬМА и другие.
В зависимости от используемой модели данных существуют различные виды СУБД. В виду того, что для реализации данного ПП была выбрана РМД, необходимо также выбрать реляционную СУБД.
Одной из таких СУБД является Microsoft Access. Кроме основных требований к СУБД эта система содержит дополнительные преимущества. Так Microsoft Access позволяет реализовывать работу операторов реляционной алгебры в полном объеме, оптимизировать данные, а также обеспечивать защиту данных, создавая различные уровни пользователей, с ограничениями на доступ к информации. Кроме этого, Microsoft Access предоставляет возможность создания различных макросов и модулей, используя язык Visual Basic for Applications. К тому же Microsoft Access, как и многие другие программные приложения фирмы Microsoft, широко распространена во всем мире и доступна многим пользователям.
Исходя из перечисленных преимуществ, для реализации БД «Поставка овощей» целесообразно будет выбрать СУБД Microsoft Access.
4.2 Описание таблиц
Схема данных «Поставка овощей» была построена в Microsoft Access посредством создания таблиц и установления связей между ними.
Схема данных БД «Поставка овощей» представлена на рисунке 4.1.
Рисунок 4.1- «Схема данных»
Между таблицами установлена связь 1:∞. Во всех связях присутствует обеспечение целостности данных. Каскадное удаление не установлено в связях «Город» - «Поставщики», «Тип корпуса» - «Товар», «Тип батареи» -
Между таблицами установлена связь 1:∞. Во всех связях присутствует обеспечение целостности данных. В связи «Изготовляется»-«Поставка» есть каскадное удаление, т.е. при удалении изготовителя, система спросит: «Действительно ли вы хотите удалить…», « Для этого измените параметры в связанной таблице». Остальные связи не имеют каскадного удаления.
Каскадное обновление в связях не установлено, т.к. все первичные ключи – счетчики, а значение в этом поле нельзя изменить, а значит, его не нужно обновлять.
#Код Категории Овощей – тип счетчик, первичный ключ, содержит уникальные значения без повторений.
Название – название категории овощей, тип текстовый, размер 30 символов, обязательное поле без повторений, не индексированное.
Таблица «Менеджер» содержит информацию о менеджерах.
#Код Менеджера – тип счетчик, первичный ключ, содержит уникальное значение без повторений.
ФИО – тип текстовый, размер 50 символов, обязательное поле, индексированное поле (допускаются совпадения).
Телефон – тип поля текстовый, 11 символов, маска ввод: \(999") "999\-99\-99, необязательное поле, не индексированное.
Таблица «Поставка» содержит информацию о менеджере, количестве товара, дате поставки и тп.
Код Менеджера – тип числовой, подстановка из таблицы «Менеджер», обязательное поле, индексированное поле с совпадениями, отображается ФИО.
Цена за единицу – тип числовой, длинное целое, обязательное поле, формат поля: 000#.00 “грн”, не индексированное.
Дата поставки – тип дата-время, маска 00.00.0000;0;_, обязательное поле, не индексированное, условие на значение <=Now (), сообщение об ошибке «Дата не должна быть больше сегодняшней!» .
Количество - тип числовой, длинное целое, обязательное поле, не индексированное поле. Значение по умолчанию 1, значение об ошибке «Количество товара не может быть меньше 1», условие на значение >=1.
Код Изготовителя - тип числовой, обязательное поле, подстановка из таблицы «Изготовляется», связь по коду поля с подписью «Код Изготовителя», связь по полю «Изготовитель».
Таблица «Овощи»: справочник овощей.
#Код Овощей – тип счетчик, первичный ключ, содержит уникальные значения без повторений.
Вид Овощей – название вида, тип текстовый, размер 30 символов, обязательное поле без повторений, индексированное.
Код Категории Товара – тип числовой, длинное целое, подстановка из таблицы «Категории овощей», отображаются названия категории овощей, обязательное поле, совпадения не допускаются.
Производитель
Категория овощей
Менеджер
Овощи
Таблица «Производитель»: справочник производителей.
