База даних підприємства

Курсова робота
з дисципліни«Проектування баз даних»
На тему: База даних підприємства

Зміст
Вступ
1. Опис предметної області
1.1 Призначення інформаційної системи
1.2 Основні завдання предметної області
2. Постановка завдання
2.1 Організаційно-економічна сутність комплексу завдань
2.2 Опис вхідної інформації
2.3 Опис вихідної інформації
3. Проектування інформаційної системи
3.1 Аналіз вхідної інформації предметної області
3.2 Визначення зв'язків інформаційних об'єктів і побудоваінформаційно — логічної моделі
3.3 Визначення логічної структурибази даних
4. Об'єкти бази даних
4.2 Запити
4.3 Екранні форми введення й редагування даних
4.4 Звіти
Висновок
Список використаної літератури
Вступ
Із самого початку розвитку обчислювальної техніки утворилися дваосновних напрямки її використання. Перший напрямок — застосування обчислювальноїтехніки для виконання чисельних розрахунків, які занадто довго або взагалі неможливоробити вручну. Становлення цього напрямку сприяло інтенсифікації методів чисельногорішення складних математичних завдань, розвитку класу мов програмування, орієнтованихна зручний запис чисельних алгоритмів, становленню зворотного зв'язку з розроблювачаминових архітектур ЕОМ.
Другий напрямок, це використання засобів обчислювальної технікив автоматичній або автоматизованій інформаційній системах. У самому широкому змістіінформаційна система являє собою програмний комплекс, функції якого складаютьсяв підтримці надійного зберігання інформації в пам'яті комп'ютера, виконанні специфічнихдля даного додатка перетворень інформації й/або обчислень, наданні користувачамзручного й легко освоюваного інтерфейсу. Звичайно обсяги інформації, з якими доводитимати праворуч таким системам, досить великі, а сама інформація має досить складнуструктуру. Класичними прикладами інформаційних систем є банківські системи, системирезервування авіаційних або залізничних квитків, місць у готелях і т.д.
Насправді, другий напрямок виникло трохи пізніше першого. Це пов'язанез тім, що на зорі обчислювальної техніки комп'ютери малі обмежені можливості в частиніпам'яті. Зрозуміло, що можна говорити про надійне й довгострокове зберігання інформаціїтільки при наявності запам'ятовувальних пристроїв, що зберігають інформацію післявимикання електричного харчування. Оперативна пам'ять цією властивістю звичайноне володіє. На качану використалися два види пристроїв зовнішньої пам'яті: магнітністрічки й барабани. При цьому ємність магнітних стрічок була досить велика, аліпо своїй фізичній природі смороду забезпечували послідовний доступ до даних. Магнітніж барабани (смороду найбільше схожі на сучасні магнітні диски з фіксованими голівками)давали можливість довільного доступу до даними, алі були обмеженого розміру.
Легко бачити, що зазначені обмеження не дуже істотні для чисточисельних розрахунків. Навіть якщо програма винна обробити (або зробити) великийобсяг інформації, при програмуванні можна продумати розташування цієї інформаціїв зовнішній пам'яті, щоб програма працювала якнайшвидше.
З іншого боку, для інформаційних систем, у яких потреба в поточнихданих визначається користувачем, наявність тільки магнітних стрічок і барабанівнезадовільно. Уявіть собі покупця квитка, що коштуючи в каси винний дочекатися повногоперемотування магнітної стрічки. Одним із природних вимог до таких систем є середняшвидкість виконання операцій.
Як здається, саме вимоги до обчислювальної техніки з боку нечисельнихдодатків викликали поява знімних магнітних дисків з рухливими голівками, що з'явилосяреволюцією в історії обчислювальної техніки. Ці пристрої зовнішньої пам'яті маліістотно більшу ємність, чим магнітні барабани, забезпечували задовільну швидкістьдоступу до даних у режимі довільної вибірки, а можливість зміни дискового пакетана пристрої дозволяла мати практично необмежений архів даних.
З появою магнітних дисків почалася історія систем керування данимив зовнішній пам'яті. До цього кожна прикладна програма, який було потрібно зберігатидані в зовнішній пам'яті, сама визначали розташування кожної порції даних на магнітнійстрічці або барабані й виконувала обміни між оперативною й зовнішньою пам'яттю задопомогою програмно-апаратних засобів низького рівня (машинних команд або викликіввідповідних програм операційної системи). Такий режим роботи не дозволяє або дужеутрудняє підтримка на одному зовнішньому носії декількох архівів довгочасно збереженоїінформації. Крім того, кожній прикладній програмі доводилося вирішувати проблемиіменування частин даних і структуризації даних у зовнішній пам'яті.
1. Опис предметної області1.1 Призначення інформаційної системи
Визначаються перспективи розвитку керування процесамиведення господарства.
Досліджуються й обґрунтовуються умови розвиткусистем, що інформаційно радять, ведення господарства (ИСС ВХ). Одним з напрямківцього розвитку розглядається застосування комп'ютерів у технологічних процесах виробництвапродукту нижній рівень керування технологічними операціями, верхній рівень — ИССВХ керуючими процесами прийняття рішень на основі бази даних і бази знань у розвиткукомп'ютерних рішень, на рівні агропромислового комплексу (АПК) регіону розглянутіперспективи рішення завдань із розподіленими базами даних. Облік агроклиматическихресурсів території господарства дозволяє вирішувати ряд важливих завдань виробництвасільськогосподарського продукту.
Оскільки зовнішні впливи й у першу чергу кліматвизначають можливість і доцільність оброблення конкретних сільськогосподарськихкультур й їхня продуктивність, робиться спроба прогнозувати втрати врожаю. Із цієюметою формулюються моделі й оцінки агрометеорологічних розумів, включаючи характеристикистану ґрунтів, посівів і врожайності культур. При цьому одночасно проводяться спостереженняза метеорологічними величинами, що впливають на сільськогосподарський об'єкт.1.2 Основні завдання предметної області
В історичному плані проблемі розробки систем веденнясільського господарства агроэкономическая наука незмінно приділяла велику увагу.Сотні років, у своїй повсякденності, сільське господарство й, зокрема, землеробствобазувалося на сугубо практичній основі, на нагромадженні й передачі виробничогодосвіду від одного покоління до іншого. Факти накопичувалися, ретельно описувалисяй рекомендувалися для практичного застосування новим поколінням хліборобів. Кожнийз їх міг брати ті, що хотів, покладаючись при цьому лише на свою інтуїцію. Фактичнодо XIX сторіччя системи ведення сільського господарства формувалися емпірично, відбиваючизміни в рівні розвитку продуктивних сил і зміни суспільних формацій. Та й в основуназви цих систем землеробства бралися різні обставини (перелігвища, перелігвища,подсечно-огневая, выгонная, парова, сидеральна, плодозмінна). Треба відзначити,що найбільш часто найменування системи землеробства зв'язувалося з «провідної»фактором, що визначав або винний був визначати ефективність системи землеробства.
У зв'язку із цим виникає необхідність удосконалюваннякерування різними сторонами діяльності підприємств регіону, у т. ч. удосконалюванняоперативного керування виробничо-господарською й фінансовою діяльністю підприємствна основі нових інформаційних технологій, що сприяють прискореному регулюванню процесів,що відбуваються, запобіганню виникаючих негативних ситуацій. Всі це, насамперед,пов'язане з необхідністю системного й комплексного рішення як організаційно-управлінських,так і фінансово-економічних проблем галузі. Особливу актуальність здобуває критичнаоцінка факторів, що впливають на сферу керування виробничими й фінансовими потоками,аналіз зовнішнього середовища, діяльність конкурентів, що функціонують у єдиномуекономічному просторі цього регіону. Не менш важливим бачаться питання ефективноговикористання інформаційної сфери для виявлення переваг підприємств однієї галузі,недоліків, їхнього функціонування, визначення своїх переваг перед конкурентами,передбачення структурних змін на ринку, оцінка гнучкості цінової політики, якостіпродукції, стабільності попиту на неї, збуту, конкурентоздатності виробленої продукції.
2. Постановка завдання2.1 Організаційно-економічна сутністькомплексу завдань
У даній роботі буде підняте питання автоматизаціїоперативного керування ведення однієї з галузей сільського хазяйства. Конкретноавтоматизації технологічної лінії вирощування гриба «вешенки». Починаючивід заготівлі субстракта й до його повного циклу плодоношення. Програма буде вестикілька таблиць, зв'язаних в одну базу даних. Це комплекс, на базі якого можна аналізувати,планувати й приймати рішення. Стежити за економічними показниками, ростом і скороченнямобсягів збуту, нарощуванні можностей, і збільшення рентабельності підприємства,шляхом зміни якісного складу субстракта та різних партій міцелію, від різних постачальників.
Програма універсальна, і може бать використанавсього на одному комп'ютері. Алі від цього її можливості не стають меншими. Інтерфейспрограми винний мати універсальність, як для операторів, технологів, які вносятьінформацію з виробничих циклів, так і для менеджерів, які аналізують постачальниківй обсяги зборів і реалізації продукції, а також для керівництва, що долино в повномуобсязі бачити необхідні дані для аналізу рентабельності, та й просто контролю завиробництвом і персоналом.
Програма винна мати в собі вусі вище перерахованей виконувати ряд інших завдань:
1) Ведення бази паспортів партії
2) Ведення бази по персоналі
3) Бази постачальників міцелію
4) Бази міцелію
5) Базу збору продукції операторами
6) Базу технологічної інформації з усіх цехів
7) Базу реалізованих обсяги продукції
Винна мати гнучку систему аналізу й плануваннявиробництва:
1) Графік місячних зборів
2) Річні збори
3) Графік аналізу рентабельності підприємства за будь-якийперіод
4) Графіки прогнозовані обсяги при різних значеннях рентабельностипідприємства.
Програма винна буде виконана мовою високого рівняDelphi 6 з використанням БД Interbase за допомогою інструмента IB Expert. Такожпрограма винна взаємодіють на програмному рівні з устаткуванням цехів, шляхом роботичерез зовнішні пристрої, а значити використати споконвічно загальноприйнятий протоколпередачі даних.2.2 Опис вхідної інформації
У даній програмі необхідно точно організувати правильней лаконічне використання вхідних даних, тому що смороду будуть у більшості прямовпливати на організацію полів у базі даних. Дані необхідно строго впорядкувати йрозділити на дві категорії: обробних й оброблюваних.
Типи даних повинні бути наведені до стандарту використовуваномув мові високого рівня Object Pascal (Delphi). Бази даних повинні бути організованіз використанням реаляційного підходу, на базі стандарту мови запитів SQL.
Конкретний список вхідних даних для успішної роботипрограми наведень у таблиці 2.2.1 Із вказівкою їхніх назв, типів і діапазонів прийнятихзначень.
Саме вхідні дані формують структуру майбутніх полівбази даних.
база інформаційна система автоматизація

