Информационная система картинной галереи

Выполнение курсового проекта на тему: «Информационная система дизайн-студии Timko-Design» объясняется острой необходимостью автоматизации бизнес-процессов протекающих в организации, а именно учета выполнения заказов, поступающих от клиентов.

В случае применения, не автоматизированного учета, возникают следующие сложности:

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

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

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

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

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

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

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

В IDEFIX имеется ясный графический язык для описания объектов и отношений в приложениях. Этот язык есть язык диаграмм «сущность-связь» (ERD).

Первый вариант модели «сущность-связь» был предложен в 1976 г. Питером Пин-Шэн Ченом.

6 стр., 2883 слов

На английском языке Средства массовой информации (СМИ)/ Mass ...

... район, Ставропольский край, Россия Сочинение на английском языке с переводом. Номинация Мой мир. Mass media plays an important role in my life. It helps me ... brother and a lot of different cartoons in the house. My favourite cartoon is «Sponge Bob». It is very funny and ... именно от СМИ. К сожалению, мы не можем контролировать эту информацию на все 100% Конечно, новости по ТВ и некоторые программы — ...

Разработка информационной модели по IDEFIX выполняется за несколько стадий:

Стадия 0. Выясняются цели проекта, составляется план сбора информации. Обычно исходные положения для информационной модели следуют из IDEF0-модели.

Стадия 1. Выявление и определение сущностей. Это неформальная процедура.

Стадия 2. Выявление и определение основных отношений. Результат представляется или графически в виде ER-диаграмм, или в виде матрицы отношений.

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

Стадия 4. Определение атрибутов и их принадлежности сущностям.

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

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

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

1. Клиент — это физическое или юридическое лицо, которое заказало оказание каких-либо услуг или приобрело продукции у фирмы;

2. Сотрудник — это сотрудник фирмы, принявший или, который был назначен на исполнение заказа;

3. Продукция — это товар, реализуемая организацией;

4. Услуги — это услуги оказываемые организацией клиентам;

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

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

Определение взаимосвязей сущностей;

  • Рассмотрим взаимосвязи выделенных сущностей на этапе анализа предметной области.

Клиент может осуществить один или несколько заказов. В заказе может фигурировать только одна фамилия клиента. Таким образом, связь один ко многим.

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

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

По одному заказу может быть оказано множество услуг, одна и та же услуга может фигурировать во множестве заказов. Таким образом, связь многие ко многим.

Построение концептуальной модели (модель сущность-связь);

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

Рис. 1. Концептуальная модель.

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

Вход

Название сущности

Вид связи

Семантика связи

R1

М:1

R2

1:М

R3

М:1

R4

1:М

R5

М:1

R6

1:М

R7

М:1

R8

1:М

R9

М:1

R10

1:М

R11

М:1

R12

1:М

R13

1:1

R14

1:1

Определение логической модели реляционной БД;

  • Определить перечень необходимых функций, подлежащих автоматизации;

Рассмотрим функции, которые будут автоматизированы в результате реализации информационной системы:

  • Ведение базы данных по клиентам дизайн студии;
  • Учет всех выполненных заказов;
  • Ведение реестра всех оказываемых услуг;
  • Ведение реестра всей реализуемой продукции;

Кроме того реализуемая информационная система должна позволять осуществлять расчеты:

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

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

Определить логическую модель БД с учетом выбранной СУБД;

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

Microsoft Access 2003 является реляционной СУБД, в связи с чем реализация отношений типа многие ко многим не рекомендуется, поэтому были введены две дополнительные сущности:

1. Услуги по заказу — отражает информацию по оказываемым услугам по определенному заказу;

2. Продукция по заказу — отражает информацию по реализуемой продукции согласно заказу.

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

На рисунке 2 представлена логическая модель с учетом выбранной СУБД.

Рис. 2. Физическая модель базы данных.

Описать сущности в терминах таблиц (в случае реляционной СУБД);

  • Рассмотрим более подробно создаваемые таблицы для отражения необходимой информации относительно сущностей. В таблице 1 представлено описание создаваемой таблицы «Услуги».

Таблица 1. Таблица «Услуги»

Наименование

Тип данных

Размерность

Ключевое поле

Код услуги

Счетчик

Первичный

Наименование услуги

Текстовый

50

В таблице 2 представлено описание создаваемой таблицы «Клиент».

Таблица 2. Таблица «Клиент»

Наименование

Тип данных

Размерность

Ключевое поле

Код клиента

Счетчик

Первичный

ФИО клиента

