| № п/п
| Код підприємства
| Назва підприємства
|
Для формування вихідного документа треба вибрати всі коди підприємств із вхідного файла, знайти ці коди у Довіднику підприємств, за ними визначити відповідні назви підприємств.
Позначимо поля формування рядка вихідного документа:
i — поле порядкового номера списку;
PRED — код підприємства;
NAME — назва підприємства.
Позначимо поля області зчитування записів довідника:
DPRED — код підприємства;
DNAME — назва підприємства;
DADRES — адреса;
DFON — телефон.
Зауважимо: вхідний файл упорядкований за кодами підприємств, цехів та прізвищами; довідник упорядкований за кодами підприємств. Тому при всіх наступних зверненнях до довідника можна продовжувати його зчитування. При нормальній роботі не буде виходу на кінець довідника. Вихід на кінець довідника означає, що в ньому відсутній запис підприємства із шуканим кодом. Треба передбачати в алгоритмі, щоб у такій ситуації видавалося відповідне повідомлення.
Складемо алгоритм формування та друку списку підприємств. (рис. 6.12).
Рис. 6.12. Приклад 6 алгоритму використання довідника (6.7)
6.1.8. Розрахунки підсумків на основі багатьох запитів
з використанням декількох вхідних файлів (6.8)
Якщо для обробки запиту використовуються декілька файлів, то технологія мало чим відрізняється від технології використання файла довідника. Тобто необхідно чітко визначити, в якому місці алгоритму обробки запиту треба звертатися до того чи іншого файла, а також твердо пам’ятати: при повторному звертанні до того самого файла зчитування його записів відновиться з чергового запису. Крім того, завжди треба знати, в якому разі здійснюється вихід на кінець того чи іншого файла, і передбачати відповідні дії та друк повідомлень.
Автоматизація задач управління будь-яким об’єктом здійснюється за допомогою комплексу програм, кожна з яких реалізує певну функцію управління.
Отримати інформацію про функціонування об’єкта можна за допомогою запиту, обробку якого виконує деякий комплекс програм. Отже, запити мають бути класифіковані і формульовані у стандартній формі (у системі є певний перелік припустимих запитів, які називають регламентними). Їх вносять у меню комплексу задач, і для отримання необхідної інформації про об’єкт треба, використовуючи меню, визначити шлях виходу на модулі обробки запиту. Зрозуміло, що форма вихідної інформації не є довільною, вона чітко визначена у програмах обробки регламентного запиту.
Якщо запит не є регламентним, то може бути три варіанти: є регламентний запит, інформація якого містить у собі необхідну інформацію як частину; є регламентний запит, який може частково задовольнити нерегламентний запит; немає жодного регламентного запиту, який дав би необхідну інформацію. В останньому випадку необхідно розробити комплекс програм обробки нового регламентного запиту і ввести його у відповідне місце меню.
Таким чином, перш ніж виконувати обробку, треба передбачити аналіз запиту з вибором відповідного варіанта розрахунків.
Можна побудувати загальний алгоритм обробки запитів з використанням одного чи декількох файлів (рис. 6.13).
Треба додати, що чим більше система містить програм обробки регламентних запитів, тим корисніша вона для користувача.
Зазначимо, що система об’єктів, об’єкт або підрозділ мають декілька рівнів управління, на кожному рівні реалізуються свої функції, і для прийняття певних управлінських рішень необхідна різна інформація. Чим вищий рівень управління, тим більш узагальнена інформація потрібна для обробки запитів. Наприклад, керівникові об’єкта може знадобитися бухгалтерська інформація, але менш деталізована та інакше структурована, ніж інформація для бухгалтера певної ланки бухгалтерії. Отже, і регламентні запити на різних рівнях управління об’єктом будуть різними і спиратимуться на різну інформацію інформаційної бази.
Рис. 6.13. Загальний алгоритм 6.8 обробки запитів
з використанням одного чи декількох файлів
Плани практичних занять
