Содержание
Пример | Образец курсовой работы МФЮА на тему: Проектирование и разработка БД «Продажа компьютерной техники»
Скачать саму работу в формате Word и отдельно титульный лист к ней можно бесплатно в конце статьи. Так же отметим, что мы можем помочь с курсовой работой. Для этого необходимо обратиться к нашим менеджерам.
Содержание
Введение. 2
Глава 1. СИСТЕМНЫЙ АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ.. 3
1.1 Системный анализ предметной области АСУ.. 3
1.2 Обзор информационных технологий. 4
1.3 Обзор продуктов-аналогов. 7
1.4 Требования к разрабатываемой базе данных. 10
ГЛАВА 2. ПРОЕКТИРОВАНИЕ БАЗЫ ДАННЫХ.. 12
2.1 Разработка инфологической модели. 12
2.2 Обоснование выбора модели данных. 13
2.3 Даталогическое проектирование. 15
2.4 Нормализация, схема БД.. 16
Глава 3. Программная реализация.. 19
3.1 Анализ и выбор СУБД.. 19
3.2 Физическое проектирование БД.. 19
3.3 Разработка представлений. 26
3.4 Разработка форм.. 29
3.5 Разработка отчетов. 30
3.6 Реализация ограничений, автоматизация обработки данных в БД.. 31
3.7 Безопасность и контроль. 34
Заключение. 39
Список источников и литературы.. 40
Актуальность данного проекта обусловлена необходимостью компаний в эффективной системе управления продажами компьютерной техники. Развитие технологий, конкуренция на рынке и изменение потребительских предпочтений требуют от компаний быстрого реагирования на изменения и оптимизации бизнес-процессов. Внедрение базы данных специально адаптированной под потребности компании позволит улучшить контроль над складскими запасами, оптимизировать процесс закупок и продаж, а также повысить уровень обслуживания клиентов, что в свою очередь способствует увеличению конкурентоспособности и прибыльности компании.
Целью данного проекта является проектирование и разработка базы данных для управления процессом продажи компьютерной техники с целью повышения эффективности управления складскими запасами, улучшения обслуживания клиентов и оптимизации бизнес-процессов компании.
Задачи:
Анализ требований: Провести анализ бизнес-процессов компании, выявить требования к базе данных, определить основные сущности и их атрибуты.
Проектирование базы данных: Разработать логическую и физическую модели базы данных, учитывая специфику бизнеса компании, нормализацию данных, а также обеспечение целостности и безопасности данных.
Разработка структуры базы данных: Создать таблицы для хранения информации о продуктах, клиентах, заказах, поставках, складских запасах, ценах и других сущностях, необходимых для эффективного управления продажами компьютерной техники.
Интеграция существующих систем: Предусмотреть возможность интеграции новой базы данных с уже существующими информационными системами компании для обмена данными и синхронизации информации.
Разработка пользовательского интерфейса: Создать удобный и интуитивно понятный пользовательский интерфейс для взаимодействия с базой данных, который позволит оперативно выполнять основные операции по управлению продажами компьютерной техники.
Тестирование и оптимизация: Провести тестирование разработанной базы данных на соответствие требованиям, выявить и устранить возможные ошибки и несоответствия. Оптимизировать производительность базы данных для обеспечения быстрой и эффективной работы.
Внедрение и обучение персонала: Провести внедрение разработанной базы данных, обучить персонал работе с новой системой, обеспечить поддержку и сопровождение на этапе внедрения.
Глава 1. СИСТЕМНЫЙ АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ
1.1 Системный анализ предметной области АСУ
Системный анализ предметной области автоматизированной системы управления (АСУ) "Продажа компьютерной техники" играет ключевую роль в определении требований к функциональности и структуре базы данных. В этом контексте под системным анализом понимается процесс изучения и анализа всех аспектов бизнес-процессов, связанных с продажей компьютерной техники, с целью выявления проблемных моментов, потребностей пользователей и возможных улучшений. Вот несколько ключевых шагов, которые могут быть включены в системный анализ предметной области автоматизированной системы управления "Продажа компьютерной техники":
Идентификация заинтересованных сторон (стейкхолдеров): Определение всех участников бизнес-процесса, таких как менеджеры по продажам, складской персонал, клиенты и поставщики. Изучение их потребностей и ожиданий от системы управления продажами.
Сбор требований: Проведение интервью, опросов и анализа документации для выявления требований к системе. Это может включать в себя требования к функциональности (например, управление складом, обработка заказов, ведение клиентской базы данных) и требования к производительности и безопасности.
Анализ бизнес-процессов: Подробное изучение текущих бизнес-процессов, связанных с продажей компьютерной техники, от начала заказа до его выполнения и доставки клиенту. Определение узких мест и возможных улучшений процесса.
Определение данных: Идентификация всех типов данных, которые будут использоваться в системе, таких как данные о продуктах, клиентах, заказах, поставках, ценах и т.д. Определение связей между этими данными.
Анализ рисков: Выявление потенциальных рисков и препятствий, которые могут возникнуть в процессе внедрения и использования системы управления продажами. Разработка плана мер по смягчению этих рисков.
Проектирование модели данных: На основе собранных данных и требований разработка логической и физической модели базы данных, которая будет использоваться в системе управления продажами компьютерной техники.
Составление отчета: Документирование результатов системного анализа в виде отчета, который будет использоваться в дальнейшей разработке системы управления продажами.
Рисунок 1 - Организационно-функциональная структура
В бухгалтерии выполняется работа по ведению бухучета, обязательств и хозяйственных операций. Также бухгалтерия следит за работой на кассе, отслеживая все действия по продажам.
Покупатель, приходя в магазин, взаимодействует с продавцами, который, в свою очередь, осуществляют продажу компьютерной техники. Операции с денежными средствами и отбивку чека осуществляются на кассе также продавцом-кассиром.
Ответственный за склад руководит работой склада по приему, хранению и отпуску товаров, по их размещению с учетом наиболее рационального использования складских площадей, облегчения и ускорения поиска необходимых материалов, инвентаря и т. п.
Директор – принимает решение в сфере закупок, работы с партнерами, обеспечении прибыльности предприятия, занимается менеджментом человеческих ресурсов и принимает решение о расширении товарного ассортимента.
Товаровед – отслеживает товар, принимает решение о своевременной закупке товара и поддерживает товарный запас.
1.2 Обзор информационных технологий
Обзор информационных технологий в контексте разработки и внедрения системы управления продажами компьютерной техники играет важную роль, поскольку выбор правильных технологий может значительно повлиять на эффективность и производительность создаваемой системы. Вот несколько ключевых информационных технологий, которые могут быть применены в данном проекте:
Системы управления базами данных (СУБД): Использование современных СУБД, таких как MySQL, PostgreSQL, Microsoft SQL Server или Oracle, позволяет эффективно хранить и управлять данными, необходимыми для управления продажами компьютерной техники.
Языки программирования: Для разработки программной части системы могут быть использованы различные языки программирования, такие как Python, Java, C# или JavaScript. Например, Python может быть использован для написания скриптов обработки данных, а JavaScript - для разработки веб-интерфейса.
Веб-технологии: Если система будет иметь веб-интерфейс, то для её разработки могут быть использованы современные веб-технологии, такие как HTML, CSS, JavaScript и фреймворки для создания веб-приложений, например, React.js, Angular или Vue.js.
API и веб-сервисы: Использование API и веб-сервисов позволяет интегрировать систему управления продажами компьютерной техники с другими информационными системами, такими как системы учета, CRM или системы управления складом.
Облачные технологии: Размещение системы в облаке может обеспечить высокую доступность, масштабируемость и гибкость, а также снизить затраты на инфраструктуру. Популярные облачные платформы, такие как Amazon Web Services (AWS), Microsoft Azure или Google Cloud Platform (GCP), предоставляют широкий набор услуг для развертывания и управления приложениями.
Автоматизация процессов: Использование инструментов автоматизации, таких как системы управления версиями кода (например, Git), системы непрерывной интеграции и развертывания (CI/CD), позволяет ускорить разработку, тестирование и внедрение системы управления продажами.
Бизнес-аналитика и отчетность: Для анализа данных и создания отчетов могут быть использованы различные бизнес-интеллект инструменты, такие как Tableau, Power BI или QlikView.
Выбор конкретных технологий будет зависеть от требований проекта, особенностей бизнес-процессов компании, а также доступных ресурсов и опыта команды разработки. Важно подбирать технологии, которые наилучшим образом соответствуют потребностям и целям проекта.
- Система IBS Trade House (компании IBS)
Рисунок 2 - IBS Trade House
Разработанное решение предоставляет возможность контроля и управления потоками товаров в оптово-розничных сетях различных форматов. Система состоит из автоматизированных рабочих мест (АРМ), специально предназначенных для выполнения разнообразных задач в офисах, на складах, в магазинах и для администрирования.
Система обеспечивает ввод, хранение, обработку и передачу первичной информации. Благодаря мультиплатформенности, IBS Trade House может взаимодействовать с большинством ERP-систем, а при необходимости может функционировать автономно. Вся сгенерированная отчетность экспортируется в формат MS Excel для дальнейшего анализа и обработки данных. Особенности системы включают ее открытость, универсальность, соответствие стандартам и законодательству. В процессе работы любой компонент системы может быть добавлен по мере необходимости. Надежность обеспечивается за счет использования промышленной СУБД Progress, которая способна обрабатывать большие объемы данных до сотен терабайт.
Функциональность:
ведение справочников;
электронный документооборот (система EDI);
ценообразование;
печать ценников и этикеток;
отчёты;
работа с фильтрами и макросами;
система администрирования;
управление производством;
выгрузка данных в форматы XML, Microsoft Excel, PDF;
- Система Alfa (производитель «Информконтакт»)
Рисунок 3 - Alfa
Система состоит из комплекта полностью интегрированных программных модулей, каждый из которых представляет собой самостоятельное и полнофункциональное решение в своей области. Для автоматизации торговли предусмотрены два модуля: Alfa-Retail для розничной торговли и Alfa-Sales&Distribution для оптовой.
Alfa-Retail полностью автоматизирует работу кассира-операциониста, продавца и администратора торгового зала, независимо от размеров магазина, будь то небольшой магазин или супермаркет. Для каждого рабочего места предусмотрена индивидуальная настройка внешнего интерфейса системы, обеспечивающая доступность только необходимых функций для выполнения соответствующих задач, описанных в должностных инструкциях.
Второй модуль, Alfa-Sales&Distribution, обеспечивает все необходимые функции для планирования, учета и анализа торговых процессов, а также оптимизации хранения, перемещения и отгрузки готовой продукции.
Функциональность:
Для розничной торговли:
Взаимодействие с контрольно-кассовыми машинами.
Контроль ассортимента и наличия товаров в торговом зале и на складах.
Контроль забронированных товаров.
Управление ценовой политикой.
Формирование и аннулирование чеков на выдачу и возврат товара.
Контроль денежных средств в кассах торговых залов.
Формирование и печать ценников, включая создание штрих-кодов.
Параметрические отчёты.
Использование дисконтных карт.
Для оптовой торговли:
Планирование и контроль сбыта.
Документирование и финансовый учет сбытовых операций.
Учет и управление подвижным составом.
Сквозной документарный учёт.
Оформление заказов.
Учёт таможенного декларирования.
Ведение лицевых счетов грузополучателей.
Учёт комиссионной реализации и перемещения готовой продукции между складами.
Построение отчётов.
1.4 Требования к разрабатываемой базе данных
Требования к разрабатываемой базе данных для проекта "Продажа компьютерной техники" могут быть сформулированы следующим образом:
Хранение информации о продуктах: База данных должна содержать информацию о продуктах компьютерной техники, включая модель, производителя, характеристики, стоимость, количество на складе и другие сведения.
Учет клиентов: Система должна позволять хранить данные о клиентах, включая их персональную информацию, контактные данные, историю покупок и предпочтения.
Оформление заказов: База данных должна поддерживать оформление заказов клиентами, включая выбор продуктов, способы доставки, оплаты и другие детали заказа.
Управление складскими запасами: Система должна отслеживать количество доступных товаров на складе, автоматически учитывать поступления и отгрузки товаров, а также предупреждать о необходимости дополнительного заказа при нехватке товаров.
Интеграция с партнерами и поставщиками: База данных должна поддерживать интеграцию с внешними системами поставщиков для автоматического обновления информации о товарах и ценах, а также учета поставок.
Отчетность и аналитика: Система должна предоставлять возможность создания отчетов о продажах, складских запасах, динамике спроса и других ключевых показателях для анализа эффективности работы компании.
Безопасность данных: База данных должна обеспечивать защиту конфиденциальности и целостности данных, а также предоставлять возможности для управления доступом к информации в зависимости от ролей пользователей.
Масштабируемость и производительность: Система должна быть способной обрабатывать большие объемы данных и обеспечивать высокую производительность даже при интенсивной нагрузке.
Эти требования помогут определить необходимый функционал и структуру базы данных, обеспечивая эффективное управление процессом продажи компьютерной техники и повышение конкурентоспособности компании.
В главе 1 проведён системный анализ предметной области объекта автоматизации. Перечислены должности работников, выявлены основные объекты предметной области с их основными характеристиками, а также сформулированы ограничения, накладываемые на информацию, содержащуюся в системе.
В ходе обзора информационных технологий описаны классы СУБД: Oracle Database, MySQL, Microsoft Access
Определили требования к базе данных для каждой группы пользователей и перечислили какие действия они могут совершать.
В данной главе осуществлена подготовка к этапу проектирования базы данных.
ГЛАВА 2. ПРОЕКТИРОВАНИЕ БАЗЫ ДАННЫХ
2.1 Разработка инфологической модели
Целью инфологического проектирования является создание структурированной информационной модели предметной области, для которой будет разрабатываться база данных. На рисунке 4 представлена инфологическая модель проектируемой базы данных.
Рисунок 4 – Инфологическая модель
Процесс реализации товара начинается с поставки новой от поставщика и регистрации каждой единицы в базе данных магазина.
При необходимости ассортимент магазина расширяется новыми товарами путем добавления новых данных в списки продаваемых товаров.
Каждую сделку проводит сотрудник на должности продавца, занося в БД информацию для каждой сделки: данные покупателя и необходимые данные по сделке.
2.2 Обоснование выбора модели данных
Выбор модели данных для проекта "Продажа компьютерной техники" должен быть обоснован на основе требований проекта, характеристик бизнес-процессов и особенностей данных, которые необходимо хранить и обрабатывать. В данном случае рекомендуется использовать реляционную модель данных по следующим причинам:
Структурированность данных: Реляционная модель позволяет структурировать данные в виде таблиц, что облегчает их организацию и обеспечивает легкий доступ к информации.
Гибкость и расширяемость: Реляционная модель позволяет легко добавлять новые таблицы и связи между ними при необходимости, что делает систему более гибкой и адаптивной к изменениям в бизнес-процессах.
Целостность данных: Реляционные СУБД обеспечивают механизмы для обеспечения целостности данных, такие как ограничения целостности, транзакции и механизмы контроля доступа, что важно для сохранения точности и достоверности информации.
Поддержка сложных запросов: Реляционные СУБД обеспечивают мощные средства для выполнения сложных запросов к данным, что позволяет эффективно анализировать информацию и создавать различные отчеты.
Широкое распространение и поддержка: Реляционные базы данных широко распространены и поддерживаются большинством вендоров, что обеспечивает доступность квалифицированных специалистов и надежность в работе.
В результате использование реляционной модели данных обеспечит надежную основу для разработки базы данных "Продажа компьютерной техники", обеспечивая удобное хранение, эффективное управление и анализ данных, а также гибкость и расширяемость системы для адаптации к изменяющимся потребностям бизнеса.
2.3 Даталогическое проектирование
Поскольку выбор сделан в пользу реляционной модели данных, применяется процесс преобразования информационной модели в физическую модель данных. Для этого был использован следующий алгоритм:
- Для каждого атрибута сущности был определен конкретный тип данных, который поддерживается в СУБД Oracle.
- При реализации связи многие-ко-многим, которая была допустима в информационной модели, производилось ее преобразование в связи один-ко-многим через промежуточную таблицу. Для устранения существующей связи многие-ко-многим между таблицами «Список товаров» и «Поставщики» будет введена промежуточная таблица «DeliverGoods», в которой будет указан тип товара, поставляемый каждым поставщиком.
Рисунок 5 – Даталогическая модель проектируемой БД
2.4 Нормализация, схема БД
Нормальная форма в реляционной модели данных отражает уровень избыточности данных, который может привести к потенциальным ошибкам при выборке или изменении данных. Это свойство определяется набором требований, которым должно соответствовать отношение.
Процесс нормализации представляет собой преобразование структуры базы данных к форме, которая соответствует нормальным формам. Цель нормализации заключается в минимизации избыточности данных, что не направлено ни на повышение, ни на снижение производительности или объема базы данных. Основная задача нормализации состоит в снижении вероятности противоречий в хранимой информации. Для этого обычно используется декомпозиция отношений таким образом, чтобы каждое отношение содержало только первичные факты, то есть факты, которые нельзя вывести из других хранимых фактов.
Понятие нормализации тесно связано с понятием функциональной зависимости.
ФЗ R.A → R.B называется полной, если набор атрибутов B ФЗ от A и не зависит функционально от любого подмножества А.
ФЗ R.А → R.В называется транзитивной, если существует такой набор атрибутов С, который удовлетворяет следующим свойствам: 1. С ¢ А; 2. В ¢ С; 3. существует ФЗ
R.А → R.С; 4. не существует ФЗ R.С → R.А; 5. не существует ФЗ R.С → R.B.
Таблица считается находящейся в первой нормальной форме (1НФ), если каждый из её атрибутов является атомарным, то есть может содержать только одно значение. Это означает, что в таблице не должно быть полей, способных хранить списки значений. Для приведения таблицы к 1НФ обычно требуется её разбиение на несколько отдельных таблиц.
Отношение считается находящимся во второй нормальной форме (2НФ), если оно находится в 1НФ, и при этом каждый его атрибут, не входящий в состав первичного ключа, функционально полно зависит от первичного ключа. Функциональная полная зависимость подразумевает, что каждый атрибут зависит от всех компонентов первичного ключа, но не зависит от какого-либо из них в отдельности. Другими словами, в 2НФ нет атрибутов, зависящих от части составного ключа.
Отношение считается находящимся в третьей нормальной форме (3НФ), если оно находится во второй нормальной форме (2НФ) и при этом каждый не ключевой атрибут зависит только от первичного ключа. Таким образом, отношение находится в 3НФ, когда оно находится во 2НФ и не содержит транзитивных зависимостей не ключевых атрибутов от ключевых.
Схема базы данных, разработанная в данном случае, находится во 2НФ, поскольку в отношении с составным первичным ключом ("Order detail") все атрибуты, не входящие в первичный ключ, функционально полно зависят от первичного ключа.
3НФ – отношение находится в 3НФ, если оно находится во 2НФ и не содержит транзитивных зависимостей. Все отношения данной модели находятся в 3НФ, т.к. ни в одном из них нет транзитивных зависимостей.
В большинстве ситуаций достаточным этапом при решении практических задач является достижение третьей нормальной формы. Поэтому процесс проектирования базы данных часто завершается достижением этой формы. Разрабатываемая база данных уже соответствует требованиям третьей нормальной формы, следовательно, дополнительная нормализация не требуется. Схема базы данных представлена на рисунке 5.
Во второй главе курсовой работы была выполнена разработка информационно-логической модели. Были изучены различные модели данных (иерархическая, сетевая, реляционная, объектно-ориентированная), а также указаны их преимущества и недостатки, и сделан выбор в пользу реляционной модели.
На основе информационно-логической модели была построена даталогическая модель, в которой был указан список атрибутов отношений, и проведена нормализация до третьей нормальной формы. Проектирование базы данных завершено, и получена вся необходимая информация для реализации проектируемой информационной системы с использованием одной из реляционных СУБД.
Глава 3. Программная реализация
Oracle Application Express (Oracle Apex, APEX, ранее известная как Oracle HTMLDB) представляет собой свободную среду для быстрой разработки прикладного программного обеспечения на основе базы данных Oracle. Она полностью реализована в виде веб-приложения. Все компоненты, используемые в процессе разработки приложения в Oracle Apex, хранятся непосредственно в инфраструктуре базы данных Oracle, что обеспечивает совместную работу разработчиков и контроль версий без необходимости использования дополнительных файлов и систем управления версиями.
Oracle Application Express (Apex) представляет собой инструмент для быстрой разработки веб-приложений для базы данных Oracle. С помощью Apex можно создавать профессиональные приложения даже для пользователей с ограниченным опытом программирования, при этом требуется только веб-браузер.
Ускоренная разработка обеспечивается благодаря встроенным средствам в Oracle Apex, таким как пользовательские темы интерфейса, управление навигацией, управление формами и гибкие отчеты.
3.2 Физическое проектирование БД
Создадим приложение в APEX Application Builder, и разработаем меню для нашего приложения.
Рисунок 6 – Создание приложения в Oracle APEX
После того как создали приложение, используя даталогическую модель создадим следующие таблицы:
Posts
Employees
Orders
Customers
Products
Categories
Manufacturers
Supplies
Supliers
DeliverGoods
ProducsList
Для каждой таблицы создадим свою последовательнсть. Для этого нажмем на кнопку «Create» и выберем Sequence, после чего откроется окно Create Sequence, где вводим имя последовательности:
Рисунок 7 – Настройка последовательности
Далее сохраняем последовательность.
Рисунок 8 – Сохранение последовательности
Для того чтобы создать таблицу нажмем на кнопку «Create» и выберем TABLE, после чего откроется окно Create Table, где заполняем Column Name и выбираем тип этих полей:
Рисунок 9 – Выбор типа полей
Далее укажем, что для первичного ключа уже заготовлена последовательность и укажем первичный ключ. Также есть возможность указать внешние ключи и ограничения, но, в данном случае, в этом нет необходимости.
Рисунок 10 – Установка существующей последовательности
Завершаем создание таблицы, нажав на кнопку «Create».
Рисунок 11 – Завершение создания таблицы
Создадим все остальные таблицы, как было показано выше, и заполним их нужными данными.
Рисунок 12 – Таблица должностей «POSTS»
Рисунок 13 – Таблица работников «Employees»
Рисунок 14 – Таблица покупателей «Customers»
Рисунок 15 – Таблица продаваемых товаров «ProductsList»
Рисунок 16 – Таблица поставщиков «Supliers»
Рисунок 17 – Таблица поставок «Supplies»
Рисунок 18 – Таблица заказов «Orders»
Рисунок 19 – Таблица поставляемой продукцией поставщиками «DeliverGoods»
Рисунок 20 – Таблица категорий «Categories»
Рисунок 21 – Таблица товаров «Products»
Рисунок 22 – Таблица производителей «Manufacturers»
Создадим несколько представлений, которые, в дальнейшем, будут использоваться при разработке отчетов
Первое представление показывает информацию о поступлениях денежных средств за май месяц.
Рисунок 23 – Создание представления получении прибыли за май
Рисунок 24 – Пример работы представления
Второе представление показывает информацию о поставках товара за май месяц.
Рисунок 25 – Создание представления о поставках товара
Рисунок 26 – Пример работы представления
Третье представление показывает информацию об убытках за май месяц
Рисунок 27 – Создание представления об убытках за май
Рисунок 28 – Пример работы представления
После того как создали приложение в APEX Application Builder, разработаем меню для нашего приложения.
Рисунок 29 – Внешний вид основного меню
Также создали формы для ввода данных, как показано на рисунках ниже.
Рисунок 30 – Форма заполнения/отображения производителей
Рисунок 31 – Форма дополнения/отображения товаров магазина
Создадим отчеты, используя ранее созданные представления.
Рисунок 32 – Отчет по доставкам за май
Рисунок 33 – Отчет по прибыли за май
Рисунок 34 – Отчет по убыткам за май
3.6 Реализация ограничений, автоматизация обработки данных в БД
В таблице «Employees» добавим ограничение на правильность вводимых данных. Добавим ограничение на поле «Age», где укажем диапазон возможного возраста сотрудника – от 18 до 99.
Рисунок 36 – Ограничение на возраст
В таблице «Productlist» добавим ограничение на правильность вводимых данных. Добавим ограничение на поле «COUNT», где укажем диапазон товара на складе – от 0 до ∞.
Рисунок 37 – Ограничение на кол-во товара
Создадим завершающий триггер «Supplies_SR_PROD» для реализации автоматизации данных. При добавлении новой поставки в таблицу «Supplies» автоматически создастся необходимое кол-во товара в таблице «Products» и изменится кол-во товара на складе в таблице «Productlist»
Рисунок 38 – Код триггера
Рисунок 39 – Создание новой поставки
Рисунок 40 – Автоматическое добавление кол-во товаров
Рисунок 41 – Автоматическое создание единиц товара
Создадим предваряющий триггер «Orders_t1» для реализации автоматизации данных. При добавлении нового заказа в таблицу «Orders» автоматически уменьшает единицу товара в таблице в таблице «Productlist»
Рисунок 42 – Код триггера
Рисунок 43 – Создание нового заказа
Рисунок 44 – Автоматические уменьшение кол-ва товара
Создадим замещающий триггер «Price_Update» для реализации автоматизации данных. При изменении цены на товар, в представлении «MOUNTHLYDELIVERYVIEW_», автоматически изменяется цена соответствующего товара в таблице «Products».
Рисунок 45 – Код триггера
Рисунок 46 – Изменение цены
Рисунок 47 – Автоматические изменение цены в таблице
В Oracle существует две основные категории средств безопасности: безопасность доступа и безопасность данных.
Безопасность доступа в Oracle обеспечивается через ряд механизмов идентификации и верификации пользователей. Простейшим из них является запрос имени пользователя и пароля при каждом подключении. Эта процедура должна выполняться независимо от используемого интерфейса для доступа к базе данных. Цель заключается в том, чтобы предоставлять доступ к средствам базы данных только после установления санкционированного соединения. Информация о пользователях и их паролях хранится в таблице SYS.USERS в зашифрованном виде.
В многих приложениях баз данных существуют различные категории пользователей с разными уровнями доступа к данным. В простейшем случае это может быть разделение на пользователей, вводящих данные, и менеджеров, запрашивающих их. Однако, чаще всего существует несколько категорий пользователей с пересекающимися правами доступа. В таких случаях можно избежать дублирования работы, создав одно приложение с динамическим меню или панелью инструментов, которые изменяются в зависимости от роли конкретного пользователя.
Безопасность данных в Oracle означает ограничение доступа уполномоченных пользователей к данным в базе данных. Это достигается путем предоставления доступа только к определенным модулям, на выполнение которых пользователям предоставлено право.
Для добавления пользователя в базу данных администратор базы данных создает учетную запись с именем пользователя и паролем. Каждому пользователю также назначается профиль, который определяет предельные значения системных ресурсов, выделенных данному пользователю, такие как лимит процессорного времени или другие ограничения.
В Oracle имеются системные и объектные привилегии. Системные привилегии — это права на выполнение общих задач, таких как SELECT ANY TABLE и UPDATE ANY TABLE. Объектные привилегии относятся к действиям с определенными элементами базы данных — таблицами, представлениями и последовательностями. Для предоставления привилегий другому пользователю можно использовать оператор GRANT.
В данном случае будет реализована авторизация пользователей с помощью Authorization Schemes. Было создано несколько схем авторизации.
Первое, что необходимо сделать – понять какие уровни авторизации необходимо будет реализовать в нашем приложении. Т.к. это определит не только роли, которые создаются в общем компоненте контроля доступа к приложениям, но и будут определять, какие схемы авторизации мы определяем и возможность применения к различным компонентам APEX.
Мы будем использовать 5 различных уровня авторизации:
Администратор
Бухгалтер
Товаровед
Ответственный за склад (Кладовщик)
Продавец
На администратора не накалывается никаких ограничений.
Бухгалтеры не имеют доступа к таблицам покупателей производителей и категориям.
Товаровед имеет доступ только к таблицам: список товаров, поставщик, производитель и категории.
Кладовщик имеет доступ к списку товаров, поставкам и товару. Также имеет доступ к отчетам о поступлениях товара.
Продавцы имеют доступ только к заказам и покупателям.
Для реализации аутентификации создадим таблицу с ролями, в которой и укажем тип, пароль и уровень доступа.
Рисунок 48 – Таблица USER_LOGIN
Сами по себе роли контроля доступа, по сути, ничего не делают, но предоставляют возможность связать пользователя с ролью. Это связанные схемы авторизации и обеспечивают логику, которая позволяет нам связать роль с компонентами в APEX. Далее необходимо создать схемы авторизации для ролей.
Рисунок 49 – Схемы авторизации
Теперь можно присвоить различным компонентам соответствующую схему авторизации
Рисунок 50 – Пример установки схемы
Теперь, после авторизации, будут отображаться только те страницы, к которым у пользователей есть доступ.
Рисунок 50 – Авторизация администратора
Рисунок 51 – Меню для администратора
Рисунок 52 – Авторизация продавца
Рисунок 53 – Меню для продавца
В данной главе произведено физическое проектирование базы данных. Создано три триггера. Определены ограничения. Произведен анализ безопасности в СУБД Oracle.
Изучение системного анализа предметной области магазина продажи компьютерной техники, построение инфологической и даталогической моделей, а также реализация базы данных в СУБД Oracle Application Express позволили осуществить успешное выполнение курсовой работы по разработке базы данных для магазина компьютерной техники.
Системный анализ предметной области представляет собой важный этап, на котором определяются ключевые требования к будущей базе данных. Исследование предметной области позволяет выявить основные бизнес-процессы, определить основные сущности и их взаимосвязи, а также выявить потребности пользователей. Это обеспечивает основу для дальнейшего проектирования и разработки базы данных.
Построение инфологической и даталогической моделей является ключевым этапом в процессе разработки базы данных. Инфологическая модель описывает основные сущности и связи между ними, а также их атрибуты. Даталогическая модель включает в себя конкретные таблицы и поля, а также связи между ними. Эти модели служат основой для создания физической базы данных.
Реализация базы данных в СУБД Oracle Application Express позволяет создать функциональную и масштабируемую систему для управления данными магазина компьютерной техники. Oracle Apex предоставляет мощные инструменты для быстрой разработки веб-приложений, что упрощает процесс создания интерфейса и взаимодействия с базой данных.
Таким образом, выполнение курсовой работы по разработке базы данных для магазина компьютерной техники позволило не только изучить основные принципы и методы проектирования баз данных, но и приобрести практические навыки в создании функциональных и эффективных систем управления данными.
Начало формы
Список источников и литературы
- Адамцевич Л.А., Пиляй А.И. Разработка базы данных отбора и экспертной проверки объектов культурного наследия для обучения искусственного интеллекта // Строительное производство. 2023. № 2. С. 80-84.
- Азарова А.С., Гейченко Д.А. Перспективы создания баз данных геномной информации с точки зрения криминалистики // Трибуна ученого. 2022. № 6. С. 139-142.
- Аль Мусави О.А.Р., Кравец О.Я. Исследование алгоритмов повторной оптимизации запросов в облачных базах данных // Решение. 2022. Т. 1. С. 168-171.
- Амалбеков С.С., Тусупов Д.А. Использование инструмента dbms_job в oracle для планирования и управления заданиями в базе данных // Интернаука. 2023. № 19-1 (289). С. 49-51.
- Аргучинцев А.В., Кедрин В.С., Кедрина М.С. Архитектура иерархически модифицируемо-пересекающейся базы данных биоэкологических параметров // Вестник Бурятского государственного университета. Математика, информатика. 2022. № 1. С. 3-17.
- Безруков И.А., Сальников А.И., Яковлев В.А., Вылегжанин А.В. Анализ надежности программного отказоустойчивого массива при организации системы долговременного хранения данных радиоинтерферометрии со сверхдлинными базами // Приборы и техника эксперимента. 2022. № 2. С. 37-42.
- Белгородский В.С., Дембицкий С.Г., Силаков А.В., Кушнир А.М., Дианова Т.В. Экономическая проблематика текстильной промышленности в зеркале библиографических баз данных // Известия высших учебных заведений. Технология текстильной промышленности. 2022. № 3 (399). С. 5-17.
- Бирих Э.В., Волокушина К.П. Разработка автоматизированного процесса по корреляции информации между таблицей базы данных Postgresql и Active Directory // Экономика и качество систем связи. 2023. № 1 (27). С. 65-71.
- Боженко А.М. Анализ баз данных ледовой обстановки в программном комплексе matlab и ARCGIS // Интернаука. 2022. № 1-1 (224). С. 27-30.
Скачать пример / образец курсовой работы МФЮА на тему: Проектирование и разработка БД «Продажа компьютерной техники»
Проектирование и разработка БД «Продажа компьютерной техники».2.53 мб. Word
Образец титульного листа МФЮА. 32.5 Кб. Word
Другие статьи:
- Курсовая работа ММУ- пример | образец
- Практика по получению первичных профессиональных умений и навыков (часть 1/1) – ММУ пример образец учебной практики
- Основы военной подготовки | Практическая работа ММУ пример, образец
- Диджтал проектирование- ММУ Реферат
- Курсовая работа ММА | Факультет «Гражданского права»- пример | образец