Содержание:

ВВЕДЕНИЕ

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

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

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

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

Цель курсовой работы – проектирование реализации операций бизнес-процесса «Продажи».

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

– рассмотреть основные определения теории бизнес-процессов и баз данных;

• выполнить описание предметной области;
• выполнить моделирование бизнес-процессов для реализации продаж;
• разработать в MS Access базу данных, которая демонстрирует основные бизнес-процессы при продажи;
• выполнить создание вспомогательных объектов (запросов, форм, отчетов) для описания различных функций продаж.

Объект исследования: продовольственный магазин.

Предмет исследования: бизнес-процесс «Продажи».

Основные методы исследования: декомпозиция, анализ бизнес-процесса «Продажи», связанных с хранением данных в табличном виде.

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

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

1.Теоретические основы теории баз данных и бизнес-процессов

1.1. Основные понятия о моделировании бизнес-процессов

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

Бизнес-процесс – это последовательность действий (подпроцессов), которая направлена на получение определенного результата, ценного для некоторого предприятия.[3]

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

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

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

Понятия бизнес-процесса лежит в основе специального процессного подхода к синтезу и анализу деятельности организации.

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

Ключевыми понятиями в бизнес-процессах являются:[1]

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

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

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

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

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

Для моделирования бизнес-процессов необходимо использовать специальные языке моделирования.

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

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

1. IDEF0 (Integration Definition for Function Modeling) применяется для задач создания разных функциональных моделей ИС, которые способны корректно отображать функции системы, а также ее структуру.

Сама нотация IDEF0 является этапом развития графического языка моделирования SADT, использовавшегося при описании функциональных ИС.

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

Функциональный блок представляет некоторую конкретную функцию для рассматриваемой системы. Визуально, этот блок представляется как прямоугольник (рисунок 1). Каждая из имеющихся сторон данного блока дает свое уникальное унифицированное использование:[5]

• верхняя сторона применяется для задания управляющих действий (Control);
• левая сторона применяется для определения входных потоков;
• правая сторона применяется для задания результатных потоков работы;
• нижняя сторона применяется для задания исполнителей [9].

Рис. 1. Пример функционального блока в IDEF0

2. IDEF3 (Integrated DEFinition for Process Description Capture Method) – это нотация которая выступает в качестве средств для описания разных технологических процессов, что имеют место для конкретного предприятии. Содержит набор свойств и графических объектов по работы сценариев развития ИС. Сценарием, в рассматриваемой нотации, принято называть формальное описание последовательностей для модификации различных объектов в рамках процессов [4].

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

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

Нотация IDEF3 широко применяется при создании процессов, поскольку данная методология дополняет IDEFO благодаря очень широкому набору разных функциональных компонентов, что позволяют обеспечение комплексного подхода при осуществлении имитационного анализа объекта (рисунок 2).

Рис. 2. Образец IDEF3 диаграммы

3. DFD (Data Flow Diagram) – нотация, что организует корректное описание разных выходов системы при входном на систему.[2] Все DFD диаграммы выступают как одно из наиболее гибких методов моделирования различных возможностей проектируемой ИС. Реализация нотации DFD диаграмм основывается на использовании таких главных понятий: потоки данных, структурные процессы (вход-выход), некоторые сущности и хранилища информации [9].

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

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

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

Рис. 3. DFD диаграмма

1.2. Основные понятия теории баз данных

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

База данных (БД) - именованная совокупность данных, отражающая состояние объектов и их отношений в рассматриваемой предметной области. Под предметной областью понимается некоторая область человеческой деятельности или область реального мира, на основе которой создается БД и её структура.[8]

Система управления базами данных (СУБД) - совокупность языковых и программных средств, предназначенных для создания, наполнения, обновления и удаления баз данных.

Принципы построения баз данных

К современным базам данных, а, следовательно, и к СУБД, на которых они строятся, предъявляются следующие основные требования:[7]

– Высокое быстродействие (малое время отклика на запрос). Время отклика - промежуток времени от момента запроса к БД до фактического получения данных.

