Введение. Курсовой проект на тему «Проектирование и разработка базы данных для склада» 49 с., 22 рис., 15 источников

РЕФЕРАТ

Курсовой проект на тему «Проектирование и разработка базы данных для склада» 49 с., 22 рис., 15 источников

Объектом исследования является база данных.

Цель работы состоит в приобретении навыков построения модели данных, их практическом применении в построении базы данных средствами СУБД и разработке приложения базы данных в соответствии с темой.

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

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

Эффективность работы характеризуется точностью расчетов и автоматическим формированием списка.

Содержание

Введение. 5

1. Автоматизация процессов управления. 10

1.2. Автоматизированное рабочее место пользователя. 13

2. Описание предметной области складские операции. 14

3. Разработка программного продукта. 26

3.1. Выбор среды разработки. 26

3.2. Информационная модель данных. 29

3.3. Логическая модель данных. 32

3.4. Алгоритм решения задач. 33

3.5. Входные данные. 36

3.6. Выходные данные. 38

3.7. Интерфейс. 40

3.8. Программная документация. 45

3.8.1.Руководство программиста. 45

3.8.2 Руководство пользователя. 45

Заключение. 47

Список используемой литературы.. 48

Введение

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

Так как классификация систем по сфере функционирования объекта управления очевидна, рассмотрим следующие признаки. По видам процессов управления АИС подразделяются на:

АИС управления технологическими процессами - это человеко-машинные системы, обеспечивающие управление технологическими устройствами, станками, автоматическими линиями.

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

Для АИС организационного управления объектом служат производственно-хозяйственные, социально- экономические функциональные процессы, реализуемые на всех уровнях управления экономикой, в частности:

- банковские АИС;

- АИС фондового рынка;

- финансовые АИС;

- страховые АИС;

- налоговые АИС;

- АИС таможенной службы;

- статистические АИС;

АИС промышленных предприятий и организаций (особое место по значимости и распространенности в них занимают бухгалтерские АИС) и др.

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

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

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

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

Территориальные АИС предназначены для управления административно-территориальными районами. Деятельность территориальных систем направлена на качественное выполнение управленческих функций в регионе, формирование отчетности, выдачу оперативных сведений местным государственным и хозяйственным органам.

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

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

- активное участие человека - специалиста в системе автоматизации обработки информации и принятия управленческих решений;

- интерпретация информационной деятельности как одного из видов бизнеса;

- наличие научно обоснованной программно-технической, технологической платформы, реализуемой на конкретном экономическом объекте;

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

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

- постановка и решение конкретных практических задач в области управления с учетом заданных критериев эффективности.

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

Всё вышеизложенное обусловливает актуальность разработки автоматизированной информационной системы для ООО “СТК Дело”.

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

Предметом исследования являются средства разработки и теоретические основы создания автоматизированных информационных систем.

Цель работы состоитв разработке автоматизированной информационной системы для строительного предприятия ООО “СТК Дело”. Автоматизированная информационная система является средством для автоматизации учёта хранения строительных материалов.

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

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

- обеспечить обновление и добавление стройматериалов на складе;

- обеспечить отгрузку стройматериалов со склада;

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

- минимизировать финансовые затраты на документооборот.

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

Курсовая работа состоит из следующих частей:

- введение, в котором показаны задачи, решаемые в курсовой работе;

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

- описание предметной области;

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

- заключение;

- приложение.

1. Автоматизация процессов управления

Автоматизация является основным резервом повышения эффективности управления. Это утверждение справедливо по двум причинам:

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

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

Автоматизация управления предприятием нацелена на решение следующих основных задач:

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

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

- поддержка принятия решений на всех уровнях управления на основе совершенствования процессов сбора и обработки различных видов информации;

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

Автоматизированная система управления или АСУ — комплекс аппаратных и программных средств, предназначенный для управления различными процессами в рамках технологического процесса, производства, предприятия. АСУ применяются в различных отраслях промышленности, энергетике, транспорте и т.п. Термин автоматизированная, в отличие от термина автоматическая подчёркивает сохранение за человеком-оператором некоторых функций, либо наиболее общего, целеполагающего характера, либо не поддающихся автоматизации. АСУ с Системой поддержки принятия решений (СППР), являются основным инструментом повышения обоснованности управленческих решений.

