Главная Коллекция "Otherreferats" Программирование, компьютеры и кибернетика Информационная система по учету и реализации товаров торгово-посреднической фирмы "Столица"

Информационная система по учету и реализации товаров торгово-посреднической фирмы "Столица"

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

Рубрика Программирование, компьютеры и кибернетика
Вид курсовая работа
Язык русский
Дата добавления 22.01.2011
Размер файла 1,5 M

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Введение

Развитие информационных систем, как элемента управления, тесно связано с изменениями, происходящими в области их применения. Эти перемены затронули как отрасли экономики в целом, так и отдельные субъекты в экономике (организации и предприятия). Благодаря научно - техническому прогрессу всё чаще стали появляться новые программные средства, которые делают значительно эффективной автоматизацию различных процессов в экономике. Не смотря на всё это, до сих пор на некоторых организациях учёт данных, их обработка и использование ведется в ручную.

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

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

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

Объектом исследования данной курсовой работы является торгово-посредническая фирма «Столица»

Предметом исследования является процесс учета реализации товаров на предприятии.

При написании данного курсового проекта необходимо решить следующие задачи:

· провести предпроектное обследование предприятия, на котором будет внедряться разработанная автоматизированная система;

· изучить бизнес-процессы данного предприятия с точки зрения выбранной темы;

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

1. Предпроектное обследование, анализ предметной области, постановка задачи

1.1 Сбор материалов обследования

Разрабатываемая система учёта реализации товаров предприятия

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

Реализация товаров народного потребления и продукции производственно-технического назначения;

Торговой, торгово-посреднической, закупочной и кроме того, оно создаёт торговые подразделения и предприятия;

Транспортировкой грузов автомобильным транспортом, как собственным, так и привлечённым.

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

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

1.2 Организационная структура предприятия, функции основных отделов предприятия

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

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

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

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

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

1.3 Обоснование выбора автоматизированных процессов

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

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

· Покупка товара у изготовителя;

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

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

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

· большие объёмы ежегодно создаваемой, обрабатываемой и хранимой информации (до нескольких сотен млн. символов в год для среднего предприятия);

· большая часть этой информации имеет символьное представление, слабо приспособленное для логической и арифметической обработки;

· высокий уровень стоимостных и трудовых затрат на поиск и ее обработку.

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

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

Входная и выходная информация должна формироваться в удобном и понятном для восприятия электронном виде. При этом она должны быть представлена в соответствии утвержденными формами.

1.4 Общие сведения, назначение системы и цели её создания

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

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

· получение более общих или наиболее детализированных отчетов по итогам всего процесса учета за определенный временной интервал;

· позволять легко определять тенденцию в изменении важнейших показателей непосредственно относящихся к исследуемым объектам;

· выполнять точный и полный анализ данных и др.

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

Должна существовать возможность:

· просмотра данных о любом приобретенном товаре;

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

· создание различного рода отчетов;

· добавление и удаление объектов, товаров;

· отслеживание новых покупателей.

2. Технология информационного проектирования

2.1 Моделирование процессов

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

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

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

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

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

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

Модель может содержать четыре типа диаграмм:

· контекстную диаграмму (в каждой модели может быть только одна контекстная диаграмма);

· диаграммы декомпозиции;

· диаграммы дерева узлов;

· диаграммы только для экспозиции (FEO).

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

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

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

Кроме того, в IDEF0 различают пять типов стрелок:

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

Управление (Control) - правила, стратегии, процедуры или стандарты, которыми руководствуется работа. Каждая работа должна иметь хотя бы одну стрелку управления.

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

Механизм (Mechanism) - ресурсы, которые выполняют работу, например персонал предприятия, станки, устройства и т.д.

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

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

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

Рассмотрим созданную в данной курсовой работе методологию IDEF0.

Контекстная диаграмма «Производственная деятельность фирмы».

Контекстная диаграмма «Производственная деятельность фирмы «Столица»

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

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

Диаграмма декомпозиции по работе «Производственная деятельность фирмы «Столица»

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

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

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

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

Далее эти работы мы будем декомпозировать в DFD диаграммы.

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

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

* функции обработки информации (работы);

* документы (стрелки, arrows), объекты, сотрудников или отделы, которые участвуют в обработке информации;

* внешние ссылки (external references), которые обеспечивают интерфейс с внешними объектами, находящимися за границами моделируемой системы;

* таблицы для хранения документов (хранилище данных, data store).