Таблиця вхідних даних 2.2.1Назва Діапазон Тип даних  Паспорт партії 1.999999 Числовий Назва партії міцелію 1.999999 Числовий Порядковий номер збору 1.999999 Числовий Номер партії 1.999999 Числовий Кількість у партії 1.999999 Числовий Ваги партії 1.999999 Числовий Дата збору Дд. мм. рр Дата Дата виносу на плодоносіння Дд. мм. рр Дата Дата продажів Дд. мм. рр Дата Штам партії 100 Строковий Виробник 100 Строковий Оператор 100 Строковий Примітки 100 Строковий Дата засіву Дд. мм. рр Дата Кількість блоків 1.9999 Числовий Ваги блоків 1.9999 Числовий Загальна ваги партії 1.999999 Числовий Ціна -999999.999999 Currency Температура -30.150 числовий Вологість 0.100 числовий PH % числовий Соломка % числовий Лушпайка % числовий Гречка % числовий Вапно % числовий Інакулював 120 Строковий Перфорував 120 Строковий 2.3 Опис вихідної інформації
Вихідна інформація є, основний і представляє зсебе результат роботи програми й ведення хазяйства в цілому. На базі цієї інформаціїможна зручно аналізувати й прогнозувати майбутні періоди виробництва. Тому що даневиробництво повністю виявляє інерційну систему, де зміни виробництва в самих початковихетапах можуть бути помічені результатом лише через місяці. Програма виявляє собоюпотужну систему для прийняття рішень технологам, керівництву, менеджерам по продажахі відділу маркетингу. Вихідні дані розташовані в таблиці 2.3.1 й являють собою результат,а також базову складову майбутніх полів бази даних.
Таблиця вихідних даних 2.3.1Найменування Діапазон Тип даних Наростаючий підсумок за місяць 1.99999999 числовий Наростаючий підсумок за рік 1.99999999 числовий Наростаючий підсумок за період 1.99999999 числовий Рентабельність % числовий Торба зборів за день 1.99999999 числовий Торба зборів за місяць 1.99999999 числовий Торба зборів за звітний період 1.99999999 числовий Дані паспорти партії структура - Результати технологічного циклу структура - Об’єми за день 1.99999999 числовий обсяги за місяць 1.99999999 числовий обсяги за звітний період 1.99999999 числовий Торба по партії 1.99999999 числовий Примітки 500 Строковий Обсяги реалізації 1.99999999 Числовий
3. Проектування інформаційної системи3.1 Аналіз вхідної інформації предметноїобласті
Поняття тип даних у реляційної моделі данихповністю адекватно поняттю типу даних у мовах програмування. Звичайно в сучаснихреляційних БД допускається зберігання символьних, числових даних, бітових рядків,спеціалізованих числових даних (таких як «гроші»), а також спеціальних«темпоральних» даних (дата, година, часовий інтервал). Досить активнорозвивається підхід до розширення можливостей реляційних систем абстрактними типамиданих (відповідними можливостями володіють, наприклад, системи сімейства Ingres/Postgres).У нашому прикладі мі маємо справу з даними трьох типів: рядка символів, цілі числай «гроші».
Схема відносини — це іменована безліч пари {ім'я атрибута, ім'ядомена (або типу, якщо поняття домена не підтримується) }. Ступінь або «арность»схеми відносини — потужність цієї безлічі. Ступінь відносини СПІВРОБІТНИКИ дорівнюєчотирьом, тобто воно є 4-арным. Якщо всі атрибути одного відношення визначені нарізних доменах, осмислено використати для іменування атрибутів імена відповіднихдоменов (не забуваючи, звичайно, про ті, що це є всього лише зручним способом іменуванняй не усуває розходження між поняттями домена й атрибута).
Відношення — це безліч кортежів, що відповідають одній схемі відносини.Іноді, щоб не плутатися, говорять «відношення-схема» й «відношення-екземпляр»,іноді схему відносини називають заголовком відносини, а відношення як набір кортежів- тілом відносини. Насправді, поняття схеми відносини ближче всього до поняття структурноготипу даних у мовах програмування. Було б цілком логічно дозволяти окремо визначатисхему відносини, а потім одне або кілька відносин з даною схемою.
Однак у реляційных базах даних це не прийнято. Ім'я схеми відносинив таких базах даних завжди збігається з ім'ям відповідного відношення-екземпляра.У класичних реляційних базах даних після визначення схеми бази даних змінюютьсятільки відношення-екземпляри. У них можуть з'являтися нові й віддалятися або модифікуватисяіснуючі кортежі. Однак у багатьох реалізаціях допускається й зміна схеми бази даних:визначення нових і зміна існуючих схем відносини. Це прийнято називати еволюцієюсхеми бази даних.
Звичайним життєвим поданням відносини є таблиця, заголовком якоїє схема відносини, а рядками — кортежі відношення-екземпляра; у цьому випадку іменаатрибутів іменують стовпці цієї таблиці. Тому іноді говорять «стовпець таблиці»,маючи на увазі «атрибут відносини». Коли мі перейдемо до розгляду практичнихпитань організації реляційних баз даних і засобів керування, мі будемо використатицю життєву термінологію. Цієї термінології дотримуються в більшості комерційнихреляційних СУБД.3.2 Визначення зв'язків інформаційнихоб'єктів і побудова інформаційно — логічної моделі
Та властивість, що відносини не містять кортежів-дублікатів, требаз визначення відносини як безлічі кортежів. У класичній теорії множин по визначеннюкожна безліч складається з різних елементів.
Із цієї властивості випливає наявність у шкірного відношення такназиваного первинного ключа — набору атрибутів, значення яких однозначно визначаютькортеж відносини. Для шкірного відношення принаймні повний набір його атрибутівмає цю властивість. Однак при формальному визначенні первинного ключа потрібне забезпеченняйого «мінімальності», тобто в набір атрибутів первинного ключа не повиннівходити такі атрибути, які можна відкинути без шкоди для основної властивості — однозначно визначати кортеж. Поняття первинного ключа є винятково важливиму зв'язку з поняттям цілісності баз даних.
В багатьох практичних реалізаціях СУБД допускається порушення властивостіунікальності кортежів для проміжних відносин, породжуваних неявно при виконаннізапитів. Такі відносини є не безліччю, а мультимножествами, що в ряді випадків дозволяєдомогтися певних переваг, алі іноді приводити до серйозних проблем.
Атрибути відносин не впорядковані, оскільки по визначенню схемавідносини є безліч пар {ім'я атрибута, ім'я домена}. Для посилання на значення атрибутав кортежі відносини завжди використається ім'я атрибута. Це властивість теоретичнодозволяє, наприклад, модифікувати схеми існуючих відносин не тільки шляхом додаваннянових атрибутів, алі й шляхом видалення існуючих атрибутів. Однак у більшості існуючихсистем така можливість не допускається, і хоча впорядкованість набору атрибутіввідносини явно не потрібно, часто як неявний порядок атрибутів використається їхнійпорядок у лінійній формі визначення схеми відносини.3.3 Визначення логічної структури бази даних
Коли в попередніх розділах мі говорили про основні поняття реляційнихбаз даних, мі не опиралися на яку-небудь конкретну реалізацію. Ці міркування рівноюмірою ставилися до будь-якої системи, при побудові якої використався реляційнийпідхід.
Інакше кажучи, мі використали поняття так називаної реляційноїмоделі даних. Модель даних описує деякий набір родових зрозуміти й ознак, якимиповинні володіти всі конкретні СУБД і керовані ними бази даних, якщо смороду ґрунтуютьсяна цій моделі. Наявність моделі даних дозволяє порівнювати конкретні реалізації,використовуючи одну загальну мову.
Хоча поняття моделі даних є загальним, і можна говорити про ієрархічної,мережний, деякої семантичну й т.д. моделях даних, потрібно відзначити, що це поняттябуло поведене в побут стосовно до реляційним систем і найбільше ефективно використаєтьсясаме в цьому контексті. Спроби прямолінійного застосування аналогічних моделей додореляційним організацій показують, що реляційна модель занадто «велика»для них, а для постреляційних організацій вона виявляється «мала».
Найпоширеніше трактування реляційної моделі даних, мабуть, належитьДейту, що відтворює її (з різними уточненнями) практично у всіх своїх книгах. ЗгідноДейту реляційная модель складається із трьох частин, що описують різні аспекти реляційногопідходу: структурної частини, манипуляційної частини й цілісній частині.
У структурній частині моделі фіксується, що єдиною структурою даних,використовуваної в реляційних БД, є нормалізоване n-арное відношення. По суті справи,у попередніх двох розділах цієї лекції мі розглядали саме поняття й властивостіструктурної складової реляційної моделі.
У манипуляционной частини моделі затверджуються дві фундаментальнихмеханізми маніпулювання реляційними БД — реляційна алгебри й реляційне вирахування.Перший механізм базується в основному на класичній теорії множин (з деякими уточненнями),а другий — на класичному логічному апарату вирахування предикатів першого порядку.Мі розглянемо ці механізми більш докладно на наступній лекції, а поки лише помітимо,що основною функцією маніпуляційної частини реляційної моделі є забезпечення міриреляційності будь-якої конкретної мови реляційних БД: мова називається реляційним,якщо він має не меншу виразність і потужність, чим реляційна алгебра або реляційневирахування.
4. Об'єкти бази даних
Рис 4.1.1 Таблиця «Міцелій прихід»
/>
Рис 4.1.2 Таблиця «витрата міцелію»
/>