Создателем первых АСУ в СССР является доктор экономических наук, профессор, член-корреспондент Национальной академии наук Белоруссии, основоположник научной школы стратегического планирования Николай Иванович Ведута (1913—1998). В 1962—1967гг. в должности директора Центрального научно-исследовательского института технического управления (ЦНИИТУ), являясь также членом коллегии Министерства приборостроения СССР, он руководил внедрением первых в стране автоматизированных систем управления производством на машиностроительных предприятиях. Активно боролся против идеологических PR-акций по внедрению дорогостоящих ЭВМ, вместо создания настоящих АСУ для повышения эффективности управления производством.

Важнейшая задача АСУ - повышение эффективности управления объектом на основе роста производительности труда и совершенствования методов планирования процесса управления. Различают АСУ объекты (технологическими процессами- АСУТП, предприятием-АСУП, отраслью- ОАСУ) и функциональные автоматизированные системы, например, проектирование плановых расчётов, материально-технического снабжения и т.д.

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

- Предоставление лицу, принимающему решение (ЛПР) релевантных данных для принятия решений

- Ускорение выполнения отдельных операций по сбору и обработке данных

- Снижение количества решений, которые должно принимать ЛПР

- Повышение уровня контроля и исполнительской дисциплины

- Повышение оперативности управления

- Снижение затрат ЛПР на выполнение вспомогательных процессов

- Повышение степени обоснованности принимаемых решений

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

1.2. Автоматизированное рабочее место пользователя

Автоматизированное рабочее место (АРМ)— программно-технический комплекс, предназначенный для автоматизации деятельности определенного вида. При разработке АРМ для управления технологическим оборудованием, как правило, используют SCADA-системы.

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

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

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

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

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

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

Описание АИС по реализации складских операций Oracle RAC

Наиболее распространенная база данных, установленная на одном физическом сервере, называется single-instance. Я раньше не предавал особого значения разнице понятий между: экземпляр (instance) базы данных и самой базы данных (в целом). Теперь же хочу особенно отметить, что под экземпляром подразумевается ПО (процессы, потоки, сервисы) которое располагается в оперативной памяти и обрабатывает данные (сортировка, буферизация, обслуживание) полученные непосредственно с диска. Таким образом, под базой данных подразумевается совокупность:

- область хранения данных, т.е. физические файлы на диске (datastorage) (сама БД)

- экземпляр БД (получающая и обрабатывающая эти данные в оперативной памяти) (СУБД)

Во всех современных реляционных БД данные хранятся в таблицах. Таблицы, индексы и другие объекты в Oracle хранятся в логических контейнерах – табличных пространствах (tablespace). Физически же tablespace располагаются в одном или нескольких файлах на диске. Хранятся они следующим образом: Каждый объект БД (таблицы, индексы, сегменты отката и.т.п.) хранится в отдельном сегменте – области диска, которая может занимать пространство в одном или нескольких файлах. Сегменты в свою очередь, состоят из одного или нескольких экстентов. Экстент – это непрерывный фрагмента пространства в файле. Экстенты состоят из блоков. Блок – наименьшая единица выделения пространства в Oracle, по умолчанию равная 8K. В блоках хранятся строки данных, индексов или промежуточные результаты блокировок. Именно блоками сервер Oracle обычно выполняет чтение и запись на диск. Блоки имеют адрес, так называемый DBA (Database Block Address).

При любом обращении DML (Data Manipulation Language) к базе данных, Oracle подгружает соответствующие блоки с диска в оперативную память, а именно в буферный кэш. Хотя возможно, что они уже там присутствуют, и тогда к диску обращаться не нужно. Если запрос изменял данные (update, insert, delete), то изменения блоков происходят непосредственно в буферном кэше, и они помечаются как dirty (грязные). Но блоки не сразу сбрасываются на диск. Ведь диск – самое узкое место любой базы данных, поэтому Oracle старается как можно меньше к нему обращаться. Грязные блоки будут сброшены на диск автоматически фоновым процессом DBWn при прохождении контрольной точки (checkpoint) или при переключении журнала.

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