– Простота обновления данных.

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

– Совместное использование данных многими пользователями.

– Безопасность данных - защита данных от преднамеренного или непреднамеренного нарушения секретности, искажения или разрушения.

– Стандартизация построения и эксплуатации БД (фактически СУБД).

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

– Простой интерфейс пользователя.[9]

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

Основные этапы проектирования баз данных:

1) Концептуальное (инфологическое) проектирование – построение формализованной модели предметной области. Такая модель строится с использованием стандартных языковых средств, обычно графических, например ER-диаграмм (диаграмм «Сущность-связь»). Такая модель строится без ориентации на какую-либо конкретную СУБД.[6]

Основные элементы данной модели:

– Описание объектов предметной области и связей между ними.

– Описание информационных потребностей пользователей (описание основных запросов к БД).

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

– Описание ограничений целостности, т.е. требований к допустимым значениям данных и к связям между ними.[4]

2) Логическое (даталогическое) проектирование – отображение инфологической модели на модель данных, используемую в конкретной СУБД, например на реляционную модель данных. Для реляционных СУБД даталогическая модель – набор таблиц, обычно с указанием ключевых полей, связей между таблицами. Если инфологическая модель построена в виде ER-диаграмм (или других формализованных средств), то даталогическое проектирование представляет собой построение таблиц по определённым формализованным правилам, а также нормализацию этих таблиц. Этот этап может быть в значительной степени автоматизирован.

3) Физическое проектирование – реализация даталогической модели средствами конкретной СУБД, а также выбор решений, связанных с физической средой хранения данных: выбор методов управления дисковой памятью, методов доступа к данным, методов сжатия данных и т.д. – эти задачи решаются в основном средствами СУБД и скрыты от разработчика БД.[5]

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

– основные объекты предметной области (объекты, о которых должна храниться информация в БД);

– атрибуты объектов;

– связи между объектами;

– основные запросы к БД.

Рассмотрим одну из самых популярных СУБД – MS Access.

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

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

Это помогает избежать рутинных действий, облегчает работу неопытному пользователю.[8]

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

В плане обеспечения целостности данных MS Access отвечает лишь моделям средней сложности. В нем не используются такие объекты как хранимые процедуры и триггеры, что заставляет разработчиков создавать клиентские программы для поддержания бизнес-логики БД.[1]

Однако, при указанных недостатках MS Access располагает большим количеством преимуществ.

В первую очередь отметим распространенность, что обусловлена принадлежностью СУБД компании Microsoft, операционные системы и программное обеспечение которой использует множество пользователей ПК. MS Access абсолютно совместим с ОС Windows, постоянно обновляется, поддерживает различные языки.

MS Access предоставляет за небольшую стоимость огромное количество возможностей. Также отметим ориентированность на пользователей с различной профессиональной подготовкой. Это выражается в наличии различных вспомогательных средств, развитую справочную систему и интуитивно понятный интерфейс. Данные средства облегчают проектирование и создание БД, выборку из нее данных.[5]

В распоряжение непрограммирующим пользователям MS Access предоставляет разнообразные диалоговые средства, что позволяют им создавать приложения, при этом не прибегая к непосредственной разработке запросов с помощью языка SQL или к программированию вспомогательных модулей или макросов на языке VBA.[4]

Также Access обладает большими возможностями по экспорту/импорту данных в разнообразные форматы через механизм ODBC: от текстовых файлов и таблиц Excel до любой серверной СУБД.

Еще одним немаловажным преимуществом MS Access является встроенные средства разработки приложений. Большое количество приложений, которые распространяемые среди пользователей, содержат некоторый объем кода языка Visual Basic for Applications. [1]

VBA – единственное средство для выполнения различных стандартных задач в MS Access (построение команд SQL, обработка ошибок, работа с переменными, использование Windows API), для создания сложных приложений.

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

Одной из самых необходимых функций каждой СУБД является защита информации, которая размещена в таблицах базы данных. [6]