В BPwin для построения диаграмм потоков данных используется нотация Гейна - Сарсона.

В отличие от стрелок IDEF0, которые представляют собой жесткие взаимосвязи, стрелки DFD показывают, как объекты (включая данные) двигаются от одной работы к другой. Это представление потоков совместно с хранилищами данных и внешними сущностями делает модели DFD более похожими на физические характеристики системы - движение объектов (data flow), хранение объектов (data stores), поставка и распространение объектов (external entities).

Диаграмма декомпозиции для работы «Реализация товара»

Декомпозировали данный процесс на следующие работы: Изготовление товара и Продажа товара фирмой.

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

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

Диаграмма декомпозиции для работы «Покупка товара»

Мы декомпозировали процесс Покупка товара фирмой на 2 работы: непосредственно сама покупка товара и учет купленного товара.

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

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

2.2 Выявление сущностей, связей, ключей и отношений

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

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

Методология ER-моделирования разработана П. Ченом в конце 1970-х годов. Для представления сущностей в методологии ER используются прямоугольники. В исходной ER-нотации Чена отношения содержат атрибуты. Равная возможность использования атрибутов в сущностях и отношениях делает различие между сущностями и отношениями достаточно сложным.

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

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

Сущность имеет следующие признаки:

· Она имеет имя и описание.

· Она представляет класс, а не единичный экземпляр абстракции.

· Ее конкретные представители (экземпляры) могут быть уникально идентифицированы.

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

Существует две основных группы сущностей: зависимые и независимые. Независимая сущность не нуждается в информации из другой сущности для идентификации уникального экземпляра. Она представляется в ERwin в виде прямоугольника. Первичный ключ независимой сущности не включает в себя первичных ключей других сущностей. Зависимая сущность должна привлекать информацию из другой сущностей для идентификации уникального экземпляра. Она представляется на ER-диаграмме в виде прямоугольника с закругленными углами. Первичный ключ зависимой сущности включает первичные ключи одной или более родительских сущностей.

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

Связь является логическим соотношением между сущностями. Каждая связь должна именоваться глаголом или глагольной фразой. Имя связи выражает некоторое ограничение или правило и облегчает чтение диаграммы. Ниже на рисунке представлены связи рассматриваемого проекта.

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

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

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

(NULL). Все части ключа являются обязательными и не могут быть опущены.

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

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

Родительская сущность

Название

Зависимая сущность

Мощность

Фирма - продавец товара

Продает

Товар

1:N

Фирма - покупатель товара

Покупает

Товар

1:N

Вид товара

Определяет

Товар

1:N

Изготовитель

Производит

Товар

1:N

Заметим, что поскольку были выделены объекты, отвечающие требованиям нормализации, то установлены связи с отношениями типа один ко многим. Связь 1:N означает, что каждый экземпляр первой сущности может быть связан с несколькими экземплярами второй сущности, а каждый экземпляр второй сущности может быть связан только с одним экземпляром первой сущности.

В каждой такой связи главный объект связан по уникальному ключу с подчиненным объектом. Если степень бинарной связи равна 1:N и класс принадлежности N-связной сущности является обязательным, то достаточным является использование двух отношений, по одному на каждую сущность, при условии, что ключ каждой сущности служит в качестве первичного ключа для соответствующего отношения. Дополнительно ключ 1-связной сущности должен быть добавлен как атрибут в отношение, отводимое N-связной сущности. В данной модели сущность Товар является подчинённой для остальных сущностей.

Список первичных ключей для сущностей

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

Первичный ключ

Фирма - Продавец товара

Код продавца

Фирма - Покупатель товара

Код покупателя

Вид товара

Код товара

Изготовитель товара

Код изготовителя

2.2 Описание атрибутов сущностей

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

Сущность: ФИРМА - ПРОДАВЕЦ ТОВАРА.

Атрибуты:

1. «Код продавца» Этот атрибут позволяет единственным образом определить каждый экземпляр сущности, т.е. является уникальным, поэтому тип индекса - Primary. Тип данных - текстовый, длинна атрибута 3 символа.

2. «ИНН продавца» числовой (длинное целое)

3. «Страна продавца» текстовый (50)

4. «Юридический адрес фирмы» текстовый (50)

5. «Банк продавца» текстовый (30)

6. «Номер счета в банке» числовой (длинное целое)

7. «Ф.И.О. руководителя фирмы» текстовый (50)

8. «Ф.И.О. главного менеджера фирмы» текстовый (50)

9. «Телефон руководителя» числовой (длинное целое)

