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

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

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

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

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

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

5

Содержание

  • Введение
  • 1. Автоматизация процессов управления
  • 1.2 Автоматизированное рабочее место пользователя
  • 2. Описание предметной области складские операции
  • 2.1 Описание АИС по реализации складских операций Oracle RAC
  • 2.2 Уровень доступа к данным. ASM
  • 2.3 Описание АИС по реализации складских операций в ИСУ "Галактика"
  • Информационная система управления
  • Функциональные контуры системы "Галактика"
  • Принципы корпорации "Галактика"
  • 2.4 Описание АИС по реализации складских операций в 1С: Предприятие
  • Области применения
  • Прикладные решения
  • Внедрение
  • 3. Разработка программного продукта
  • 3.1 Выбор среды разработки
  • 3.2 Основные этапы проектирования в MS Access
  • Концептуальное (инфологическое) проектирование
  • Логическое (даталогическое) проектирование
  • Физическое проектирование
  • 3.3 Информационная модель данных
  • 3.4 Логическая модель данных
  • 3.5 Алгоритм решения задач
  • 3.5 Входные данные
  • 3.6 Выходные данные
  • 3.7 Интерфейс
  • Интерфейс реализуется с помощью "Форм”
  • 3.8 Программная документация
  • Руководство программиста
  • Руководство пользователя
  • 3.9 Техника безопасности
  • Заключение
  • Список используемой литературы

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

склад база строительный материал

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

2.1 Описание АИС по реализации складских операций 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).

2.2 Уровень доступа к данным. 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 на лету продублирует экстенты, которые он содержал, на другие оставшиеся в группе диски. При добавлении в группу диска, переместит экстенты в группе так, что на каждом диске окажется приблизительно равное число экстентов.

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

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

Комплексная система автоматизации управления предприятием "Галактика" реализована в архитектуре клиент-сервер для интегрированной поддержки управленческого цикла в компаниях различных отраслей и масштабов деятельности, была выпущена на рынок в 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. Во-вторых, возможность выбора аппаратной платформы и сетевой операционной системы сервера (они перечислены в таблице).

2.4 Описание АИС по реализации складских операций в 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 есть кнопка "Сжать и восстановить базу данных" - эту кнопку нужно время от времени нажимать (при нажатии этой кнопки никакая информация, никакие данные из файла базы данных не удаляются).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- CD дисковод;

- 1 Gb на HDD;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.9 Техника безопасности

Учет эргономических аспектов взаимодействия программы с пользователем (обучаемым и /или обучающим).

- Наилучшее расположение объекта информации в зависимости от величины самых мелких его деталей колеблется в пределах от 90 до 50 см от линии глаз воспринимающего. Ось зрения с плоскостью экрана должна составлять угол 900±100.

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

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

- Горизонтальные линии на кадре подчеркивают широту и простор сюжета, а вертикальные - его высоту.

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

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

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

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

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

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

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

При начертании букв - оптимальное соотношение ширины букв к их высоте близко к 2: 3; Наиболее приемлемым соотношением с точки зрения восприятия толщины обводки к высоте букв является 1: 6 для прямой контрастности (черные буквы на белом фоне) и 1: 10 для обратной контрастности (белые буквы на черном фоне).

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

При написании слов и чисел расстояние между буквами и цифрами должно составлять 0, 2.0, 3 их ширины.

Расстояние между строчками текста подбирается в соответствии с высотой букв (в пределах от 1: 1 до 1: 1,2) и с учетом длины строк. Чем длиннее строчки, тем больше должно быть расстояние между ними. Так, машинописный текст, напечатанный через один интервал с длиной строки во весь лист, читается значительно хуже, чем тот же текст, напечатанный через два интервала. Но в то же время короткие строчки машинописи (например, стихи) читаются лучше при напечатании через один интервал.

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

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

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

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

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

Используя цвет в передаче информации на дисплее, следует учитывать:

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

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

Заключение

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

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

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

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

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

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

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

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

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 с.


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

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