СУБД MS Access хранит данные о защите в двух местах. При установке программа Setup создает в папке Program Files\Microsoft_Ofice\Оffice стандартный файл для рабочей группы – System.mdw, который далее при запуске Access используется по умолчанию. [3]Этот файл содержит информацию обо всех группах и пользователях. При создании новой базы данных MS Access сохраняет данные о правах, которые предоставляются конкретным группам и пользователям, непосредственно в файле базы данных.[8]

Расположение файла рабочей группы находится в реестре Windows. Можно также использовать служебную программу операционной системы Windows – Wrkadm.exe (администрирование рабочих групп) для редактирования текущего или создания новой рабочей группы. Также можно выбрать необходимый файл рабочей группы при выполнении приложения, задав при этом соответствующий параметр в командной строке. [5]

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

2.Описание операций бизнес-процесса «Продажи»

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

Предметная область выполнения курсовой работы – продуктовый магазин. С точки зрения рассмотрения бизнес-процессов и проектирования базы данных в данной предметной области имеются следующие конечные пользователи: заведующий магазином, бухгалтер, продавец. Опишем предметную область с точки зрения конечных пользователей.[3]

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

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

У каждого товара мне необходимо проверить срок годности, и соответствует ли его наименование накладной.

После чего считается общее количество каждого товара, стоимость каждого вида товара (цена закупки * количество товаров) и общая стоимость поставки (сумма стоимостей каждого вида товара), которые тоже сверяются с накладной. [9]

На основе этого составляется отчет о приеме товара за день со всеми реквизитами поставщика (наименование, адрес, ИНН, КПП, расчетный счет для оплаты поставки) и данными о торговом представителе (ФИО, телефон, электронная почта) и товаре (наименование, штрих-код, количество, цена закупки). [2]

Бухгалтер в конце дня получает от заведующего магазином отчет о приеме товара за этот день, и размещает информацию о полученных товарах по каждому поставщику в отдельный журнал. Если товар от этого поставщика был поставлен впервые, то для него необходимо завести новый журнал, куда записываются все его данные: наименование, адрес, ИНН, КПП, расчетный счет. По каждому товару записывается наименование, штрих-код, количество, цена закупки, рассчитывается и записывается цена продажи (цена закупки * 1,3). На основе этого формируется отчет о товарах и их розничных ценах, в котором указывается наименование товара, штрих-код и его цена продажи. [4]

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

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

На основе отчета о приеме товара за день составляется платежное поручение на сумму задолженности каждому поставщику, в котором указываются реквизиты поставщика, номер накладной и сумма задолженности (сумма цен закупки товара умноженных на их количество). Платежное поручение относится в банк для оплаты задолженности. [4]

2.2. Описание операций бизнес-процесса «Продажи»

Построим IDEF0 диаграммы для описания процесса «Продажи». Рассмотрим уровень А0 указанного процесса (рис.4):

Рисунок 4 – Контекстная диаграмма

Стоит отметить, что входами в процессе являются:[1]

– покупка товара;

– поставка товара;

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

– план продаж;

– накладная.

В функционировании бизнес-процессов берут участие:[5]

– продавец;

– покупатель.

В результате выполнения операций формируются:

– кассовый чек;

– отчет по продажам.

Для более детального описания процесса нужно выполнить детализацию бизнес-процесса «Продажи».[6]

Рисунок 5 – Детализация контекстной диаграммы

На рисунке 5 показано расщепление первичного бизнес-процесса «Продажи» на несколько подпроцессов:[3]

– выбор товара;

– продажа товара;

– выдача товара.

Анализ составных частей процесса (входов, выходов и т.д.) выполняется аналогично контекстной диаграмме.[5]

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

3. Практическая реализация операций бизнес-процесса «Продажи»

3.1. Проектирование и разработка таблиц базы данных

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

Рассмотрим процесс создания таблицы в СУБД MS Access 2016, а именно с помощью конструктора таблиц.

После запуска СУБД и создания базы данных нужно нажать на ленту «Создание» и выбрать в разделе «Таблицы» Конструктор таблиц (рис.6)