10. «Телефон отдела продаж» числовой (длинное целое)

Сущность: ФИРМА - ПОКУПАТЕЛЬ ТОВАРА

Атрибуты:

1. «Код покупателя» (ключевой) - текстовый

2. «ИНН покупателя» числовой (длинное целое)

3. «Страна покупателя» текстовый (50)

4. «Юридический адрес фирмы» текстовый (50)

5. «Ф.И.О. руководителя фирмы» текстовый (50)

6. «Телефон руководителя фирмы» числовой (длинное целое)

7. «Банк покупателя» текстовый (30)

8. «Номер счета в банке» числовой (50)

9. «Количество купленного товара» числовой (длинное целое)

10. «Дата покупки товара» дата / время

Сущность: ВИД ТОВАРА

Атрибуты:

1. «Код товара» (ключевой) - текстовый

2. «Название товара» текстовый (50)

3. «Категория товара» текстовый (50)

4. «Изготовитель товара» текстовый (50)

5. «Дата изготовления товара» дата / время

6. «Срок хранения товара» числовой (длинное целое)

7. «Фото товара»

8. «Покупатель товара» текстовый (50)

9. «Штрих-код товара»

10. «Единица измерения» текстовый (30)

11. «Цена за единицу» числовой (длинное целое)

Сущность: ИЗГОТОВИТЕЛЬ ТОВАРА

Атрибуты:

1. «Код изготовителя» (ключевой) - текстовый

2. «Единица измерения» текстовый (30)

3. «Цена за единицу» числовой (длинное целое)

4. «Количество товара» числовой (длинное целое)

Сущность: ТОВАР

Атрибуты:

1. «Код продавца» текстовый

2. «Код покупателя» текстовый

3. «Код изготовителя» текстовый

4. «Код товара» текстовый.

2.3 Создание модели «сущность-связь» с использованием программного продукта ERWin

Таким образом, была разработана модель «сущность-связь». Для ускорения разработки модели данных используется такое CASE-средство как ERWin. Он имеет 2 уровня представления модели - логический и физический. Создание модели начинается с создания логического уровня. После этого проектировщик выбирает необходимую СУБД.

Для создания моделей в ERWin используется 3 нотации:

Integration DEFinition for Modeling (IDEF1X), Information Engineering (IE), Dimensional Modeling (DM). В данном примере рассматривается только первая нотация. Логическая модель имеет несколько уровней отображения диаграммы: уровень сущностей, уровень атрибутов, уровень определений, уровень первичных ключей и уровень иконок. Рассмотрим процесс создания сущности: ФИРМА - ПРОДАВЕЦ ТОВАРА.

Для внесения сущности в модель необходимо перейти на логический уровень. Для этого можно использовать список выбора, который располагается на стандартной панели инструментов . Затем вызовите панель инструментов ERWin Toolbox, зайдя в пункт меню Windows. Щелкните на кнопке , а затем на том месте рабочей области, где необходимо расположить сущность. Щелкнув правой кнопкой мыши по сущности и выбрав из всплывающего меню пункт Entity Properties, вызовите диалог Entities, в котором определяете имя, описание и комментарий сущности. Вкладка Definition используется для введения определения сущности.

Описание сущности

Для описания атрибутов необходимо, щелкнув правой кнопкой мыши по сущности, выбрать в появившемся меню пункт Attributes. Появляется диалог Attribute Editor.

Описание атрибутов

Для создания нового атрибута необходимо щелкнуть по кнопке New и в появившемся диалоге указать имя атрибута и домен. В ERWin используются следующие домены: Blob - картинка, Datetime - дата\время, Number - числовой, String - строковый. Для атрибутов первичного ключа во вкладке General необходимо сделать пометку в окне выбора Primary Key. Вкладка Definition используется для введения определения атрибута. Создали атрибут «Код продавца», согласно рисунку, а затем по аналогии остальные атрибуты сущности.

На следующем шаге необходимо создать связь. Связь является логическим соотношением между сущностями. Каждая связь должна именоваться глаголом или глагольной фразой. Например, связь между сущностями: ФИРМА - ПРОДОВЕЦ ТОВАРА «Продает» ТОВАР. Данная связь показывает, кто именно продает товар.