Текстовый

50

Контакт

Текстовый

14

В таблице 3 представлено описание создаваемой таблицы «Сотрудник».

Таблица 3. Таблица «Сотрудник»

Наименование

Тип данных

Размерность

Ключевое поле

Код сотрудника

Счетчик

Первичный

ФИО сотрудника

Текстовый

50

Дата рождения

Дата

Номер паспорта

Текстовый

12

Контакты

Текстовый

14

В таблице 4 представлено описание создаваемой таблицы «Продукция».

Таблица 4. Таблица «Продукция»

Наименование

Тип данных

Размерность

Ключевое поле

Код продукции

Счетчик

Первичный

Наименование продукции

Текстовый

50

В таблице 5 представлено описание создаваемой таблицы «Заказ». Таблица 5.

Таблица «Заказ»

Наименование

Тип данных

Размерность

Ключевое поле

Номер заказа

Счетчик

Первичный

Дата заказа

Дата

Дата выполнения

Дата

Скидка

Числовой

Код клиента

Числовой

Внешний

Код сотрудника

Числовой

Внешний

В таблице 6 представлено описание создаваемой таблицы «Услуги по заказу».

Таблица 6. Таблица «Услуги по заказу»

Наименование

Тип данных

Размерность

Ключевое поле

Номер заказа

Числовой

Первичный, внешний, составной

Код услуги

Числовой

Первичный, внешний, составной

Цена

Денежный

В таблице 7 представлено описание создаваемой таблицы «Продукция по заказу».

Таблица 7. Таблица «Продукция по заказу»

Наименование

Тип данных

Размерность

Ключевое поле

Номер заказа

Числовой

Первичный, внешний, составной

Код продукции

Числовой

Первичный, внешний, составной

Количество

Числовой

Цена

Денежный

Обеспечить целостность данных и ссылочную целостность (визуализация с помощью схемы БД);

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

Ввести необходимые ограничения на ввод данных. (не менее 8-10 страниц);

В результате анализа предметной области должны быть выявлены:

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

(Не менее 16-20 страниц с иллюстрациями и поясняющим текстом)

2. Разработка алгоритмов и технологии решения задачи

Определение макета форм ввода-вывода для загрузки в БД входной информации

Рассмотрим созданные формы для осуществления ввода данных в базу данных.

На рисунках 4-8 представлены созданные формы ввода.

Рис. 4. Форма ввода «Клиент»

Рис. 5. Форма ввода «Сотрудник»

Рис. 6. Форма ввода «Услуги»

Рис. 7. Форма ввода «Продукция»

Рис. 8. Форма ввода «Заказ»

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

Рассмотрим созданные запросы для реализации выборки данных из базы данных. Ниже представлен программный код запроса «Доход от сотрудников».

SELECT Сотрудник.[ФИО Сотрудника], Sum([Продукция по заказу].[Цена]*[Продукция по заказу].[Количество]) AS [Сумма по продукции], Sum([Услуги по заказу].Цена) AS [Сумма по услугам]

FROM (Сотрудник INNER JOIN (Заказ LEFT JOIN [Услуги по заказу] ON Заказ.[Номер заказа] = [Услуги по заказу].[Номер заказа]) ON Сотрудник.КодСотрудника = Заказ.КодСотрудника) LEFT JOIN [Продукция по заказу] ON Заказ.[Номер заказа] = [Продукция по заказу].[Номер заказа]

GROUP BY Сотрудник.[ФИО Сотрудника];

Рис. 9. Результат запроса «Доход от сотрудников»

Ниже представлен программный код запроса «Заказы выполненные сотрудником».

SELECT Заказ.[Номер заказа], Клиент.[ФИО Клиента], Клиент.Контакт, Заказ.[Дата заказа], Заказ.[Дата выполнения]

FROM Сотрудник INNER JOIN (Клиент INNER JOIN Заказ ON Клиент.[Код клиента] = Заказ.[Код клиента]) ON Сотрудник.КодСотрудника = Заказ.КодСотрудника

WHERE (((Сотрудник.[ФИО Сотрудника])=[Введите ФИО сотрудника]));

  • На рисунке 10 представлен результат выполнения данного запроса.

Рис. 10. Результат запроса «Заказы выполненные сотрудником»

Ниже представлен программный код запроса «Заказы клиента».

SELECT Заказ.[Номер заказа], Заказ.[Дата заказа], Заказ.[Дата выполнения]

FROM Клиент INNER JOIN Заказ ON Клиент.[Код клиента] = Заказ.[Код клиента]

