Доклад: База даних підприємства

--PAGE_BREAK--1.2 Основні завдання предметної області


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

У зв'язку із цим виникає необхідність удосконалювання керування різними сторонами діяльності підприємств регіону, у т. ч. удосконалювання оперативного керування виробничо-господарською й фінансовою діяльністю підприємств на основі нових інформаційних технологій, що сприяють прискореному регулюванню процесів, що відбуваються, запобіганню виникаючих негативних ситуацій. Всі це, насамперед, пов'язане з необхідністю системного й комплексного рішення як організаційно-управлінських, так і фінансово-економічних проблем галузі. Особливу актуальність здобуває критична оцінка факторів, що впливають на сферу керування виробничими й фінансовими потоками, аналіз зовнішнього середовища, діяльність конкурентів, що функціонують у єдиному економічному просторі цього регіону. Не менш важливим бачаться питання ефективного використання інформаційної сфери для виявлення переваг підприємств однієї галузі, недоліків, їхнього функціонування, визначення своїх переваг перед конкурентами, передбачення структурних змін на ринку, оцінка гнучкості цінової політики, якості продукції, стабільності попиту на неї, збуту, конкурентоздатності виробленої продукції.

2. Постановка завдання2.1 Організаційно-економічна сутність комплексу завдань


У даній роботі буде підняте питання автоматизації оперативного керування ведення однієї з галузей сільського хазяйства. Конкретно автоматизації технологічної лінії вирощування гриба «вешенки». Починаючи від заготівлі субстракта й до його повного циклу плодоношення. Програма буде вести кілька таблиць, зв'язаних в одну базу даних. Це комплекс, на базі якого можна аналізувати, планувати й приймати рішення. Стежити за економічними показниками, ростом і скороченням обсягів збуту, нарощуванні можностей, і збільшення рентабельності підприємства, шляхом зміни якісного складу субстракта та різних партій міцелію, від різних постачальників.

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

Програма винна мати в собі вусі вище перераховане й виконувати ряд інших завдань:

1)                Ведення бази паспортів партії

2)                Ведення бази по персоналі

3)                Бази постачальників міцелію

4)                Бази міцелію

5)                Базу збору продукції операторами

6)                Базу технологічної інформації з усіх цехів

7)                Базу реалізованих обсяги продукції

Винна мати гнучку систему аналізу й планування виробництва:

1)                Графік місячних зборів

2)                Річні збори

3)                Графік аналізу рентабельності підприємства за будь-який період

4)                Графіки прогнозовані обсяги при різних значеннях рентабельности підприємства.

Програма винна буде виконана мовою високого рівня Delphi 6 з використанням БД Interbase за допомогою інструмента IB Expert. Також програма винна взаємодіють на програмному рівні з устаткуванням цехів, шляхом роботи через зовнішні пристрої, а значити використати споконвічно загальноприйнятий протокол передачі даних.


    продолжение
--PAGE_BREAK--2.2 Опис вхідної інформації


У даній програмі необхідно точно організувати правильне й лаконічне використання вхідних даних, тому що смороду будуть у більшості прямо впливати на організацію полів у базі даних. Дані необхідно строго впорядкувати й розділити на дві категорії: обробних й оброблюваних.

Типи даних повинні бути наведені до стандарту використовуваному в мові високого рівня Object Pascal (Delphi). Бази даних повинні бути організовані з використанням реаляційного підходу, на базі стандарту мови запитів SQL.

Конкретний список вхідних даних для успішної роботи програми наведень у таблиці 2.2.1 Із вказівкою їхніх назв, типів і діапазонів прийнятих значень.

Саме вхідні дані формують структуру майбутніх полів бази даних.

база інформаційна система автоматизація


Таблиця вхідних даних 2.2.1


    продолжение
--PAGE_BREAK--2.3 Опис вихідної інформації


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



3. Проектування інформаційної системи3.1 Аналіз вхідної інформації предметної області


Поняття тип даних у реляційної моделі даних повністю адекватно поняттю типу даних у мовах програмування. Звичайно в сучасних реляційних БД допускається зберігання символьних, числових даних, бітових рядків, спеціалізованих числових даних (таких як «гроші»), а також спеціальних «темпоральних» даних (дата, година, часовий інтервал). Досить активно розвивається підхід до розширення можливостей реляційних систем абстрактними типами даних (відповідними можливостями володіють, наприклад, системи сімейства Ingres/Postgres). У нашому прикладі мі маємо справу з даними трьох типів: рядка символів, цілі числа й «гроші».

Схема відносини — це іменована безліч пари {ім'я атрибута, ім'я домена (або типу, якщо поняття домена не підтримується) }. Ступінь або «арность» схеми відносини — потужність цієї безлічі. Ступінь відносини СПІВРОБІТНИКИ дорівнює чотирьом, тобто воно є 4-арным. Якщо всі атрибути одного відношення визначені на різних доменах, осмислено використати для іменування атрибутів імена відповідних доменов (не забуваючи, звичайно, про ті, що це є всього лише зручним способом іменування й не усуває розходження між поняттями домена й атрибута).

Відношення — це безліч кортежів, що відповідають одній схемі відносини. Іноді, щоб не плутатися, говорять «відношення-схема» й «відношення-екземпляр», іноді схему відносини називають заголовком відносини, а відношення як набір кортежів — тілом відносини. Насправді, поняття схеми відносини ближче всього до поняття структурного типу даних у мовах програмування. Було б цілком логічно дозволяти окремо визначати схему відносини, а потім одне або кілька відносин з даною схемою.

Однак у реляційных базах даних це не прийнято. Ім'я схеми відносини в таких базах даних завжди збігається з ім'ям відповідного відношення-екземпляра. У класичних реляційних базах даних після визначення схеми бази даних змінюються тільки відношення-екземпляри. У них можуть з'являтися нові й віддалятися або модифікуватися існуючі кортежі. Однак у багатьох реалізаціях допускається й зміна схеми бази даних: визначення нових і зміна існуючих схем відносини. Це прийнято називати еволюцією схеми бази даних.

Звичайним життєвим поданням відносини є таблиця, заголовком якої є схема відносини, а рядками — кортежі відношення-екземпляра; у цьому випадку імена атрибутів іменують стовпці цієї таблиці. Тому іноді говорять «стовпець таблиці», маючи на увазі «атрибут відносини». Коли мі перейдемо до розгляду практичних питань організації реляційних баз даних і засобів керування, мі будемо використати цю життєву термінологію. Цієї термінології дотримуються в більшості комерційних реляційних СУБД.


    продолжение
--PAGE_BREAK--