Выделяют идентифицирующие и неидентифицирующие связи. Идентифицирующая связь устанавливается между независимой (родительский конец связи) и зависимой (дочерний конец связи) сущностями. Когда рисуется идентифицирующая связь, ERWin автоматически преобразует дочернюю сущность в зависимую. Зависимая сущность изображается прямоугольником со скругленными углами. Экземпляр зависимой сущности определяется только через отношение к родительской сущности. При установлении идентифицирующей связи атрибуты первичного ключа родительской сущности автоматически переносятся в состав первичного ключа дочерней сущности. Эта операция дополнения атрибутов дочерней сущности при создании связи называется миграцией атрибутов. В дочерней сущности новые атрибуты помечаются как внешний ключ - (FK). Такая связь существует между сущностями: ФИРМА - ПРОДАВЕЦ ТОВАРА «Продает» ТОВАР, ФИРМА - ПОКУПАТЕЛЬ ТОВАРА «Покупает» ТОВАР, ВИД ТОВАРА «Определяет» ТОВАР, ИЗГОТОВИТЕЛЬ ТОВАРА «Производит» ТОВАР.

Установить курсор на кнопке панели инструментов ERWin Toolbox соответствующей необходимому типу связи (идентифицирующая - ) и нажать левую кнопку мыши. Щелкнуть сначала по родительской, а затем по дочерней сущности. Для редактирования свойств связи следует «кликнуть» правой кнопкой мыши по связи и выбрать на контекстном меню пункт Relationship Editor. В закладке General появившегося диалога можно задать мощность, имя и тип связи. Имя связи (Verb Phrase) - фраза, характеризующая отношение между родительской и дочерней сущностями.

Кроме того, ERWin позволяет устанавливать правила ссылочной целостности - логические конструкции, которые выражают бизнес-правила использования данных и представляют собой правила вставки, замены и удаления. Триггеры представляют собой программы, выполняемые всякий раз при выполнении команд вставки, замены или удаления (INSERT, UPDATE или DELETE). Правила удаления управляют тем, что будет происходить в БД при удалении строки. Аналогично правила вставки и обновления управляют тем, что будет происходить с БД, если строки изменяются или добавляются. Режимы ссылочной целостности могут быть изменены в диалоге Relationship Editor. Рассмотрим их установку на примере:

Между сущностями ФИРМА - ПРОДАВЕЦ ТОВАРА и ТОВАР существует идентифицирующая связь. Экземпляр сущности ФИРМА - ПРОДАВЕЦ ТОВАРА не может существовать, если отсутствует экземпляр сущности ТОВАР. Так как не возможно выполнение продажи не имея товара. Таким образом, атрибут первичного ключа «Код продавца» не может принимать значение NULL. Значит необходимо либо запретить удаление записи из сущности ФИРМА - ПРОДАВЕЦ ТОВАРА, либо сразу удалять вместе все относящиеся к ней записи из сущности ТОВАР. Мы выбираем второе правило удаления, которое называется каскадом (Parent CASCADE).

Это осуществляется следующим способом: После определения типа связи (идентифицирующая - и неидентифицирующая - ) присваиваем действие триггера Parent Insert - CASCADE, для того чтобы при создании новой записи в родительской сущности ФИРМА - ПРОДАВЕЦ ТОВАРА создавалась хотя бы одна строка в дочерней сущности ТОВАР.

Затем присваиваем действие триггера Parent Delete - CASCADE, для того чтобы при удалении строки в родительской сущности автоматически удалялись соответствующие строки сущности ТОВАР.

3. Реализация информационной системы в СУБД Access

3.1 Общая характеристика СУБД

учет система информационный

В настоящее время существует огромное количество различных систем управления БД. Наиболее распространены такие, как Oracle, SQL Server, Visual FoxPro, Clipper и другие. Все они имеют свои преимущества и недостатки. В качестве инструментальной базы данного проекта была выбрана СУБД MS Access 2003. Access - это реляционная система управления базами данных. Под системой управления понимается комплекс программ, который позволяет не только хранить большие массивы данных в определенном формате, но и обрабатывать их, представляя в удобном для пользователей виде. В реляционной СУБД можно работать одновременно с несколькими таблицами базы данных, это помогает упростить структуру данных и таким образом облегчить выполнение работы.