- Что будет, если Oracle упадет где-то на середине длинной транзакции (если бы она вносила изменения)?

- Какие же данные прочтет первая транзакция, когда в кэше у нее «под носом» другая транзакция изменила блок?

Для ответа на эти вопросы рассмотрим механизм обеспечения согласованного чтения CR (consistency read). Все дело в “волшебных” “ пузырьках” журналах транзакций, которые в Oracle представлены двумя типами:

- журнал повтора (redo log)

- сегмент отмены (undo)

Когда в базу данных поступает запрос на изменение, то Oracle применяет его в буферном кэше, параллельно внося информацию, достаточную для повторения этого действия, в буфер повторного изменения (redo log buffer), находящийся в оперативной памяти. Как только транзакция завершается, происходит ее подтверждение (commit), и сервер сбрасывает содержимое redo buffer log на диск в redo log в режиме append-write и фиксирует транзакцию. Такой подход гораздо менее затратен, чем запись на диск непосредственно измененного блока. При сбое сервера кэш и все изменения в нем потеряются, но файлы redo log останутся. При включении Oracle начнет с того, что заглянет в них и повторно выполнит изменения таблиц (транзакции), которые не были отражены в datafiles. Это называется «накатить» изменения из redo, roll-forward. Online redo log сбрасывается на диск (LGWR) при подтверждении транзакции, при прохождении checkpoint или каждые 3 секунды (default).С undo немного посложнее. С каждой таблицей в соседнем сегменте хранится ассоциированный с ней сегмент отмены. При запросе DML вместе с блоками таблицы обязательно подгружаются данные из сегмента отката и хранятся также в буферном кэше. Когда данные в таблице изменяются в кэше, в кэше так же происходит изменение данных undo, туда вносятся «противодействия». То есть, если в таблицу был внесен insert, то в сегмент отката вносится delete, delete – insert, update – вносится предыдущее значение строки. Блоки (и соответствующие данные undo) помечаются как грязные и переходят в redo log buffer. Да-да, в redo журнал записываются не только инструкции, какие изменения стоит внести (redo), но и какие у них противодействия (undo). Так как LGWR сбрасывает redo log buffer каждые 3 секунды, то при неудачном выполнении длительной транзакции (на пару минут), когда после минуты сервер упал, в redo будут записи не завершенные commit. Oracle, как проснется, накатит их (roll-forward), и по восстановленным (из redo log) в памяти сегментам отката данных отменит (roll-back) все незафиксированные транзакции. Справедливость восстановлена. Кратко стоит упомянуть еще одно неоспоримое преимущество undo сегмента. По второму сценарию (из схемы) когда select дойдет до чтения блока (DBA) 500, он вдруг обнаружит что этот блок в кэше уже был изменен (пометка грязный), и поэтому обратится к сегменту отката, для того чтобы получить соответствующее предыдущее состояние блока. Если такого предыдущего состояния (flashback) в кэше не присутствовало, он прочитает его с диска, и продолжит выполнение select. Таким образом, даже при длительном «select count(money) from bookkeeping» дебет с кредитом сойдется. Согласованно по чтению (CR).

Уровень доступа к данным. ASM