Рис.6. Выбор конструктора таблиц.

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

Рис.7. Таблица Товар в режиме конструктора

Аналогичным образом создаем остальные таблицы.

В MS Access можно задать следующие типы данных: [5]

• Короткий текст – предназначен для хранения символьной информации, длиной не более 255 символов.
• Длинный текст – тип данных, предназначен для хранения символьной информации, практически, любой длины. Ограничение может становить только объем использованной памьяти для хранения данных. Стоит отметить, что указанный тип является аналогом типа «поле МЕМО» в версиях MS Access 2003 и раннее.[1]
• Числовой – предназначен для хранения и отображения числовой информации.
• Дата и время – в полях данного типа данных есть возможность хранить информацию в виде различных форматов даты и времени. Например, длинный формат даты – 4 сентября 2015 года; краткий формат времени – 12:55.
• Денежный – отображает числовую информацию с символом определенной денежной единицы.[6]
• Счетчик – специальный тип данных, отображающий значения, размещенные по порядку (по умолчании, по возрастанию).
• Логический – тип данных, предназначенный для обозначения логических значений: да и нет, 1 и 0, истина и ложь.
• Поле объекта OLE – формат данных для вставки текстовых документов и других объектов, созданных в различных прикладных программах.
• Гиперссылка – тип данных, предназначенный для вставки гиперссылок на документы, веб-страницы, мультимедиа-файлы.
• Вложение – предназначен для вложения одного или нескольких изображений. На практике использовать указанный выше тип данных можно для вставки в форму изображения, например, товаров, фотографий сотрудников и прочих графических файлов.
• Вычисляемый – поле, предназначенное для создания вычислительных полей в таблице. [10]
• Мастер подстановок – мастер, в процессе выполнения которого будет создан раскрывающейся список.

Рассмотрим процесс «связывания» таблиц. Для этого нужно открыть окно «Схема данных» и добавить все созданные таблицы. После этого надо перетащить нужные нам поля одно на другое. После этого откроется окно (рис. 8).[9]

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

Рис.8. Обеспечение целостности данных при связывании таблиц

Выполнив эту процедуру для всех таблиц, получим структуру (рис.9):[4]

Рис.9. Схема данных

3.2. Создание вспомогательных объектов базы данных

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

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

Создадим следующие запросы:[8]

– Товары по таблицам Товар и Продажа товаров:

Рис. 10. Запрос Товары в режиме конструктора

Рис.11. Запрос Товары в режиме просмотра

– Количество выбитых чеков (из таблицы Продажа товаров):[3]

Рис.12. Запрос Количество выбитых чеков в режиме конструктора

Рис.13. Запрос Количество выбитых чеков в режиме просмотра

– Минимальное количество поставленных товаров (из таблицы Поставка товаров):[2]

Рис.15 Запрос Минимальное количество поставленных товаров в режиме конструктора

Рис.16. Запрос Минимальное количество поставленных товаров в режиме просмотра

– Наименование товара по алфавиту (из таблицы Товар):[1]

Рис.17. Запрос Наименование товара по алфавиту в режиме конструктора

Рис.18. Запрос Наименование товара по алфавиту в режиме просмотра

– Менеджеры поставок (из таблицы Менеджеры поставок):[9]

Рис.19. Запрос Менеджеры поставок в режиме конструктора

Рис.20. Запрос Менеджеры поставок в режиме просмотра

– Товар с истекшим сроком годности (из таблицы Товар):[8]

Рис.21. Запрос Товар с истекшим сроком годности в режиме конструктора

Рис.22. Запрос Товар с истекшим сроком годности в режиме просмотра

Аналогично запросам в Access можно создать для отбора данных фильтры.[5]

– Фильтры для отображения поставщиков разных фирм:

Рис.23. Фильтр для отображения поставщиков разных фирм в режиме просмотра

– Фильтры для отображения товаров (Печенье и Зефир):[5]

Рис.24. Фильтр для отображения товаров в режиме просмотра

– Фильтры для отображения Менеджеров поставок:

Рис.25. Фильтр для отображения Менеджеров поставок в режиме просмотра

– Фильтры для отображения Различных категорий товаров:[2]

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

Аналогично можно создать формы – элемент базы данных для удобного отображения или ввода данных. [6]

В базе разработаны формы (простые и составные) для заполнения таблиц. Рассмотрим некоторые из них:[4]

Рис.27. Составная форма Менеджеры поставок

Рис.28. Простая форма Товар

В базах данных при необходимости создаются отчеты – элементы базы данных для удобного вывода полученной информации на печать.[7]

Построим отчет Менеджер поставок. Для этого вызовем мастер создания отчетов (Создание – Отчеты – Мастер отчетов). Далее нужно:[9]

– выбрать таблицу «Менеджер поставок» и переместить поля в категорию Выбранные;

– пропустить уровень группировки;

– выполним сортировку по полю Фамилия;

– отметим макет Табличный, ориентация Книжная и нажмем кнопку Далее;[7]

– в последнем окне задаем имя Отчета, например «Менеджер поставок».

Рис.29. Отчет менеджер поставок

Одним из самых распространенных элементов администрирования является установка пароля на базу. Для этого нужно нажать Файл – Зашифровать с использованием пароля:[4]

Рис.30. Установка пароля

В результате при открытии базы появится окно:[7]

Рис.31. Ввод пароля

В процессе написания главы 3 создана база данных, которая описывает операции бизнес-процесса «Продажи», а именно:

– созданы таблицы БД;

– описана схема данных базы;

– созданы вспомогательные элементы БД.

ЗАКЛЮЧЕНИЕ

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

В процессе написания курсовой работы были реализованы следующие задачи:

– рассмотрены основные определения теории бизнес-процессов и баз данных;

• выполнено описание предметной области;
• выполнено моделирование бизнес-процессов для реализации продаж;
• разработано в MS Access базу данных, которая демонстрирует основные бизнес-процессы при продаже;
• выполнено создание вспомогательных объектов (запросов, форм, отчетов) для описания различных функций продаж.

В процессе анализа вышеизложенной информации выявлены следующие достоинства рассмотренной базы данных при реализации бизнес-процесса «Продажи»:

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

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

1. Балдин, К.В. Информационные системы в экономике: Учебное пособие / К.В. Балдин. - М.: НИЦ ИНФРА-М, 2013. - 218 c.
2. Блиновская, Я.Ю. Введение в геоинформационные системы: Учебное пособие / Я.Ю. Блиновская, Д.С. Задоя. - М.: Форум, НИЦ ИНФРА-М, 2013. - 112 c.
3. Бодров, О.А. Предметно-ориентированные экономические информационные системы: Учебник для вузов / О.А. Бодров. - М.: Гор. линия-Телеком, 2013. - 244 c.
4. Варфоломеева, А.О. Информационные системы предприятия: Учебное пособие / А.О. Варфоломеева, А.В. Коряковский, В.П. Романов. - М.: НИЦ ИНФРА-М, 2013. - 283 c.
5. Васильков, А.В. Информационные системы и их безопасность: Учебное пособие / А.В. Васильков, А.А. Васильков, И.А. Васильков. - М.: Форум, 2013. - 528 c.
6. Мартынова В.П. Базы данных. Распределенные и удаленные БД. Т.1: Учебник/В.П. Мартынова.–М.:ИД ФОРУМ,НИЦ ИНФРА-М, – 2013. – 272 c.
7. Мартынова В.П. Базы данных. Распределенные и удаленные БД. Т.1 / В.П. Мартынова.– М.: ИД ФОРУМ,НИЦ ИНФРА-М,2013. – 352 c.
8. Ракован О.Л. Базы данных / О.Л. Ракован – М.:Форум, 2014. – 352 c.
9. Ракован О.Л.Базы данных: Учебное пособие/О.Л. Ракован. - М.:Форум, 2012.–400 c.
10. Малевич И.П. Базы данных:Учебное пособие /И.П. Малевич. - СПб.:Питер, 2013.– 240 c.