Access является приложением Windows, а поскольку и Windows и Access разработаны одной фирмой (Microsoft), они очень хорошо взаимодействуют друг с другом. СУБД Access работает под управлением Windows; таким образом, все преимущества Windows доступны в Access. Таблицу Access можно связать с данными, хранящимися на другом компьютере или на сервере, а также использовать таблицу, созданную в СУБД Paradox или Dbase. Данные Access очень просто комбинировать с данными Excel. В СУБД Access предусмотрено много дополнительных сервисных возможностей: мастер - специальная программа, помогающая в решении какой-то задачи или создании объекта определённого типа; выражения; макросы; встроенный язык VBA (Visual Basic for Applications), который дает возможность опытному пользователю программировать сложные процедуры обработки данных; множество средств, разработанных для облегчения работы в Интернет и создания приложений для Web.

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

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

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

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

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

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

Задача описания данных сводится к представлению оперативной информации; задача описания действий над данными - к их реализации с помощью выбранной СУБД и обеспечение надёжности и безопасности БД.

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

· возможность хранения всех необходимых данных;

· исключение избыточных данных;

· сведение числа хранимых отношений к минимуму;

· нормализация отношений для упрощения решения проблем, связанных с обновлением, добавлением и удалением данных.

3.2 Создание таблиц и схемы данных

Таблица - это объект, определяемый для хранения данных. Каждая таблица включает информацию об объекте реального мира, например о предприятии продавце товара. Таблица состоит из заголовка и тела. Заголовок включает имена атрибутов объекта (столбцов) и их свойства, например Код продавца, Ф.И.О. руководителя фирмы и др. Тело содержит кортежи (строки), каждая строка представляет множество значений столбцов, в которых хранятся о конкретном экземпляре объекта.

Способы создания в Access пустой таблицы:

· Режим таблицы - создание таблицы в табличном представлении;

· Конструктор - создание таблиц с помощью конструктора таблиц;

· Мастер таблиц - создание таблиц на основе коллекции таблиц и полей;

· Импорт таблиц - создание таблиц путем импорта таблиц из внешнего файла или из другой БД;

Связь с таблицами - присоединение внешнего файла или таблицы другой БД.

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

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

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

Чтобы объявить Связи между таблицами, нужно:

1. Из меню Сервис выбрать команду Схема данных;

2. Нажать кнопку добавить таблицу, при добавлении необходимых таблиц;

3. В диалоговом окне Изменение связей установить опции: Обеспечение целостности данных, Каскадное обновление связанных полей.

4. Создать связи между таблицами.

3.3 Разработка запросов

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

В курсовом проекте использовались следующие типы запросов:

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

· Запрос на удаление - удаление из таблицы-источника данных (Удаление товара);

· Запрос на обновление - запрос, при котором обновляются данные в записи (Вид товара).

3.4 Разработка форм

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

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

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

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

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

Кнопочная форма

Форма «Вид товара» предназначена для ввода и редактирования данных о товарах, а также просмотра данных.

Форма «Вид товара»

Форма «Покупатель товара» также предназначена для ввода и редактирования данных о покупателях, и просмотра данных.

Форма «Покупатель товара»

Форма «Сведения о продавце товара» предназначена для просмотра данных о фирме «Столица» и редактирования их.

Форма «Сведения о продавце товара»

3.5 Разработка отчетов

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

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

Отчёт «Вид товара» предназначен для наглядного представления на экране и распечатки видов товаров, которые продаются в данное время.

Отчет Вид товара

Отчёт «Поиск товара» предназначен для наглядного преставления на экране и распечатки товара, необходимого покупателю.

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

Заключение

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

В курсовом проекте решены следующие задачи:

· произведено описание предметной области;

· рассмотрен бизнес-процесс;

· спроектирована логическая структура базы данных;

· осуществлено проектирование физической структуры базы данных.

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

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

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

Список литературы

1. Бухгалтерский учёт / Л.И. Хоружий, Р.Н. Расторгуев, Р.А. Алборов; Под ред. Л.И. Хоружий и Р.Н. Расторгуевой. - М.: КолосС, 2004. - 511 с.

2. Маклаков С.В. Создание информационных систем с All Fusion Modeling Suite. - М.: ДИАЛОГ-МИФИ, 2003 - 432 с.

3. Бекаревич Ю.Б., Пушкина Н.В. Самоучитель Microsoft Access 2003. -

СПб.: БХВ-Петербург, 2004. - 752 с.

4. Проектирование баз данных. СУБД Microsoft Access: Учебное пособие

для вузов/ Н.Н. Гринченко, Е.В. Гусев, Н.П. Макаров, А.Н. Пылькин, Н.И. Цуканова. - М.: Горячая линия-Телеком, 2004. - 240 с.

Размещено на Allbest.ru


Подобные документы

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.

© 2000 — 2023, ООО «Олбест» Все права защищены