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