3) Бази постачальників міцелію
4) Бази міцелію
5) Базу збору продукції операторами
6) Базу технологічної інформації з усіх цехів
7) Базу реалізованих обсяги продукції
Винна мати гнучку систему аналізу й планування виробництва:
1) Графік місячних зборів
2) Річні збори
3) Графік аналізу рентабельності підприємства за будь-який період
4) Графіки прогнозовані обсяги при різних значеннях рентабельности підприємства.
Програма винна буде виконана мовою високого рівня Delphi 6 з використанням БД Interbase за допомогою інструмента IB Expert. Також програма винна взаємодіють на програмному рівні з устаткуванням цехів, шляхом роботи через зовнішні пристрої, а значити використати споконвічно загальноприйнятий протокол передачі даних.
У даній програмі необхідно точно організувати правильне й лаконічне використання вхідних даних, тому що смороду будуть у більшості прямо впливати на організацію полів у базі даних. Дані необхідно строго впорядкувати й розділити на дві категорії: обробних й оброблюваних.
Типи даних повинні бути наведені до стандарту використовуваному в мові високого рівня 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.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 | Числовий |
Поняття тип даних у реляційної моделі даних повністю адекватно поняттю типу даних у мовах програмування. Звичайно в сучасних реляційних БД допускається зберігання символьних, числових даних, бітових рядків, спеціалізованих числових даних (таких як "гроші"), а також спеціальних "темпоральних" даних (дата, година, часовий інтервал). Досить активно розвивається підхід до розширення можливостей реляційних систем абстрактними типами даних (відповідними можливостями володіють, наприклад, системи сімейства Ingres/Postgres). У нашому прикладі мі маємо справу з даними трьох типів: рядка символів, цілі числа й "гроші".
Схема відносини - це іменована безліч пари {ім'я атрибута, ім'я домена (або типу, якщо поняття домена не підтримується) }. Ступінь або "арность" схеми відносини - потужність цієї безлічі. Ступінь відносини СПІВРОБІТНИКИ дорівнює чотирьом, тобто воно є 4-арным. Якщо всі атрибути одного відношення визначені на різних доменах, осмислено використати для іменування атрибутів імена відповідних доменов (не забуваючи, звичайно, про ті, що це є всього лише зручним способом іменування й не усуває розходження між поняттями домена й атрибута).
Відношення - це безліч кортежів, що відповідають одній схемі відносини. Іноді, щоб не плутатися, говорять "відношення-схема" й "відношення-екземпляр", іноді схему відносини називають заголовком відносини, а відношення як набір кортежів - тілом відносини. Насправді, поняття схеми відносини ближче всього до поняття структурного типу даних у мовах програмування. Було б цілком логічно дозволяти окремо визначати схему відносини, а потім одне або кілька відносин з даною схемою.
Однак у реляційных базах даних це не прийнято. Ім'я схеми відносини в таких базах даних завжди збігається з ім'ям відповідного відношення-екземпляра. У класичних реляційних базах даних після визначення схеми бази даних змінюються тільки відношення-екземпляри. У них можуть з'являтися нові й віддалятися або модифікуватися існуючі кортежі. Однак у багатьох реалізаціях допускається й зміна схеми бази даних: визначення нових і зміна існуючих схем відносини. Це прийнято називати еволюцією схеми бази даних.
Звичайним життєвим поданням відносини є таблиця, заголовком якої є схема відносини, а рядками - кортежі відношення-екземпляра; у цьому випадку імена атрибутів іменують стовпці цієї таблиці. Тому іноді говорять "стовпець таблиці", маючи на увазі "атрибут відносини". Коли мі перейдемо до розгляду практичних питань організації реляційних баз даних і засобів керування, мі будемо використати цю життєву термінологію. Цієї термінології дотримуються в більшості комерційних реляційних СУБД.
Та властивість, що відносини не містять кортежів-дублікатів, треба з визначення відносини як безлічі кортежів. У класичній теорії множин по визначенню кожна безліч складається з різних елементів.
Із цієї властивості випливає наявність у шкірного відношення так називаного первинного ключа - набору атрибутів, значення яких однозначно визначають кортеж відносини. Для шкірного відношення принаймні повний набір його атрибутів має цю властивість. Однак при формальному визначенні первинного ключа потрібне забезпечення його "мінімальності", тобто в набір атрибутів первинного ключа не повинні входити такі атрибути, які можна відкинути без шкоди для основної властивості - однозначно визначати кортеж. Поняття первинного ключа є винятково важливим у зв'язку з поняттям цілісності баз даних.
В багатьох практичних реалізаціях СУБД допускається порушення властивості унікальності кортежів для проміжних відносин, породжуваних неявно при виконанні запитів. Такі відносини є не безліччю, а мультимножествами, що в ряді випадків дозволяє домогтися певних переваг, алі іноді приводити до серйозних проблем.
Атрибути відносин не впорядковані, оскільки по визначенню схема відносини є безліч пар {ім'я атрибута, ім'я домена}. Для посилання на значення атрибута в кортежі відносини завжди використається ім'я атрибута. Це властивість теоретично дозволяє, наприклад, модифікувати схеми існуючих відносин не тільки шляхом додавання нових атрибутів, алі й шляхом видалення існуючих атрибутів. Однак у більшості існуючих систем така можливість не допускається, і хоча впорядкованість набору атрибутів відносини явно не потрібно, часто як неявний порядок атрибутів використається їхній порядок у лінійній формі визначення схеми відносини.
Коли в попередніх розділах мі говорили про основні поняття реляційних баз даних, мі не опиралися на яку-небудь конкретну реалізацію. Ці міркування рівною мірою ставилися до будь-якої системи, при побудові якої використався реляційний підхід.
Інакше кажучи, мі використали поняття так називаної реляційної моделі даних. Модель даних описує деякий набір родових зрозуміти й ознак, якими повинні володіти всі конкретні СУБД і керовані ними бази даних, якщо смороду ґрунтуються на цій моделі. Наявність моделі даних дозволяє порівнювати конкретні реалізації, використовуючи одну загальну мову.