Проектирование БД для учета животных АПК

КУРСОВАЯ РАБОТА

на тему:

«Проектирование БД для учета животных АПК»

                                                               Выполнил (а):

                                                               Проверил:

Рязань 2012

Содержание

Введение.

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

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

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

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

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

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

1. Описать предметную область;
2. Построить логическую и физическую модель БД;
3. Построить схему данных.

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

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

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

В данной работе в качестве СУБД была выбрана система управления реляционной базой данных Microsoft Access 2007, включающей все необходимые инструментальные средства для создания локальной базы данных. В ее файле могут храниться не только данные, но и объекты интерфейса: отчеты, формы.

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

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

Животные на выращивании и откорме – особый вид оборотных активов. С одной стороны это материальные ценности, которые поступали с производства как готовая продукция или купленная на стороне, а с другой это особый вид запасов – живые организмы которые находятся все время в незавершенном производстве. То есть это беспрерывный производственный процесс, в котором готовая продукция постепенно изменяет свой объем и стоимость. Поэтому необходим постоянный контроль за объемом, а тем более стоимостью животных в производстве.

Это можно рассматривать как независимое производство отрасли животноводства. Также их можно отнести к материальным оборотным активам: молодняк может быть переведен в основное стадо, реализован и т.д.

Такими средствами не обладает ни один вид производственных запасов. Исходя из этой особенности учет животных на выращивании и откорме (УЖВО) ведут обособленно от производственных запасов.

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

Задачи УЖВО:

1)Своевременное и правильное  документальное оформление поступления  и выбытия ЖВО.

2)Обеспечение контроля за сохранностью  скота

3)Своевременное отражение всех  изменений, происходящих в составе  стада

4)Правильное отражение записей  в регистрах БУ

5)Обеспечение контроля за сохранностью полученной продукции животноводства

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

 При учёте животных ,полученный в хозяйстве приплод оценивают следующим образом: телят в молочном скотоводстве - по плановой себестоимости головы приплода, которая определяется исходя из 10 % затрат на содержание скота основного стада; поросят - исходя из живой массы при рождении и плановой себестоимости 1 кг живой массы отъемышей; Себестоимость ягнят на момент рождения определяют в шерстно-мясном и мясо-шерстном овцеводстве в размере 10 %, романовском - 12 %, каракульском - 15 % общей суммы затрат на содержание овец основного стада;

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

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

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

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

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

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

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

Все случаи перевода животных и птицы из одной учетной группы в другую, в основное стадо, из одной фермы на другую оформляется актами, а перевод животных, которые составляются заведующим фермой совместно с зоотехником в день перевода в одном экземпляре. В акте указывается: 
1 – количество голов 
2 – масса животных 
3 – возраст, оценка, ФИО животноводов, за которыми были закреплены животные, и технические работники, под ответственность которых они передаются.

Основным видом животноводческой продукции является прирост животной массы, получаемый в ходе откорма и выращивания животных. Для определения прироста и плодотворности выращивания животных необходимо производить их систематическое взвешивание, которое производится в следующих случаях: 
1 – при рождении 
2 – при переводе в следующую возрастную группу или в основное стадо 
3 – при забое 
4 – при постановке выбракованных животных на откорм 
5 – при снятии с откорма 
По овцам, козам и некоторым другим видам мелких животных живая масса всего поголовья на конец отчетного периода определяется умножением массы одной головы на общее количество голов, числящихся в данной возрастной группе. 
Результаты взвешивания заносят в накопительную ведомость взвешивания животных. В ней указывается вид животных, их инвентаризационный номер, количество голов, масса животных на дату взвешивания, прирост животной массы. 
Таким образом, в ведомости исчисляется прирост животной массы только тех животных, которые находились в группе на день взвешивания.

2. Выбор средств, методологии проектирования. Выбор СУБД.

2.1 Выбор СУБД.

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

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

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

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

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

Office Access 2007 обеспечивает возможность  легко начинать работу со встроенными  базами данных, вносить в них  изменения и адаптировать к  меняющимся деловым потребностям пользователя. Пользователь может собирать информацию с помощью форм электронной почты или импортировать данные из внешних приложений. Реализована возможность создания и редактирования подробных отчетов, содержащих отсортированную, отфильтрованную и сгруппированную информацию, которая облегчит принятие более обоснованных решений. Совместный доступ к информации обеспечивается с помощью технологических списков Microsoft Windows SharePoint Services, позволяющих проверять журнал исправлений, восстанавливать удаленную информацию, устанавливать разрешения доступа к данным и регулярно осуществлять резервное копирование.

2.2. Моделирование бизнес – процесса ( модели IDEF0 , IDEF3).

Графический язык IDEF0 удивительно прост и гармоничен. В основе методологии лежат четыре основных понятия:

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

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

Верхняя сторона имеет значение «Управление» (Control);