Хранилищем (datastorage) в больших БД почти всегда выступает SAN (Storage Area Network), который предоставляет прозрачный интерфейс серверам к дисковым массивам. Сторонние производители (Hitachi, HP, Sun, Veritas) предлагают комплексные решения по организации таких SAN на базе ряда протоколов (самым распространенным является Fibre Channel), с дополнительными функциональными возможностями: зеркалирование, распределение нагрузки, подключение дисков на лету, распределение пространства между разделами и.т.п. Позиция корпорации Oracle в вопросе построения базы данных любого масштаба сводится к тому, что Вам нужно только соответствующее ПО от Oracle (с соответствующими лицензиями), а выбранное оборудование – по возможности (если средства останутся после покупки Oracle:). Таким образом, для построения высоконагруженной БД можно обойтись без дорогостоящих SPARC серверов и фаршированных SAN, используя сервера на бесплатном Linux и дешевые RAID-массивы.
На уровне доступа к данным и дискам Oracle предлагает свое решение – ASM (Automatic Storage Management). Это отдельно устанавливаемый на каждый узел кластера мини-экземпляр Oracle (INSTANCE_TYPE = ASM), предоставляющий сервисы работы с дисками. Oracle старается избегать обращений к диску, т.к. это является, пожалуй, основным bottleneck любой БД. Oracle выполняет функции кэширования данных, но ведь и файловые системы так же буферизуют запись на диск. А зачем дважды буферизировать данные? Причем, если Oracle подтвердил транзакцию и получил уведомления том, что изменения в файлы внесены, желательно, чтобы они уже находились там, а не в кэше, на случай «падения» БД. Поэтому рекомендуется использовать RAW devices (диски без файловой системы), что делает ASM. ASM работает поверх RAW device, его преимуществами являются:

- отсутствие необходимости в отдельном ПО для управления разделами дисков

- нет необходимости в файловой системе

Disk group — объединение нескольких дисков. При записи файлов на диски данные записываются экстентами размерами по 1 МБ, распределяя их по всем дискам в группе. Это делается для того, чтобы обеспечить высокую доступность, ведь части одной таблицы (из tablespace) разбросаны по разным физическим дискам. Способности ASM:

- Зеркалирование данных: как правило, 2-х или 3-х ступенчатое, т.е. данные одновременно записываются на 2 или 3 диска. Для зеркалирования диску указываются не более 8 дисков-партнеров, на которые будут распределяться копии данных.

- Автоматическая балансировка нагрузки на диски (обеспечение высокой доступности): если данные tablespace разместить на 10 дисках и, в некоторый момент времени, чтение данных из определенных дисков будет «зашкаливать», ASM сам обратится к таким же экстентам, но находящимся на зеркалированных дисках.

- Автоматическая ребалансировка: При удалении диска, ASM на лету продублирует экстенты, которые он содержал, на другие оставшиеся в группе диски. При добавлении в группу диска, переместит экстенты в группе так, что на каждом диске окажется приблизительно равное число экстентов.

Описание АИС по реализации складских операций в ИСУ " Галактика"

Информационная система управления

Комплексная система автоматизации управления предприятием " Галактика" реализована в архитектуре клиент-сервер для интегрированной поддержки управленческого цикла в компаниях различных отраслей и масштабов деятельности, была выпущена на рынок в 1995 г. Первая версия системы " Галактика" вышла на платформе BTrieve, в 1997 г (15 модулей) завершены работы по созданию версий для Microsoft SQL Server и Oracle. В 1998 г. корпорация приступила к выпуску отраслевых решений на основе системы " Галактика": для предприятий связи и телекоммуникаций, металлургии, нефтегазового и лесопромышленного комплексов, торговли, пищевой промышленности, химической индустрии.

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

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

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

Функциональные контуры системы " Галактика"

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

- управления финансами - обеспечивает решение задач финансового менеджмента, предоставляет набор средств для управления бюджетом, ведения платежного календаря и финансового анализа.

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

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

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

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

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

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

- Корпорация " Галактика", создавая свои решения, придерживается следующих базовых принципов.

Принципы корпорации " Галактика"

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

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

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

- открытость. Сегодня трудно найти предприятие, где в той или иной степени не использовались бы средства автоматизации. Естественно, возникает проблема одновременной эксплуатации продуктов разных поставщиков. В системе " Галактика" открытость обеспечивается средствами утилит администрирования (инструментальный комплекс Support); для обмена данными с банками через систему электронных платежей разработан специальный модуль " Клиент-Банк"; модуль " Обмен бизнес - документами" (Экспорт/Импорт) предоставляет универсальную систему настроек для обмена хозяйственными документами с внешними системами.

