Разработка АСИС “Учет поставок”

• бланк договору підприємства замовника з фірмою-постачальником (з вказівкою найменування і юридичних адрес сторін, що беруть участь в  договорі, асортименту продукції для постачань, її кількості, гаданої вартості, умови і терміни дії договору);
• заявку на постачання необхідній продукції (указується кількість, найменування, номенклатура, терміни постачання, сума постачання);
• замовлення на постачання.

    Комерційна  версія  програмного продукту дозволить  проводити:

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

    Що  розробляється автоматизована система  повинна буде реалізувати наступні функції:

1. Забезпечення введення даних про постачання на підприємство;
2. Аналіз введеної інформації;
3. Підрахунок заборгованості підприємства за здійснені постачання;
4. Визначати оптимальний рахунок з точки зору “кількість-ціна”;
5. Проводить друк документації, пов'язаної з організацією постачань (бланк договору, замовлення, заявки).

 

    1.3.4. Початкові вимоги  до кінцевого результату. 

Вимоги  по функціональності.

    АСИС, що розробляється, повинен забезпечувати  автоматизований контроль, а так  само облік постачань на підприємство (цех цього підприємства), для  цього створювана система винна:

• Забезпечувати введення, пов'язаних з постачаннями на підприємство і обробку  цих даних;
• Створювати звітні документи і документи для організації грузопоставок; ( Додаток 3)
• Мати систему допомоги за програмою;
• При введенні даних про найменування  товарів повинен використовуватися довідник “Номенклатура товарів”;
• Створювані документи повинні відповідати галузевим стандартам, прийнятим на підприємстві.

 

Умови експлуатації

      Створюваний програмний продукт повинен буде використовуватися директором підприємства, начальником цеху, начальником складу, залежно від місця експлуатації продукту. Задані характеристики функціонування повинні забезпечуватися за умов, які визначаються конкретним носієм даних, на якому зберігаються дані.  Найбільш поширеними носіями даних в даний час є жорсткі диски, для яких оптимальним є функціонування при температурах від 5 до +35^оС і відносній вологості від 10 до 60 відсотків.

Вимоги  до складу і параметрів технічних засобів

      Програма  повинна функціонувати на персональних комп'ютерах з наступною конфігурацією:

• IBM PC/AT сумісних ПЕВМ не нижче Pentium 100;
• з об'ємом ОЗУ не менше 16 мегабайт;
• Об'єм необхідного дискового простору - не менше 10 мегабайт.

Вимоги  до інформаційної  і програмної сумісності

  Створювана  програма повинна функціонувати, легко  інсталюватися, настроюватися і  коректно працювати  при виконанні  наступних вимог:

• наявність операційної системи типу Windows 95, Windows 98, Windows NT 4.x, Windows 2000 і сумісних з ними;
• наявність бази даних LocalInterBase або сумісних з нею;
• введення дати обов'язкове у формі маски;
• введення цифр обов'язкове.

Вимоги  по захисту.

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

    2 Плановані показники ефективності. 

      В результаті виконаної роботи передбачається досягти наступних ефектів:

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

    2.1 Аналіз представлення  моделей даних. 

    Для ефективного функціонування АСИС, що розробляється, “Облік постачань” буде розроблений СУБД. Тому нижче розглянуті логічні і концептуальні моделі даних.

    2.2 Вибір логічної моделі даних. 

    2.2.1 Ієрархічна модель  даних. 

    Ієрархічна  модель даних є ієрархією у вигляді дерева. Дана модель даних базується на сегменті, який є сукупністю полів, що характеризують даний сегмент. Сегменти розрізняються за типом, а кожен тип характеризується фіксованою довжиною і конкретним розбиттям на поля даних. Два зв'язані сегменти, розташованих на суміжних рівнях називаються початковим (більш високого рівня) і породженим (нижчого). Ієрархічний запис – система взаємозв'язаних сегментів, в якій кожен породжений сегмент представлений стільки раз, скільки необхідно для повного розкриття даного сегменту. У ієрархічній структурі є сегмент, який не має початкового і називається головним або кореневим. У цьому сегменті зазвичай розташовується ідентифікатор об'єкту, властивості якого розкриваються в сегментах другого і нижчих рівнів ієрархії.

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