Левая сторона имеет значение «Вход» (Input);

Правая сторона имеет значение «Выход» (Output);

Нижняя сторона имеет значение «Механизм» (Mechanism).

Каждый функциональный блок в рамках единой рассматриваемой системы должен иметь свой уникальный идентификационный номер.

Вторым «китом» методологии IDEF0 является понятие интерфейсной дуги (Arrow). Также интерфейсные дуги часто называют потоками или стрелками. Интерфейсная дуга отображает элемент системы, который обрабатывается функциональным блоком или оказывает иное влияние на функцию, отображенную данным функциональным блоком.

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

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

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

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

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

Обязательное наличие управляющих интерфейсных дуг является одним из главных отличий стандарта IDEF0 от других методологий классов DFD (Data Flow Diagram) и WFD (Work Flow Diagram).

Третьим основным понятием стандарта IDEF0 является декомпозиция (Decomposition). Принцип декомпозиции применяется при разбиении сложного процесса на составляющие его функции. При этом уровень детализации процесса определяется непосредственно разработчиком модели.

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

Модель IDEF0 всегда начинается с представления системы как единого целого – одного функционального блока с интерфейсными дугами, простирающимися за пределы рассматриваемой области. Такая диаграмма с одним функциональным блоком называется контекстной диаграммой, и обозначается идентификатором «А 0».

В пояснительном тексте к контекстной диаграмме должна быть указана цель (Purpose) построения диаграммы в виде краткого описания и зафиксирована точка зрения (Viewpoint).

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

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

В процессе декомпозиции, функциональный блок, который в контекстной диаграмме отображает систему как единое целое, подвергается детализации на другой диаграмме. Получившаяся диаграмма второго уровня содержит функциональные блоки, отображающие главные подфункции функционального блока контекстной диаграммы и называется дочерней (Child diagram) по отношению к нему (каждый из функциональных блоков, принадлежащих дочерней диаграмме соответственно называется дочерним блоком – Child Box). В свою очередь, функциональный блок – предок называется родительским блоком по отношению к дочерней диаграмме (Parent Box), а диаграмма, к которой он принадлежит – родительской диаграммой (Parent Diagram). Каждая из подфункций дочерней диаграммы может быть далее детализирована путем аналогичной декомпозиции соответствующего ей функционального блока. Важно отметить, что в каждом случае декомпозиции функционального блока все интерфейсные дуги, входящие в данный блок, или исходящие из него фиксируются на дочерней диаграмме. Этим достигается структурная целостность IDEF0 – модели. Наглядно принцип декомпозиции представлен на рисунке 2. Следует обратить внимание на взаимосвязь нумерации функциональных блоков и диаграмм – каждый блок имеет свой уникальный порядковый номер на диаграмме (цифра в правом нижнем углу прямоугольника), а обозначение под правым углом указывает на номер дочерней для этого блока диаграммы. Отсутствие этого обозначения говорит о том, что декомпозиции для данного блока не существует.

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

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

Обычно IDEF0 модели несут в себе сложную и концентрированную информацию, и для того, чтобы ограничить их перегруженность и сделать удобочитаемыми, в соответствующем стандарте приняты соответствующие ограничения сложности:

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

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

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

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

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

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

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

содействовать принятию оптимальных решений при реорганизации технологических процессов;

разрабатывать имитационные модели технологических процессов, по принципу «КАК БУДЕТ, ЕСЛИ…».

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

2.3.Создание хранилищ данных(DFD моделей).

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

Альтернативным подходом является подход, популярный при создании программного обеспечения, называемый событийным разделением (event Partitioning), в котором различные диаграммы DFD выстраивают модель системы. Во-первых, логическая модель строится как совокупность работ и документирования того, что они (эти работы) должны делать.

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

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

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

Нумерация объектов.

В DFD номер каждой работы может включать префикс, номер родительской работы (А) и номер объекта. Номер объекта – это уникальный номер работы на диаграмме. Например, работа может иметь номер А. 12.4. Уникальный номер имеют хранилища данных и внешние сущности независимо от их расположения на диаграмме. Каждое хранилище данных имеет префикс D и уникальный номер, например D5. Каждая внешняя сущность имеет префикс Е и уникальный номер, например Е5.

Наличие в диаграммах DFD элементов для описания источников, приемников и хранилищ данных позволяет более эффективно и наглядно описать процесс документооборота. Однако для описания логики взаимодействия информационных потоков более подходит IDEF3, называемая также workflow diagramming – методологией моделирования, использующая графическое описание информационных потоков, взаимоотношений между процессами обработки информации и объектов, являющихся частью этих процессов. Диаграммы Workflow могут быть использованы в моделировании бизнес-процессов для анализа завершенности процедур обработки информации.

2.4.Создание логической и физической модели (Erwin ) 

Преимущества моделирования в ERwin

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

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