- многоплатформенность. Для территориально-распределенных корпораций и предприятий со сложной структурой управления важна интероперабельность системы. Система " Галактика" поддерживает наиболее распространенные серверные платформы (см. таблицу) и СУБД: Pervasive.SQL (BTrieve), Microsoft SQL Server, Oracle. При этом клиентская часть может функционировать в различных операционных средах: Windows 95/98/NT и т.д.

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

Масштабируемость. Под ней принято понимать возможность использования программного продукта в вычислительных сетях различного размера: в масштабе отдельного подразделения, предприятия, корпорации. Применительно к системе " Галактика" масштабируемость достигается благодаря двум факторам. Во-первых, это широкий выбор СУБД: Pervasive.SQL (BTrieve), Microsoft SQL Server, Oracle, а в перспективе Sybase, Informix, DB2. Во-вторых, возможность выбора аппаратной платформы и сетевой операционной системы сервера (они перечислены в таблице).

Описание АИС по реализации складских операций в 1С: Предприятие

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

Области применения.

Гибкость платформы позволяет применять 1С: Предприятие 8 в самых разнообразных областях:

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

- поддержка оперативного управления предприятием;

- автоматизация организационной и хозяйственной деятельности;

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

- широкие возможности для управленческого учета и построения аналитической отчетности, поддержка многовалютного учета;

- решение задач планирования, бюджетирования и финансового анализа;

- расчет зарплаты и управление персоналом;

- другие области применения.

Прикладные решения.

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

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

Внедрение.

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

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

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

3. Разработка программного продукта

3.1. Выбор среды разработки

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

Microsoft Office Access или просто Microsoft Access — реляционная СУБД корпорации Microsoft. Имеет широкий спектр функций, включая связанные запросы, связь с внешними таблицами и базами данных. Благодаря встроенному языку VBA, в самом Access можно писать приложения, работающие с базами данных.

Основные компоненты MS Access:

- построитель таблиц;

- построитель экранных форм;

- построитель SQL-запросов (язык SQL в MS Access не соответствует стандарту ANSI);

- построитель отчётов, выводимых на печать.

Они могут вызывать скрипты на языке VBA, поэтому MS Access позволяет разрабатывать приложения и БД практически «с нуля» или написать оболочку для внешней БД.

MS Access является файл-серверной СУБД и потому применима лишь к маленьким приложениям. Отсутствует ряд механизмов, необходимых в многопользовательских БД, таких, например, как триггеры.

Существенно расширяет возможности MS Access по написанию приложений механизм связи с различными внешними СУБД: " связанные таблицы" (связь с таблицей СУБД) и " запросы к серверу" (запрос на диалекте SQL, который " понимает" СУБД). Также MS Access позволяет строить полноценные клиент-серверные приложения на СУБД MS SQL Server. При этом имеется возможность совместить с присущей MS Access простотой инструменты для управления БД и средства разработки.

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

Это приращение размера файла является, фактически, пустотой, но эта пустота лежит внутри файла, увеличивая его объём.

Чтоб вернуть файлу базы данных нормальный (минимальный) объём (то есть, чтоб убрать из файла пустоту), в Access есть кнопка «Сжать и восстановить базу данных» — эту кнопку нужно время от времени нажимать (при нажатии этой кнопки никакая информация, никакие данные из файла базы данных не удаляются).

Основные этапы проектирования в MS Access.

Концептуальное (инфологическое) проектирование

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

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

Чаще всего концептуальная модель базы данных включает в себя:

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

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

Логическое (даталогическое) проектирование

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

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

На этапе логического проектирования учитывается специфика конкретной модели данных, но может не учитываться специфика конкретной СУБД.

Физическое проектирование

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

3.2. Информационная модель данных.

Рисунок 1 Таблица “Поставщики”.

Рисунок 2 Таблица “Накладная”.

Рисунок 3 Таблица “Реализация товара”.

Рисунок 4 Таблица “Склад”.

Рисунок 5 Таблица “Товар”.

Рисунок 6 Таблица “Характеристики товара”.

