Автоматизована довідково-інформаційна система обліку і контролю постачань на
підприємстві
1. Стан проблеми обліку поставок на підприємство.
Введення
Господарство України являє собою сукупність підприємств і організацій
окремих галузей народного господарства різних форм власності. Підприємства
державної форми власності перебувають у віданні різних міністерств і
відомств, а також у веденні місцевих виконкомів. Виробнича діяльність
як і господарська, спрямовані на випуск предметів культурно-побутового
призначення, господарського вжитку та ін
Таким чином, до складу господарства України входять підприємства і організації, як
сфери матеріального виробництва, так і сфери обслуговування, як госпрозрахункові,
так і перебувають на державному бюджеті. Найбільше число держбюджетних
організацій знаходиться у веденні Міністерства освіти і науки України: школи,
дитячі сади, педагогічні інститути, технікуми, училища і т.п. (близько 30%
загальної кількості організацій); міністерства охорони здоров'я України - лікарні,
санаторії, госпіталі та ін лікувальні установи (близько 20%); міністерства
культури і освіти України - театри, бібліотеки, музеї та ін (більше 25%
загальної кількості організацій) [3].
Керівництво місцевим господарством країни організовано як за галузевим принципом
(через відповідні міністерства та відомства), так і за територіальним
(через місцеві органи управління).
Підприємства господарства України проводять різноманітну продукцію. В її числі
можна знайти засоби виробництва: верстати, машини, металопродукцію, що виробляється
народного споживання, предмети побутової хімії тощо
Для виробництва всієї перерахованої вище продукції підприємства, незалежно від
форм власності, для свого нормального і стабільного функціонування
мають потребу в сировині, комплектуючих, запчастини і т.п. Іншими словами для організації
своєї діяльності підприємства стикаються з проблемою своєчасного постачання
продукції. Для цих цілей підприємства державної форми власності
використовують постачальницькі організації (в даний час цими організаціями
мають спеціалізовані державні підприємства), підприємства ж
приватних форм власності проводять відповідні заходи, спрямовані на
своєчасне та безперервне забезпечення необхідною сировиною або матеріалами. Але в
даний час практично всі підприємства будь-якої форми власності
самостійно займаються пошуком підприємств-постачальників, а також у міру
необхідності організацією поставок.
Одним з показників що характеризують роботу підприємства є товарооборот,
який являє собою планово організаційний процес обігу коштів
виробництва [2], від якого багато в чому залежать і інші економічні
показники. До загального обсягу товарообігу включають всі товари, реалізовані
підприємством, тобто отримані від підприємств постачальників продукції. Також
товарообіг показує наскільки швидко підприємство використовує отриману
продукцію, тобто якими темпами воно здійснює свою діяльність, чим більше на
підприємство здійснюється постачання, тим більш стабільно працює цей
підприємство.
При здійсненні поставок на підприємство проводиться обробка та зберігання
великої кількості інформації, пов'язаної з поставками, яка в себе включає:
своєчасне і правильне оформлення документів та контроль за кожною операцією
надходження товарів від постачальників, з переробки та інших джерел,
виявлення розбіжності фактичної наявності та кількості, зазначеної в
супровідних документах;
контроль за своєчасним, повним і правильним оприбуткуванням надійшли
товарів;
своєчасне і правильне оформлення документації та контроль за кожною
операцією відпустки, відвантаження або реалізації товару;
контроль за дотриманням нормативів запасу товарів.
У зв'язку з цим для надійного функціонування системи постачань необхідно вести
їх систематичний і безперервний облік, що і буде виконувати розробляється ПЗ.
Розробляється програмний продукт буде відрізнятися від аналогічного
програмного забезпечення можливістю застосування на сучасній
електронно-обчислювальної техніки [1], зручний інтерфейс, низькою вартістю,
можливістю його використання на будь-якому підприємстві.
1.1 Загальна характеристика проблеми
При здійсненні поставок підприємства виробники продукції
виробничо-технічного призначення вступають у договірні відносини з
підприємствами споживачами (покупцями) як постачальники укладають прямі
договору з підприємствами споживачами для збуту продукції та комплексного
постачання підприємств-замовників.
Договори про постачання необхідно укладати своєчасно. У них вказуються
умови поставки товарів, їх кількість, асортимент, якість, комплектність і
строки поставки. Крім того, у договорах передбачено ціни на товари, загальна
сума, порядок розрахунків, платіжні та відвантажувальні реквізити постачальника і
одержувача продукції. Договору підлягають обов'язковому виконанню за всіма
зазначеним у них пунктам. Порушення строків договорів та зобов'язань тягне
відповідальність, передбачену "Положенням про поставку продукції
виробничо-технічного призначення "і" Особливими умовами поставки. "
Контроль за виконанням договорів здійснюють товарні відділи.
Раціональна організація приймання продукції від постачальників має важливе значення
для своєчасного, повного, комплексного постачання підприємств сировиною,
матеріалами, паливом, інструментами, устаткуванням та іншими засобами
виробництва.
Правильна приймання та оформлення документами, що надійшли товарів
Чи є надійною основою збереження товарно-матеріальних цінностей.
Загальний порядок приймання товарно-матеріальних цінностей встановлено "Положенням про
постачання продукції виробничо-технічного призначення ". Порядок і строки
приймання товарно-матеріальних цінностей в певній кількості і якості,
оформлення актів приймання і пред'явлення претензій визначені інструкцією про
порядок приймання продукції виробничо-технічного призначення і товарів
народного споживання за кількістю та інструкцією про порядок приймання продукції
виробничо-технічного призначення за якістю. Особливості приймання
окремих видів продукції визначаються в ГОСТах [12.01.005-89], технічних
умовах, Особливих умов поставки і договорах поставки, що передбачають
особливі порядки приймання продукції при поставках.
На підприємствах державної форми власності здійсненням всіх дій
пов'язаних з постачанням і оформленням необхідних документів, за наявності
відповідного програмного забезпечення, займається певну кількість
персоналу підприємства, але, як правило, розробка такого програмного
забезпечення велася на мовах низького рівня програмування, а за останні 6-8
років розвиток машинних засобів (ПЕОМ), програмних засобів різко збільшилася,
тому раніше розроблене ПЗ не відповідає більш високим вимогам,
що пред'являються до сучасних програмних продуктів. Що ж стосується підприємств,
фірм різний форм приватної власності, то вони часто не мають зовсім
відповідного програмного забезпечення, що значно збільшує
трудомісткість процесу контролю та обліку проведення поставок. Розроблювальний
програмний продукт і покликаний вирішувати дані проблеми.
1.2 Формулювання завдань
Будь-яке підприємство, здійснюючи свою діяльність, для одержання продукції від
постачальників має укласти з останніми договір на поставку продукції. Зазвичай
на однойменну продукцію підприємство-замовник укладає кілька договорів з
підприємствами-постачальниками. Потім замовник по мірі потреби у певній
продукції висилає постачальнику заявку на поставку продукції і отримує від
останнього рахунок-фактуру, у якому зазначено найменування продукції та її відпускна
ціна. На підставі цих рахунків підприємство-замовник визначає оптимальну
заявку і надсилає постачальнику замовлення на постачання продукції. Після отримання
замовленої продукції замовник відправляє рахунок в бухгалтерію, яка оплачує
його в банку протягом терміну, передбаченого договором. Тому для
документального забезпечення процесу постачання на підприємство програма повинна
створювати (роздруковувати) такі необхідні документи:
бланк договору підприємства-замовника з фірмою-постачальником (із зазначенням
найменування та юридичних адрес сторін, асортименту продукції для поставок,
її кількості і ймовірної вартості, а також умови та терміни дії
договору);
замовлення на поставку необхідної продукції (вказується кількість, найменування,
номенклатура, терміни поставки).
Також створюється автоматизована система за наявними даними про постачальників і
знову з отриманими даними повинна визначати оптимальний рахунок-фактуру з точки
зору кількість-ціна.
Будь-яку постачання підприємство-замовник зобов'язаний сплатити у встановлені договором
терміни, тому АС повинна здійснювати підрахунок суми боргу (грошей для виплати) на
поточну дату.
1.3 Мотивація завдань.
Підприємство або фірма, виробляючи свою продукцію, потребує постачання сировини від
інших підприємств. Але на одне і теж сировину у різних виробників-постачальників
різна відпускна ціна, тому з метою зниження собівартості продукції, що випускається
продукції підприємство замовник укладає договори з великою кількістю
постачальників і потім висилає постачальникам заявку на постачання продукції з
зазначенням типу і її кількості. Оскільки підприємство-замовник при отриманні
вантажів так чи інакше пов'язане з документами, з документальним оформленням
постачань, то проектована АСИС повинна створювати всі бланки документів,
пов'язаних з поставками.
Оскільки всі постачальники висилають замовнику рахунки-фактури (прейскурант цін на
замовлену продукцію), то серед їх безлічі необхідно визначити найбільш
вигідне для підприємства-замовника, як за ціною, так і за якістю, що і повинна
виконувати створювана АС.
Оскільки договори з постачальниками укладаються на певний строк, передбачуване
кількість продукції, що постачається і на певну суму, то при здійсненні
замовлення на поставку продукції, в договорі обумовлюється термін, протягом якого
замовлення повинен бути сплачений, тому необхідно знати суму до оплати на вказане
число, як загальну так і по різних постачальникам окремо.
Так як всі перераховані вище дії здійснюються впродовж тривалого
часу, то при прийнятті рішення про продовження терміну дії договору
доцільно брати до уваги такі чинники: якість поставок
конкретними постачальниками (мається на увазі виконання термінів здійснення
поставок, відповідність номенклатури поставленої продукції замовленої,
відсутність або відсоток браку), його терпимість по відношенню до оплати по
поставок. Тому необхідно зберігати всю інформацію про постачання на
підприємство, що б надалі її можна було б використовувати.
1.3. Технічне завдання.
Введення.
Автоматизована довідково-інформаційна система (АСИС) "Облік поставок" буде
використовуватися на підприємствах різних форм власності та забезпечувати
контроль та облік поставок вироблених на підприємство. Також при використанні
даного ПЗ буде матися можливість складання звітності про поставки на
підприємство, виявлення заборгованості з оплати поставок. Розробляється за
може бути використано як керівником підприємства, для здійснення
контролю вироблених поставок на підприємство, так і начальниками цехів, для
ведення обліку поставок.
1.3.1. Підстави для розробки.
Підставою для виконання роботи є наказ про базу переддипломної практики
від 10 червня 1999 р. № 270 за Державним аерокосмічного університету та
наказ про дипломному проектуванні від 26 червня 2000 р. № 271.
1.3.2. Призначення розробки.
Метою дипломного проектування є розробка та створення програмного
продукту "Облік поставок". Даний програмне забезпечення призначене для
контролю, обліку, автоматизації та систематизації інформації про постачання
різного виду продукції на підприємство будь-якої форми власності, які займаються
будь-яким видом виробництва або діяльності.
Розробляється програмний продукт повинен забезпечувати створення інформаційної
бази про здійснені поставки на підприємство, а також здійснювати створення
наступних документів:
бланк договору підприємства замовника з фірмою-постачальником (із зазначенням
найменування та юридичних адрес сторін, що беруть участь в договорі,
асортименту продукції для поставок, її кількості, ймовірної
вартості, умови та терміни дії договору);
заявку на поставку необхідної продукції (вказується кількість,
найменування, номенклатура, терміни поставки, сума поставки);
замовлення на поставку.
Комерційна версія програмного продукту дозволить проводити:
більш повний контроль та організацію обліку про постачання на підприємство;
автоматизувати процес оформлення поставок на підприємство;
зменшить тимчасові витрати на оформлення документів, пов'язаних з поставками;
обчислювати заборгованість з оплати здійснених поставок на зазначений період;
забезпечити користувача системою допомоги як за поняттями предметної області,
так і з користування програмним продуктом.
Розробляється автоматизована система повинна буде реалізувати наступні
функції:
Забезпечення введення даних про постачання на підприємство;
Аналіз введеної інформації;
Підрахунок заборгованості підприємства за здійснені поставки;
Визначати оптимальний рахунок-фактуру з точки зору "кількість-ціна";
Виробляє друк документації, пов'язаної з організацією поставок (бланк
договору, замовлення, заявки).
1.3.3. Вихідні дані і джерела.
Дана робота базується на темі переддипломної практики і є її
продовженням з урахуванням рекомендацій щодо поліпшення раніше розробленого ПЗ,
запропонованих керівником практики від підприємства і групою співробітників цього
підприємства і розглянутих керівником практики від інституту.
1.3.4. Вихідні вимоги до кінцевого результату.
Вимоги по функціональності.
Розробляється АСИС повинен забезпечувати автоматизований контроль, а так само
облік поставок на підприємство (цех цього підприємства), для цього створюється
система повинна:
Забезпечувати введення, пов'язаних з постачанням на підприємство і обробку цих
даних;
Створювати звітні документи та документи для організації грузопоставок; (
Додаток А)
Мати систему допомоги за програмою;
При введенні даних про найменування товарів повинен використовуватися довідник
"Номенклатура товарів";
Створювані документи повинні відповідати галузевим стандартам, прийнятим на
підприємстві.
Умови експлуатації
Створюваний програмний продукт повинен буде використовуватися директором
підприємства, начальником цеху, начальником складу, залежно від місця
експлуатації продукту. Задані характеристики функціонування повинні
забезпечуватися за умов, які визначаються конкретним носієм даних,
на якому зберігаються дані. Найбільш розповсюдженими носіями даних в
даний час є жорсткі диски, для яких оптимальним є
функціонування при температурах від +5 до +35 С і відносній вологості від 10
до 60 відсотків.
Вимоги до складу і параметрів технічних засобів
Програма повинна функціонувати на персональних комп'ютерах з наступною
конфігурацією:
IBM PC/AT сумісних ПЕОМ не нижче Pentium 100;
з об'ємом оперативної пам'яті не менше 16 мегабайт;
Обсяг необхідного дискового пространства - не менше 10 мегабайт.
Вимоги до інформаційної та програмної сумісності
Створювана програма повинна функціонувати, легко інсталюватися,
налаштовуватися і коректно працювати при виконанні наступних вимог:
наявність операційної системи типу Windows 95, Windows 98, Windows NT 4.x,
Windows 2000 і сумісних з ними;
наявність бази даних LocalInterBase або сумісних з нею;
введення дати обов'язковий у формі маски;
введення цифр обов'язковий.
Вимоги щодо захисту.
Для забезпечення захисту від несанкціонованого доступу до інформації, пов'язаної з
постачаннями на підприємство буде передбачена система паролів при завантаженні
програми в оперативну пам'ять. Для забезпечення захисту даних про збої в мережі
живлення ПК або аварійному завершенні роботи програми буде передбачений режим
автозбереження.
1.3.5. Етапи проведення робіт.
Етапи проведення роботи представлені в таблиці 1.2.
Таблиця 1.2. Етапи проведення роботи. № ЕтапиСрокі виполненіяОтчетность
1Ізученіе принципів системи грузопоставок на предпріятіе07.07.1999 -
14.07.1999
2Ознакомленіе з раніше виконану работой01.09.1999-08.09.1999
3Определеніе вимог до разработке9.09.2000-19.09.1999Техніческое
завдання
4Разработка інформаційної моделі предметної області (побудова
концептуальної моделі) 20.09.200-09.10.1999
5Вибор алгоритмічних средств10.10.1999-28.10.1999
6Определеніе програмних средств29.10.99-07.11.1999
7Вибор методики випробування і тестірованія08.11.1999-15.11.1999Техніческое
пропозиція
8Разработка алгоритмів, пов'язаних з реалізацією обліку поставок16.11.1999-
9.12.1999
9Проектірованіе алгоритмів, пов'язаних з формуванням тестових
заданій10.12.1999 - 20.12.1999
10Определеніе засобів проведення тестування та аналізу його
результатов11.12.1999-30.12.1999
11Разработка програмного забезпечення пов'язаного з реалізацією обліку
поставок на предпріятіе31.12.1999-15.02.2000
12Разработка програмного забезпечення пов'язаного з формуванням тестових
заданій16.02.2000-3.03.2000
13Реалізація програмного забезпечення проведення тестування і аналізу
його результатов4.03. 2000 - 4.04.2000
14Проведеніе тестування і випробувань розробленого програмного
обеспеченія5.04.2000-19.04.2000
16Напісаніе розрахунково-пояснювальної запіскі20.04.2000-
21.05.2000Расчетно-пояснювальна записка
17Подготовка плакатов22. 05.2000-29.05.2000Плакати
18Подготовка доклада29.05.2000-11.06.2000Доклад
19Предзащіта дипломного проекта12.06.2000
20Защіта дипломного проекта20.06.2000
1.3.6. Заплановані показники ефективності.
В результаті виконаної роботи передбачається досягти наступних ефектів:
зменшення часу, необхідного для обліку поставок вироблених на
підприємство;
автоматизація контролю поставок;
можливість тривалого зберігання інформації про постачання на підприємство
великого терміну давності, для можливості більш повного розрахунку ефективності
діяльності підприємства;
постійна повідомлено про терміни оплати здійснених поставок.
1.3.7. Порядок приймання результатів роботи.
Приймання результатів роботи здійснюється відповідно до плану приймання,
затвердженим на кафедрі і узгодженим з керівником практики. Цей план
включає наступні пункти:
Здача технічного завдання, технічної пропозиції, журналу з переддипломної
практиці і змісту розрахунково-пояснювальної записки після проходження
переддипломної практики.
Здача програми.
Предзащіта дипломного проекту. Надаються: розрахунково-пояснювальна записка,
плакати, доповідь, рецензія, відгук керівника.
Захист дипломного проекту. Надаються: дипломний проект з документами,
зауваження, допуск на захист, картка обліку деканату, демонстраційний зразок.
1.3.8. Документація, що пред'являється по закінченню роботи.
Після закінчення роботи надається наступна документація:
Технічне завдання;
Розрахунково-пояснювальна записка;
Опис застосування;
Керівництво системного програміста;
Керівництво оператора;
Також надаються:
Плакати;
Доповідь;
Рецензія;
Текст програми;
Дискета з програмним продуктом і супровідною документацією.
2. Моделювання.
2.1 Аналіз представлення моделей даних.
Для ефективного функціонування розробляється АСИС "Облік поставок" буде
розроблена СУБД [24]. Тому нижче розглянуті логічні та концептуальні
моделі даних.
2.2 Вибір логічної моделі даних.
2.2.1 Ієрархічна модель даних.
Ієрархічна модель [6] даних являє собою ієрархію у вигляді дерева.
Дана модель даних базується на сегменті, який являє собою
сукупність полів, що характеризують даний сегмент. Сегменти розрізняються за
типу, а кожен тип характеризується фіксованою довжиною і конкретним розбиванням
на поля даних. Два пов'язаних сегмента, розташованих на суміжних рівнях
називаються вихідним (більш високого рівня) і породженим (нижчого).
Ієрархічна запис - система взаємопов'язаних сегментів, в якій кожен
породжений сегмент представлений стільки разів, скільки необхідно для повного
розкриття даного сегмента. В ієрархічній структурі є сегмент, який не
має вихідного і називається головним чи кореневим. У цьому сегменті зазвичай
розташовується ідентифікатор об'єкта, властивості якого розкриваються в сегментах
другий і нижчих рівнів ієрархії.
Для реалізації цієї моделі на фізичному рівні використовується ряд стандартних
методів розміщення даних на запам'ятовуючих пристроях, які можуть розміщувати
сегменти наступними ієрархічними способами доступу: послідовний,
індексного-послідовний, прямий, індексного-прямій. У відповідності зі способами
розміщення сегментів встановлюється порядок доступу до них. Встановлений
порядок доступу до сегментів обумовлює процедурність мови запитів і вимагає
від користувача знання шляхів доступу до даних, які проходять по гілках дерева
ієрархічної запису. Що є одним з недоліків даної моделі. В
Як інші недоліків можна відзначити наступні:
Складність реалізації "багато до багатьох", що вимагає надлишковості даних на
фізичному рівні, що призведе до небажаного і не виправданого збільшення
БД;
вимога підвищеної коректності до операції видалення, оскільки видалення
вихідного сегмента тягне за собою видалення породжених;
доступ до будь-якого породженому сегменту можливий тільки через вихідний, що
збільшує час відповіді а запит до БД.
У зв'язку з тим, що ієрархічна модель має велику кількість недоліків
вона не буде застосовуватися для моделювання розробляється АСИС.
2.2.2 Мережева модель даних.
Мережа [5] - більш загальна структура в порівнянні з ієрархією. Вузлами мережі є
окремі екземпляри запису. Вузли записи є одиницею доступу до БД.
Оскільки окремий вузол може мати кілька безпосередньо старших вузлів,
так само, як і кілька безпосередньо підлеглих, то дана структура
забезпечує пряме подання відносини "багато до багатьох". Для зв'язку між
записами-вузлами існує связует запис, всі примірники якої містяться в
ланцюжок для зв'язку двох примірників.
Основний конструкцією мережної моделі даних є набір. Для кожного типу
набору, який визначається в схемі, повинен бути зазначений певний тип запису
власника набору, а так само довільне число типів запису членів набору. Кожен
екземпляр набору складається з одного примірника-власника і одного або більше
примірників записів-членів.
Кожен екземпляр запису-набору представляє ієрархічні зв'язки між
примірником запису-власника і відповідними примірниками записів-членів. Це
є наслідком того обмеження, що ні один примірник запису-члена з
набору на може належати більш, ніж одному примірнику набору. Спосіб,
яким кожен примірник запису власника зв'язується з відповідними
примірниками записів-членів, визначається у схемі мережі. Одним із способів
організації таких зв'язків є встановлення ланцюжка покажчиків, що виходять з
примірника запису-власника, що проходять через всі примірники записів-членів і
повертаються назад до примірника запису-власника, що забезпечує високу
швидкість обробки запитів.
Головний недолік мережевої моделі полягає в складності структур пам'яті.
Користувач повинен знати, які ланцюжка існують і які відсутні. В
результаті мова запитів процедурний і вимагає програмістських навичок.
2.2.3 Реляційна модель даних.
Реляційна модель - множинне ставлення яке являє собою
підмножина декартова твори списку доменів [27,20]. Домен - це
безліч значень, з якого здобуваються значення для даного атрибуту.
Іншими словами в основі реляційної моделі лежать прості таблиці, які
задовольняють певним обмеженням, а тому можуть розглядатися як
математичні відносини. Строки таких таблиць називаються кортежами, імена
стовпців - атрибутами. Слід зазначити, що всі кортежі різні, а порядок
стовпців довільний, ніж спрощується процес обробки кортежів. Відносно
(таблиці) виділяється декілька атрибутів, однозначно ідентифікують кортежі і
званих ключами.
Особливість реляційної моделі полягає в тому, що на відміну від мережевої і
ієрархічної моделей реальні об'єкти і взаємозв'язки між ними представляються в
базі даних однаково в вигляді нормалізованих відносин [24].
Основний недолік реляційної моделі даних зв'язується з низькою
продуктивністю реляційної СУБД. Але розробка сучасних СУБД таких як,
ORACLE, InterBase, Acsses та ін дозволило подолати і цей недолік.
Переваги реляційної моделі можна розділити на дві групи:
гідності для користувача:
реляційна БД являє собою набір таблиць з якими користувач звик
працювати;
не потрібно пам'ятати шляху доступу до даних і будувати алгоритми і процедури
обробки свого запиту;
реляційні мови легкі для вивчення і освоєння, в той час як мови спілкування
з ієрархічної і мережної моделями призначені для програмістів і мало
придатні для користувачів;
достоїнства обробки даних реляційної БД:
зв'язність. Реляційне подання дає ясну картину взаємозв'язків атрибутів
з різних відносин;
точність. Спрямовані зв'язку в реляційної БД відсутні. Відносини за своєю
природі мають більш точним змістом і піддаються маніпулювання з
використанням таких засобів, як алгебра та обчислення відносин [5],
забезпечують наочність і гнучкість моделі даних;
гнучкість. Операції проекції та об'єднання [17] дозволяють розрізати і склеювати
відносини, так що програміст може отримувати різноманітні файли в потрібній
формі;
секретність. Контроль секретності спрощується. Для кожного відносини є
можливість завдання правомірності доступу, засекречені показники можна
виділити в окремі відносини з перевіркою прав доступу.
Простота впровадження. Фізичне розміщення однорідних (табличних) файлів
набагато простіше, ніж розміщення ієрархічних і мережевих структур.
Незалежність даних. БД повинна допускати можливість розширення, тобто
додавання нових атрибутів і відносин.
Висновок: оскільки серед перерахованих логічних моделей даних реляційна
володіє значними перевагами і недоліками малими, то вона і буде
взята в основу для побудови СУБД.
2.3 Вибір концептуальної моделі.
Для вибору концептуальної моделі даних розглянемо три їх різновиди:
Семантична модель;
Фрейми;
Модель "сутність-зв'язок".
Семантична модель грунтується на побудові семантичної мережі. Під
семантичної мережею розуміють орієнтований граф, що складається з позначених
вершин і дуг і задає об'єкти і відносини предметної області. Семантичні
мережі мають ряд переваг, а саме:
Опис об'єктів предметної області відбувається природною мовою;
Усі записи, що надходять в БД накопичуються у відносно однорідної структурі.
Але незважаючи на ці переваги, семантична модель даних має ряд
недоліків, один з яких і найбільш істотний, полягає в тому, що
побудова реляційної моделі даних на основі семантичних мереж утруднено.
Фрейми виражаються структурами даних з прив'язаними процедурами обробки цих
даних. Фрейми можуть бути наступних видів: подієві, характеристики,
логічні предикати. Використання фреймової моделі так само недоцільно,
оскільки дана модель не відображає типи зв'язків [14] в реляційної моделі
даних.
Модель "сутність-зв'язок" описується в термінах сутність, зв'язок, значення.
Сутність - поняття яке може бути ідентифіковано. Зв'язок - підключення
сутностей. Для представлення зв'язків та сутностей введений спеціальний метод:
ER-Діаграми [27]. Розрізняються суті трьох основних класів: стрижневі,
асоціативні і характеристичні. Стрижнева сутність - це незалежна
сутність (їй властиво незалежне існування). Асоціативна сутність або
асоціація розглядається як зв'язок між двома або більше сутностями типу
"багато-ко-многим" або подібні до них. Характеристична сутність (або
характеристика) являє собою сутність, єдина мета якої, в рамках
розглянутої предметної області, полягає в описі чи уточнення деякої
інший сутності. ER-Діаграми - графічне відображення взаємозв'язків сутностей.
Кожне безліч сутностей представляється прямокутником, а безліч зв'язків -
ромбом. Зв'язки можуть бути трьох типів: "один до одного", "один до багатьох", "багато
до багатьох ". дані типи зв'язку властиві реляційної моделі, як і сутності,
яким в реляційної моделі відповідають таблиці.
Висновок: у зв'язку з тим, що модель "сутність-зв'язок" найбільш близька за принципами
організації до реляційної моделі та реалізація останньої на основі першого
найбільш зручна, то як концептуальної моделі обрана модель
"Сутність-зв'язок".
2.4 Процес моделювання.
2.4.1 Виділення сутностей.
Сутність "постачальник" є стрижневою сутністю розробляється моделі. З
постачальником укладається договір, на підставі якого ведеться вся інша
діяльність підприємстві з постачання, відправлення заявки постачальникам, отримання
від них рахунки-фактури, відправлення замовлення на поставку, отримання товару, оплата
поставки. Як ключ для даної суті вводиться атрибут № Постачальника.
Всі сутності, їх атрибути та ключі представлені в табл. 2.1.
Таблиця 2.1
Назва сущностіАтрібутКлюч
Договір № Договору, дата договору, сума договору, строк дії. № Договору
Постачальник № Постачальника, найменування постачальника, адреса, телефон. № Постачальника
Асортимент товарів № Товару, найменування товару. № Товару
Заявка № Заявки, асортимент заявки, номер договору, дата заявки. № Заявки
Замовлення № Замовлення, № Договору, асортимент замовлення, дата замовлення, номер рахунку.
№ Замовлення
Рахунок-фактура № Рахунку, асортимент рахунку, ціна за одиницю товару, сума
рахунку. № Рахунку
2.5 Побудова логічної моделі.
Виконавши аналіз сутностей і зв'язків меду ними побудуємо логічну модель, у вигляді
відносин (таблиця 2.2)
Таблиця 2.2
Назва сущностіАтрібутКлюч
Договір № Договору, дата договору, сума договору, строк дії. № Договору
Постачальник № Постачальника, найменування постачальника, адреса, телефон. № Постачальника
Асортимент товарів № Товару, найменування товару. № Товару
Заявка № Заявки, номер договору, дата заявки. № Заявки
Заявка № Заявки, № товару, кількість. № Заявки, № Товару
Асортимент заявки № Замовлення, № Договору, дата замовлення, номер рахунку. № Замовлення
Асортимент замовлення № Замовленняа, № Заявки, № товару. № Замовлення, № Заявки, № товару.
Рахунок-фактура № Рахунку, сума рахунку. № Рахунку
Ціни постачальника № Рахунку, № Заявки, № Товару. № Рахунку, № Заявки, № Товару.
Для побудови логічної моделі даних використовувалося case - засіб
[17] ER-Win, що дозволяє проектувати реляційні моделі даних як
на фізичному рівні (ER-Діаграми), так і на фізичному (проектування
таблиць БД).
Логічна модель даних представлена у вигляді ER-Діаграми на рис. 2.2.
Рис 2.2 ER-діаграма моделі даних АСИС "Облік поставок"
3. Проектування алгоритмів довідково-інформаційної системи обліку та контролю
поставок на підприємство.
Алгоритмізація в самому загальному вигляді може бути визначена як процес
спрямованої дії проектувальника (групи проектувальників), необхідний для
вироблення алгоритмів, достатніх для реалізації створюваного об'єкту (системи),
задовольняє заданим вимогам [19]. Завершальним етапом алгоритмізації
є випуск набору алгоритмів, що відображає рішення, прийняті
проектувальником, у формі, необхідної для виробництва об'єкта (системи). При
проектуванні системи я використовував три класи алгоритмів:
Алгоритми, пов'язані з проектуванням АСИС;
Алгоритми реляційної алгебри, необхідні для роботи з БД;
Алгоритми розрахунку необхідних показників (обчислення заборгованості підприємства
з оплати поставок, визначення оптимального рахунки-фактури).
3.1 Вибір методу проектування АСИС.
Метод - це послідовний процес створення моделей, які описують цілком
певними засобами різні сторони розробляється програмної системи
[18]. Методи важливі з кількох причин. По-перше, вони впорядковують процес
створення складних програмних систем. По-друге, вони дозволяють менеджерам в
процесі розробки оцінити ступінь просування і ризик.
Зазвичай методи проектування поділяються на три основні групи;
Метод проектування зверху вниз;
Метод потоків даних;
Об'єктно-орієнтоване проектування.
Для структурного проектування характерна алгоритмічна декомпозиція. Слід
відзначити, що більшість програм написано у відповідності з цим методом. Тим
не менш структурний підхід не дозволяє виділити абстракції і забезпечити
обмеження доступу до даних; він також не надає достатніх коштів для
організації паралелізму. Структурний метод не може забезпечити створення
гранично складних систем, і він, як правило, неефективний в об'єктних і
об'єктно-орієнтованих мов програмування. Тому даний метод не
використовувався для проектування АСИС "Облік поставок".
У методі потоків даних програмна система розглядається як перетворювач
вхідних потоків у вихідні. Метод потоків даних з успіхом застосовувався при
вирішенні ряду складних завдань, зокрема, у системах інформаційного
забезпечення, де існують прямі свя