Рис 4.1.3 Таблиця «Паспорт партії»
/>
Рис.4.1.4 Таблиця «Постачальники»
/>

Рис 4.1.5 Таблиця «Збір»
/>
Наведені вище таблиця, своєю структурою зобов’язані вхідним данимїх яким їх сформували. Природно що серед полів є й ті які несуть результати вичисленихзначень, написання програми не мало змісту, не маючи кінцевого результату. Показання вище структура таблиць досить автономна,але й одночасно міцно на міцно зв'язана один з одним. Також хочу помітити що складновиділити головну базу й визначити залежні, тому що заповнення даннями і їх оперуванняв багатьох випадках мають свіязь «багато хто до багатьох»
Таблиця «прихід міцелію» рис 4.1.1 містить у собі інформаціюпро надходження на склад ресурсу міцелій. Має ключове поле номер партії міцелію.Це основне й унікальне значення використається із прив'язкою в базі паспорт партіїмал.4.1.3 Маючи загальне поле вони зв'язуються по ньому в співвідношенні один добагатьох.
Таблиця «Збір», містить основну інформацію про кількостізібраного продукту й датам збору. Вона щільно взаємодіє з таблицею паспорт партіїй несе в собі інформацію для подальшого аналізу, побудови звітів і графіків.
4.2 Запити
Вираження реляційної алгебри й формули реляційного вирахуваннявизначаються над відносинами реляційних БД і результатом обчислення також є відносини.У результаті будь-яке вираження або формула можуть інтерпретуватися як відносини,що дозволяє використати їх в інших вираженнях або формулах.
Як ми побачимо, алгебра й вирахування мають велику виразну потужність:дуже складні запити до бази даних можуть бути виражені за допомогою одного вираженняреляційної алгебри або однієї формули реляційного вирахування. Саме із цієї причинисаме ці механізми включені в реляційну модель даних. Конкретна мова маніпулюванняреляційним БД називається реляційно повним, якщо будь-який запит, що виражає задопомогою одного вираження реляційної алгебри або однієї формули реляційного вирахування,може бути виражений за допомогою одного оператора цієї мови.
Відомо (і ми не будемо це доводити), що механізми реляційної алгебрий реляційного вирахування еквівалентні, тобто для будь-якого припустимого вираженняреляційної алгебри можна побудувати еквівалентну (тобто виробляючий такий же результат)формулу реляційної вирахування й навпаки. Чому ж у реляційної моделі даних присутніобоє ці механізму?
Справа в тому, що вони розрізняються рівнем процедурності. Вираженняреляційної алгебри будуються на основі алгебраїчних операцій (високого рівня), іподібно тому, як інтерпретуються арифметичні й логічні вираження, вираження реляційноїалгебри також має процедурну інтерпретацію. Інакше кажучи, запит, представлениймовою реляційної алгебри, може бути обчислений на основі обчислення елементарнихалгебраїчних операцій з урахуванням їх старшинства й можливої наявності дужок. Дляформули реляційної вирахування однозначна інтерпретація, загалом кажучи, відсутній.Формула тільки встановлює умови, яким повинні задовольняти кортежі результуючоговідношення. Тому мови реляційної вирахування є більше непроцедурними або декларативними.
Оскільки механізми реляційної алгебри й реляційної вирахуванняеквівалентні, то в конкретній ситуації для перевірки ступеня реляційності деякоїмови БД можна користуватися кожним із цих механізмів.
Помітимо, що вкрай рідко алгебра або вирахування приймаються якповна основа якої-небудь мови БД. Звичайно (як, наприклад, у випадку мови SQL) моваґрунтується на деякій суміші алгебраїчних і логічних конструкцій. Проте, знанняалгебраїчних і логічних основ мов баз даних часто буває корисно на практиці.
Наприклад, для того щоб отримати вибіркову інформацію за заданимикритеріями, використовуючи засоби мови програмування високого рівня Object Pascal, треба написати SQL запит. Який повинен мати вигляд:
Select t. Nomer_Partii,t. Nazvanie from “Pasport_partii. db,Sbor. db S" t where t. Nomer= S. Nomer AND S. Nazvanie=”АК-221”
Для того, щоб побудувати запит, використовується ключове словоSelect далівказуються поля, які потрібно відобразити, from вказує на розташування бази і її назву. Для самоїбази можна встановити аліас, як це показано у прикладі. Аліас дає змогу швидко звертатисядо потрібного поля і розрізняти записи з однаковою назвою поля але різними таблицями.
Після ключового поля where вказуються умови відображення даних а також задаютьсяреляційні зв’язки.
Даний запит виводить інформацію про продану партію, яка має назву«АК-221».
На базі такої моделі програмно будуються і інші реляційні зв’язки.Це дає змогу не зберігати на носіях у таблиці продаж інформацію о партії а простобрати її з іншої таблиці. Також при оформленні заказу достатньо вказати номер партіїщоб покупець міг побачити всю інформацію по даній партії.
При використанні такої технології економно використовується нетільки пам’ять, яку займають таблиці, а й більш швидко обробляються дані, що значнододає у загальній швидкості роботи з програмою а також збільшує кількість записіву таблиці в цілому.4.3 Екранні форми введення й редагування даних
Інтерфейс даної програми дуже зручний і на одній сторінці дозволяєредагувати, переглядати й додавати нове запису в різні бази даних, які автоматичноприймають значення попереднього запису в базі. Перемикання по табу робить зручнимроботу не тільки користувачам звиклим працювати з мишкою але й клавіатурою. Компактністьінформації реалізована за рахунок компонента TNotebook палітри компонентів Delphi.
Зовнішній вигляд програми показаний на рисунку 4.3.1
Рис.4.3.1 «Зовнішній вигляд програми»
/>
У лівій частині програми розташований список партій установленихна плодоношення, праворуч відображаються її характеристики, такі як склад субстрату,міцелій, і ряд інших параметрів. Що б все це вмістити трохи нижче по центрі є панельна якій розташована більше докладна інформація для аналізу партії, але не потрібнадля загальної оцінки.
Збори одна з важливих складові програми, саме сдесь відповіднодо дат можна заносити й вивчати обсяги врожайності, тривалість хвилі плодоносіння,графік визрівання й зрілості продукту, аж до його старіння.
Перемикаючи ліворуч партії, праворуч ми бачимо все нову й новуінформацію. На панелі збору можна також оцінити який обсяги гриба, який був знятий,в обраний день, а повернувшись за графіком назад ми побачимо при яких умовах бувзакладений даний субстракт і його шлях розвитку.
Рис 4.3.2 «Рух міцелію»
/>
На малюнку 4.3.2 показаний інтерфейс роботи з рухом міцелію. Цересурс міцелію, його розподілення та інші характеристики. При додаванні нової партіїнеобхідний міцелій береться зі списку й додається. Програма автоматично запропонуєрекомендований обсяг і допоможе не перевищити запит при меншій кількості на складі.4.4 Звіти
Звіти в програмне представлені у вигляді графіків, на яких можнапобачити підсумки виробництва за різні періоди часу, а також місячні підсумки роботипідприємства, з налаштованими лініями тренда, для визначення в який день місяцяобсяги збільшувалися й зменшувались. На малюнку 4.4.1 можна побачити дані зібраніза липень місяць 2007 року. На цей момент підприємство виготовляло понад 10 тонпродукції на місяць.
Рис 4.4.1 «Звіт за вибраний місяць»
/>
На малюнку 4.4.2 можна побачити як працює масштабування в плотьдо годин збору. А також включений режим влучний, які показують зібрані обсяги накожен день.