3.3. Логическая модель данных.

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

Рисунок 7.Логическая модель

3.4. Алгоритм решения задач

Автоматизированная информационная система ООО “СТК Дело” позволяет решить следующие задачи:

Рисунок 8. Запрос на добавление данных из таблицы “Накладная” в таблицу “Склад”.

Рисунок 9. Запрос на обновление Таблицы “Склад”. Складывает количество одинакового материала.

Рисунок 10. Запрос на отгрузку материала из Таблицы “Склад”, который отправили на объект.

Рисунок 11. Запрос на просмотр информации о товаре по критериям из Таблицы “Склад”.

Рисунок 12. Запрос на просмотр “Накладной”.

Рисунок 13. Запрос на просмотр поставщиков.

3.5. Входные данные

Рисунок 14. Таблица “Поставщики”

В этой таблице содержатся фирмы производящие строительные материалы.

Рисунок 15. Таблица “Товар”

В этой таблице информация о товарах поставщика, которая имеется в наличии у поставщика.

Рисунок 16. Таблица “Накладная”

В этой таблице поставщик заполняет товары, которые заказывает фирма.

Рисунок 17. Таблица “Склад”

В этой таблице информация о товаре, имеющемся на складе предприятия ООО “СТК Дело”.

Рисунок 18. Таблица “Реализация товара”

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

Работа с данными реализуется с помощью “Запросов”, которые манипулируют данными: добавляя, удаляя, обновляя их.

3.6. Выходные данные

Выходные данные реализуются с помощью “Отчётов”

В данном “Отчёте” информация о “Товаре”.

Рисунок 19 Отчёт “Товар на складе”

Рисунок 20 Отчёт “Просмотр поставщиков”.

Рисунок 21 Отчёт “Накладная” просмотр накладной по её номеру.

Рисунок 22 Отчёт “Расходная накладная ” просмотр расходной накладной по её номеру.

3.7. Интерфейс

Интерфейс реализуется с помощью “Форм”.

Управление программным продуктом реализуется с помощью “Главная форма” содержащая вкладки по которым можно переходить для определенных действий.

Рисунок 23 Вкладка на главной форме “Поступление товара”.

Рисунок 24 Вкладка на главной форме “Отгрузка товара”.

Рисунок 25 Вкладка “Просмотр отчётов”.

Рисунок 26 Форма “Товар” просмотр и редактирование товара, который есть в наличии у поставщиков.

Рисунок 27 Форма “Склад” просмотр товара на складе.

Рисунок 28 Форма “Поставщики” просмотр и редактирование поставщиков.

Рисунок 29 Форма “Приходная накладная” заполняет приходную накладную.

Рисунок 30 Форма “Расходная накладная” заполняет расходную накладную для отгрузки товара на объект.

3.8. Программная документация

3.8.1.Руководство программиста

Для работы программы необходимо иметь ПК, работающий под управлением операционной системы Windows 98/2000/XP/Vista/7, с установленным на нём программным пакетом MS Office в который входит компонент MS Access. Программа проста в обращении, с ней может работать не только специалист в области программирования, но и простой пользователь.

Технические средства:

- ПК на базе процессора Intel или AMD;

- CD дисковод;

- 1 Gb на HDD;

- цветной монитор SVGA;

- клавиатура;

- манипулятор типа “мышь”.

Автоматизированная система предназначена для автоматизации учёта складских операций и выполняет следующие функции:

- обеспечивает учёт материалов приходящих на склад;

- Обеспечивает отгрузку товара на объект

Для того чтобы открыть программу необходимо на рабочем столе пользователя открыть иконку с наименованием “Склад”.

3.8.2 Руководство пользователя

Для того, чтобы открыть программу надо:

- на рабочем столе найти иконку с наименованием “Склад”

При входе в программу откроется главное меню автоматизированной системы ООО “СТК Дело”. АИС предназначена для работы кладовщика, который получает строительные материалы и отгружает их на различные объекты.

Инструкция пользователя.

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

Кнопка “Приходная накладная” откроет форму заполнение накладной для учёта товара.