• Складність реалізації “багато до багатьом”, що вимагає надмірності даних на фізичному рівні, що приведе до небажаного і не виправданого збільшення БД;
• вимога підвищеної коректності до операції видалення, оскільки видалення початкового сегменту спричиняє за собою видалення породжених;
• доступ до будь-якого породженого сегменту можливий тільки через початковий, що збільшує час відповіді а запит до БД.

У зв'язку з тим, що ієрархічна модель володіє великою  кількістю недоліків вона не буде застосуються для моделювання АСИС, що розробляється.

 

2.2.2 Мережева модель  даних 

    Мережа [5] – більш загальна структура  порівняно з ієрархією. Вузлами  мережі є окремі екземпляри запису. Вузли запису є одиницею доступу  до БД. Оскільки окремий вузол може мати декілька безпосередньо старших  вузлів, так само, як і декілька безпосередньо підлеглих, то дана структура забезпечує пряме представлення відношення “багато до багатьом”. Для зв'язку між записами-вузлами існує запис, що пов'язує, всі екземпляри якого поміщаються в ланцюжок для зв'язку двох екземплярів.

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

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

    Головний  недолік мережевої моделі полягає  в складності структур пам'яті. Користувач повинен знати, які ланцюжки існують і які відсутні. В результаті мова запитів процедурна і вимагає навиків програмістів.

 

     2.2.3 Реляционная модель  данных.

Реляційна модель – множинним відношенням  яке є підмножина декартова твори списку доменів [27,20]. Домен – це безліч значень, з якої витягуються значення для даного атрибуту. Іншими словами в основі реляційної моделі лежать прості таблиці, які задовольняють певним обмеженням, а тому можуть розглядатися як математичні відносини. Рядки таких таблиць називаються кортежами, імена стовпців – атрибутами. Слід зазначити, що всі кортежі різні, а порядок стовпців довільний, чим спрощується процес обробки кортежів. У відношенні (таблиці)  виділяється декілька атрибутів, що однозначно ідентифікують кортежі і званих ключами.

Особливість реляційної моделі полягає в тому, що у відмінності від мережевої  і ієрархічної моделей реальні  об'єкти і взаємозв'язки між ними представляються в базі даних  одноманітно у вигляді нормалізованих відносин [24].

Основний  недолік реляційної моделі даних  зв'язується з низькою продуктивністю реляційної СУБД. Але розробка сучасних СУБД таких як, ORACLE, InterBase, Acsses і ін. дозволило подолати і цей недолік.

Достоїнства реляційної моделі можна розділити  на дві групи:

1. достоїнства для користувача:

• реляційна БД є набором таблиць з якими користувач звик працювати;
• не потрібно пам'ятати шляху доступу даним і будувати алгоритми і процедури обробки свого запиту;
• реляційні мови легкі для вивчення і освоєння, тоді як мови спілкування з ієрархічною і мережевою моделями призначені для програмістів і мало придатні для користувачів;

2. достоїнства обробки даних реляційною БД:

• зв'язність. Реляційне уявлення дає ясну картину взаємозв'язків атрибутів з різних відносин;
• точність. Направлені зв'язки в реляційній БД відсутні. Відносини за своєю природою володіють точнішим сенсом і піддаються маніпулюванню з використанням таких засобів, як алгебра і числення відносин [5], забезпечуючу наочність і гнучкість моделі даних;
• гнучкість. Операції проекції і об'єднання [17] дозволяють розрізати і склеювати відносини, так що програміст може отримувати різноманітні файли в потрібній формі;
• секретність. Контроль секретності спрощується. Для кожного відношення є можливість завдання правомірності доступу, засекречені показники можна виділити в окремі відносини з перевіркою прав доступу.
• Простота впровадження. Фізичне розміщення однорідних (табличних) файлів набагато простіше, ніж розміщення ієрархічних і мережевих структур.
• Незалежність даних. БД повинна допускати можливість розширення, тобто додавання нових атрибутів і відносин.

Вивід: оскільки серед перерахованих логічних моделей даних реляційна володіє значними перевагами і малими недоліками, то вона і буде узята в основу для побудови СУБД.