Рис 4.4.2 «Звіт у масштабі»
/>
Даний вид подання інформації більше наочний і дужезручний. Можливий розрахунок і планування розвитку підприємства й багато чого іншого.Все це організовано на базі графіка компоненти мови високого рівня Делфі.
Висновок
ИБД оптимізує зв'язки й заощаджує час, що має величезнезначення для бізнесу, де кожен другий може, а також і до перекладу грошей за компанію.Він також додає до повного керування перспективних, а не вроздріб, оскільки вінвсю картину одним поглядом. Це збільшує продуктивність торговельних агентів, а такожпідвищує задоволення клієнтів.
Там цілий ряд рішень ИБД коливається навколо сьогодні.Це програмне забезпечення в електронному виді вкладок тримає всіх продажів у компанії.Це великий пристрій керування й рутинних завдань, як зв'язатися наступної діяльності,звітності й можливість привести поступки раптом змінилося, і більше ефективної.В основному вона передбачає продаж силу з інструментами, які допоможуть їм продаватикраще й швидше одержувати інформацію. Те, що вона може бути доступна в портативнихприладів означає, що інформація на миттєве торкання кнопки незалежно від того, уякому куточку країни або миру вашого персоналу in. Кишенькові комп'ютери можна використатине тільки одержувати інформацію, але й приймати вниз розпорядження, які миттєвопередається на головний офіс. Це також допомагає централізувати функцій і зробитиїх більше ефективними.
Це означає також оптимізації керування взаємодіїклієнта із правом першої зустрічі аж до післяпродажного обслуговування. Багато підприємств,особливо у фармацевтичній промисловості й виробничих компаніях, користуються величезноїустановки цього програмного забезпечення. Ці додатки можна використати для різнихвидів продажів персоналом компанії — торговельних представників і менеджерів порекламі. Обоє ці вимоги міняються. Це надто важливо, коли поле сил, як правило,велика кількість. Тоді керування персоналом стає досить простим з даним програмнимзабезпеченням.
Однак, перш ніж ви вирішите на ИБД програмногозабезпечення, от кілька моментів, про які не можна забувати. Насамперед йому необхіднобути простим. Вона повинна мати кілька варіантів продажу й він повинен мати можливістьпрацювати з декількома джерелами інформації. Вона повинна бути в ідеалі на базіweb, тому що це може бути величезноюперевагою, якщо не зараз, те коли вам рости в майбутньому. Він повинен також бутибезпечної й гнучкої до змін. Помнете, що гнучке програмне забезпечення є ефективнимпрограмним забезпеченням
Список використаної літератури
1. Д. Вейскас." Эффективная работа с BDE.".СПб 1996.
2. 2. Вудкок Дж., Янг М. Эффективная работа с Microsoft ODBC «Microsoft Press».
3. Горев А., Макашарипов С., Эффективная работа с СУБД: СПб, «Питер»,2000.
4. Кириллов В.В. Основы проектирования реляційних баз данных. Учебное пособие.- СПб.: ИТМО, 2001.
5. Потапкин А.В. Основы Delphi 6:М, «Эком», 2002.
6. Журнал «PC Magazine Russian Edition» 17,2000, статья У. Плейна, «BDEExpres».
7. Журнал «PC Magazine Russian Edition» 15,2000.
8. Журнал «КомпьюТерра» №37-38 2006.