Кнопка “Обновление склада” обновит материал который уже есть на складе.

Кнопка “Добавить в склад” добавит материал которого нет в наличии.

Примечание: следует выполнять операции по порядку сначала выполнить операцию “обновить склад”, затем выполнить операцию “добавить в склад”. Если случайно была выполнена какая- либо операция не по порядку следует вручную отредактировать количество товара на складе, с помощью кнопки “Редактировать склад”.

Перейдя по вкладке “Отгрузка товара” Будут расположены кнопки управляющие отгрузкой товара.

Кнопка “Расходная накладная” откроет форму заполнения товара на отгрузку, который необходимо отправить на объект.

Кнопка “Реализация товара” вычитает количество товара со склада, которое отправили на объект.

Примечание: если случайно будет нажата кнопка “Реализация товара” следует в ручном режиме отредактировать склад, чтобы это сделать нужно нажать кнопку “Редактировать склад” на этой же вкладке.

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

Заключение

В рамках курсовой работы был разработан программный продукт прикладного назначения «Склад стройматериалов» при использовании СУБД Microsoft Office Access.

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

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

- уменьшение времени необходимого для учета поставок на предприятие;

- автоматизация контроля поставок;

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

- своевременное получение информации о поставках товара

Список используемой литературы

Интернет ресурс - https://ru.wikipedia.org

Интернет ресурс- https://v8.1c.ru/

1. Куправа Т. А. Самоучитель ACCESS 2013 / Т. А. Куправа. - СПб.: Наука и техника, 2014. - 144 с.

2. Карпова Т. С. Базы данных: модели, разработка, реализация: учеб. пособие / Т. С. Карпова. - СПб.: Питер, 2012. - 304 с.

3. Кетов А. В. Информационные системы: учеб. пособие / А. В. Кетов. - Хабаровск: Изд во Хабар. гос. техн. ун та, 2013. - 59 с.

4. Коннолли Т. Базы данных: проектирование, реализация и сопровождение. Теория и практика: пер. с англ. / Т. Коннолли, К. Бегг, А. Страчан. - М.: Издательский дом " Вильямс", 2014. - 1120 с.

5. Малыхина М. П. Базы данных: основы, проектирование, использование: учеб. пособие / М. П. Малыхина. - СПб.: БХВ Петербург, 2014. - 512 с.

6. Голицына О. Л. Базы данных: учеб. пособие / О. Л. Голицына, Н. В. Максимов, И. И. Попов. - М.: ФОРУМ: ИНФРА М, 2011.- 352 с.

7. Диго С. М. Проектирование и использование баз данных: учебник для студентов вузов / С. М. Диго. - М.: Финансы и статистика, 2012. - 208 с.

8. Ревунков Г. И. Базы и банки данных и знаний: учебник для вузов / Г. И. Ревунков, Э. И. Самохвалов, В. В. Чистов; под ред. В. Н. Четверикова - М.: Высш. шк., 2013. - 367 с.

9. Полищук Ю. М. Теория автоматизированных банков информации: учеб. пособие для вузов / Ю. М. Полищук, Б. В. Хон. - М.: Высш. шк., 2014. - 184 с.

10. Куправа Т. А. Создание и программирование баз данных средствами СУБД dBase III Plus, FoxBase Plus, Clipper / Т. А. Куправа. - М.: Мир, 2011.- 110 с.

11. Экономическая информатика / под ред. П. В. Конюховского и Д. Н. Колесова. - СПб.: Питер, 2012. - 560 с.

12. Экономическая информатика: учебник для вузов / под ред. В. В. Евдокимова. - СПб.: Питер, 2012. - 592 с.

13. Информатика. Базовый курс: учеб. пособие / С. В. Симонович и др. - СПб.: Питер, 2013. - 640 с.

14. Информатика для юристов и экономистов / С. В. Симонович и др. - СПб.: Питер, 2014. - 688 с.

15. Информатика: учебник / под ред. проф. Макаровой. - М.: Финансы и статистика, 2012. - 768 с.