WHERE (((Клиент.[ФИО Клиента])=[Введите ФИО клиента]));

  • На рисунке 11 представлен результат выполнения данного запроса.

Рис. 11. Результат запроса «Заказы клиента»

Ниже представлен программный код запроса «Постоянные клиенты».

SELECT Клиент.[ФИО Клиента], Клиент.Контакт

FROM Клиент INNER JOIN Заказ ON Клиент.[Код клиента]=Заказ.[Код клиента]

GROUP BY Клиент.[ФИО Клиента], Клиент.Контакт

HAVING (Count(Клиент.[ФИО Клиента])>1);

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

Рис. 12. Результат запроса «Постоянные клиенты»

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

SELECT Заказ.[Номер заказа], Продукция.[Наименование продукции], [Продукция по заказу].Количество, Клиент.[ФИО Клиента], Клиент.Контакт

FROM (Клиент INNER JOIN Заказ ON Клиент.[Код клиента] = Заказ.[Код клиента]) INNER JOIN (Продукция INNER JOIN [Продукция по заказу] ON Продукция.[Код продукции] = [Продукция по заказу].[Код продукции]) ON Заказ.[Номер заказа] = [Продукция по заказу].[Номер заказа]

WHERE (((Заказ.[Номер заказа])=[Введите номер заказа]));

  • На рисунке 13 представлен результат выполнения данного запроса.

Рис. 13. Результат запроса «Продукция по номеру заказа»

Ниже представлен программный код запроса «Текущие заказы».

SELECT Заказ.[Номер заказа], Заказ.[Дата заказа], Заказ.[Дата выполнения], Клиент.[ФИО Клиента], Клиент.Контакт, Сотрудник.[ФИО Сотрудника], Сотрудник.Контакты

FROM Сотрудник INNER JOIN (Клиент INNER JOIN Заказ ON Клиент.[Код клиента]=Заказ.[Код клиента]) ON Сотрудник.КодСотрудника=Заказ.КодСотрудника

WHERE (Заказ.[Дата выполнения]>Now());

  • На рисунке 14 представлен результат выполнения данного запроса.

Рис. 14. Результат запроса «Текущие заказы»

Ниже представлен программный код запроса «Услуги по номеру заказа».

SELECT Заказ.[Номер заказа], Услуги.НаименованиеУслуги, Клиент.[ФИО Клиента], Клиент.Контакт

FROM Клиент INNER JOIN (Услуги INNER JOIN (Заказ INNER JOIN [Услуги по заказу] ON Заказ.[Номер заказа] = [Услуги по заказу].[Номер заказа]) ON Услуги.КодУслуги = [Услуги по заказу].КодУслуги) ON Клиент.[Код клиента] = Заказ.[Код клиента]

WHERE (((Заказ.[Номер заказа])=[Введите номер заказа]));

  • На рисунке 15 представлен результат выполнения данного запроса.

Рис. 15. Результат запроса «Услуги по номеру заказа»

программа автоматизация алгоритм отчет

Разработка необходимых отчетов для вывода результатов работы с БД. (не менее 5-10 страниц)

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

Рис. 16. Отчет «Заказы сотрудников»

Рис. 17. Отчет «Реализованная продукция клиентам»

Рис. 18. Отчет «Реализованные услуги»

Заключение

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

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

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

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

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

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

Список использованных источников

[Электронный ресурс]//URL: https://liarte.ru/kursovaya/kartinnaya-galereya/

1. Бемер С, Фратер Г., MS Access 2003 для пользователя, М., «Бином», 2004

2. Биллиг В.А., Дехтярь М.И., VBA и Office 2003 Офисное программирование, М., изд. «Русская редакция», 2004

3. Вейскас Д., Эффективная работа с Microsoft Access 2003, С.-Пб.,2005

4. Винтер Рик, Microsoft Access 2003, Справочник, С.-Пб., «Питер», 2007

5. Гусева Т.И., Башин Ю.Б. , Проектирование баз данных в примерах и задачах, М.,2003

6. Козырев А.А. Информационные технологии в экономике и управлении. — СПб.: Изд-во Михайлова В.А., 2003

7. Уткин В.Б., Балдин К.В. Информационные системы и технологии в экономике. — М.: ЮНИТИ, 2003

8. Хотинская Г.И. Информационные технологии управления. — М.: Дело и Сервис (ДИС), 2003.

9. Хоффбауэр М., Шпильманн К., ACCESS 2003, Сотни полезных рецептов, Киев, «BHV», 2004