Затверджую
(дата)
Зав. кафедрою
(підпис)
ЗАВДАННЯ
по випускної роботи бакалавра комп'ютерних наук
Студент групи
Затверджене наказом по університету від
1. Тема проекту: Автоматизована довідково-інформаційна система обліку поставок на підприємстві
а) конструкторська частина проекту


Консультант
(підпис)
б) технологічна частина проекту


Консультант
(підпис)
в) економічна частина проекту


Консультант
(підпис)
г) забезпечення безпеки життєдіяльності Аналіз умов праці інженера-програміста
в лабораторії з розробки програмного забезпечення

Консультант
(підпис)
д) спецзавдання

Консультант
(підпис)
2. Термін здачі студентом закінченого проекту

3. Вихідні дані до проекту



4. Зміст розрахунково-пояснювальної записки (перелік підлягають розробці питань)


5. Перелік графічного матеріалу (з точним зазначенням обов'язкових креслень)


6. Дата видачі завдання
Керівник
(підпис)
Завдання прийняв до виконання
(дата, підпис)
ЗМІСТ
1. Стан проблеми обліку поставок на підприємство. 8
Введення 8
1.1 Загальна характеристика проблеми 11
1.2 Формулювання завдань 14
1.3 Мотивація завдань. 18
1.3. Технічне завдання. 19
Введення. 19
1.3.1. Підстави для розробки. 19
1.3.2. Призначення розробки. 19
1.3.3. Вихідні дані і джерела. 20
1.3.4. Вихідні вимоги до кінцевого результату. 21
1.3.5. Етапи проведення робіт. 23
1.3.6. Заплановані показники ефективності. 23
1.3.7. Порядок приймання результатів роботи. 24
1.3.8. Документація, що пред'являється по закінченню роботи. 24
2. Моделювання. 25
2.1 Аналіз представлення моделей даних. 26
2.2 Вибір логічної моделі даних. 26
2.2.1 Ієрархічна модель даних. 26
2.2.2 Мережева модель даних. 27
2.2.3 Реляційна модель даних. 28
2.3 Вибір концептуальної моделі. 30
2.4 Процес моделювання. 31
2.4.1 Виділення сутностей. 32
2.4.2. Виділення зв'язків між сутностями 32
2.5 Побудова логічної моделі. 33
3. Проектування алгоритмів довідково-інформаційної системи обліку і контролю постачань на підприємство. 36
3.1 Вибір методу проектування АСИС. 36
3.2. Аналіз алгоритмів роботи з базою даних 38
3.3. Проектування алгоритмів розрахунку заборгованості з оплати поставок і визначення оптимальної заявки. 43
4. Вибір засобів для розробки АСИС, опис структури АСИС. 47
4.1 Вибір апаратних засобів. 47
4.2. Аналіз та вибір програмних засобів розробки АСИС. 47
4.3. Опис загальної структури АСИС. 55
4.4. Опис програми. 57
4.4.1. Опис інтерфейсу. 57
4.4.2 Робота з режимами АСИС 58
5. Випробування програмного продукту. 63
5.1. Довідкові документи. 64
5.2. Короткий огляд верифікації. 65
5.3. Процеси верифікації. 66
5.3.1. Наскрізний контроль. 66
5.3.2. Трасування вимог до ПЗ та вимог користувача. 67
5.3.3. Тестування зовнішніх функцій. 67
5.3.4. Тестування модуля. 69
5.4.5. Комплексне тестування. 70
5.5. Висновки з тестування ПЗ. 72
6. Розробка бізнес-плану автоматизованої довідково-інформаційної системи "Облік поставок". 73
Резюме. 73
6.1. Опис автоматизованої довідково-інформаційної системи. 74
6.2 Маркетингові дослідження ринків збуту. 75
6.3 Оцінка якості та конкурентоспроможності продукту. 76
6.4 Визначення витрат на розробку АСИС "Облік поставок". 78
6.5 Стратегія маркетингу. 81
6.6 Оцінка ризику і страхування. 82
6.7 Фінансовий план. 82
7. Безпека життєдіяльності 85
7.1. Виявлення шкідливих і небезпечних факторів. 85
7.2. Заходи щодо захисту від шкідливих і небезпечних факторів. 88
Висновок. 91
Список використаної літератури. 92
Програми 94

Список використовуваних позначень.
АСИС - автоматизована довідково-інформаційна система;
БД - база даних;
ОЗП - оперативний запам'ятовуючий пристрій;
ПК - персональний комп'ютер;
ПЗ - програмне забезпечення;
ОП - оперативна пам'ять;
ВП - відеопам'ять;
ПП - програмний продукт;
ПЕОМ - персональна електронно-обчислювальна машина;
СУБД - система управління базами даних;
1. Стан проблеми обліку поставок на підприємство.
Введення
Господарство України являє собою сукупність підприємств і організацій окремих галузей народного господарства різних форм власності. Підприємства державної форми власності перебувають у віданні різних міністерств і відомств, а також у веденні місцевих виконкомів. Виробнича діяльність як і господарська, спрямовані на випуск предметів культурно-побутового призначення, господарського вжитку та ін
Таким чином, до складу господарства України входять підприємства і організації, як сфери матеріального виробництва, так і сфери обслуговування, як госпрозрахункові, так і перебувають на державному бюджеті. Найбільше число держбюджетних організацій знаходиться у веденні Міністерства освіти і науки України: школи, дитячі сади, педагогічні інститути, технікуми, училища і т.п. (близько 30% загальної кількості організацій); міністерства охорони здоров'я України - лікарні, санаторії, госпіталі та ін лікувальні установи (близько 20%); міністерства культури і освіти України - театри, бібліотеки, музеї та ін (більше 25% загальної кількості організацій ) [3].
Керівництво місцевим господарством країни організовано як за галузевим принципом (через відповідні міністерства та відомства), так і за територіальним (через місцеві органи управління).
Підприємства господарства України проводять різноманітну продукцію. В її числі можна знайти засоби виробництва: верстати, машини, металопродукцію, товари народного споживання, предмети побутової хімії тощо
Для виробництва всієї перерахованої вище продукції підприємства, незалежно від форм власності, для свого нормального і стабільного функціонування мають потребу в сировині, комплектуючих, запчастини і т.п. Іншими словами для організації своєї діяльності підприємства стикаються з проблемою своєчасного постачання продукції. Для цих цілей підприємства державної форми власності використовують постачальницькі організації (в даний час цими організаціями мають спеціалізовані державні підприємства), підприємства ж приватних форм власності проводять відповідні заходи, спрямовані на своєчасне та безперервне забезпечення необхідною сировиною або матеріалами. Але в даний час практично всі підприємства будь-якої форми власності самостійно займаються пошуком підприємств-постачальників, а також у міру необхідності організацією поставок.
Одним з показників що характеризують роботу підприємства є товарооборот, який являє собою планово організаційний процес обігу засобів виробництва [2], від якого багато в чому залежать і інші економічні показники. До загального обсягу товарообігу включають всі товари, реалізовані підприємством, тобто отримані від підприємств постачальників продукції. Також товарообіг показує наскільки швидко підприємство використовує отриману продукцію, тобто якими темпами воно здійснює свою діяльність, чим більше на підприємство здійснюється постачання, тим більш стабільно працює дане підприємство.
При здійсненні поставок на підприємство проводиться обробка та зберігання великої кількості інформації, пов'язаної з поставками, яка в себе включає:
своєчасне і правильне оформлення документів та контроль за кожною операцією надходження товарів від постачальників, з переробки та інших джерел, виявлення розбіжності фактичної наявності та кількості, зазначеної в супровідних документах;
контроль за своєчасним, повним і правильним оприбуткуванням надійшли товарів;
своєчасне і правильне оформлення документації та контроль за кожною операцією відпустки, відвантаження або реалізації товару;
контроль за дотриманням нормативів запасу товарів.
У зв'язку з цим для надійного функціонування системи постачань необхідно вести їх систематичний і безперервний облік, що і буде виконувати розробляється ПЗ.
Розробляється програмний продукт буде відрізнятися від аналогічного програмного забезпечення можливістю застосування на сучасній електронно-обчислювальної техніки [1], зручний інтерфейс, низькою вартістю, можливістю його використання на будь-якому підприємстві.
1.1 Загальна характеристика проблеми
При здійсненні поставок підприємства виробники продукції виробничо-технічного призначення вступають у договірні відносини з підприємствами споживачами (покупцями) як постачальники укладають прямі договори з підприємствами споживачами для збуту продукції та комплексного постачання підприємств-замовників.
Договори про постачання необхідно укладати своєчасно. У них зазначаються умови поставки товарів, їх кількість, асортимент, якість, комплектність і терміни поставки. Крім того, у договорах передбачено ціни на товари, загальна сума, порядок розрахунків, платіжні та відвантажувальні реквізити постачальника і одержувача продукції. Договору підлягають обов'язковому виконанню за всіма зазначеними в них пунктам. Порушення строків договорів та зобов'язань тягне за собою відповідальність, передбачену "Положенням про поставку продукції виробничо-технічного призначення" і "Особливими умовами поставки."
Контроль за виконанням договорів здійснюють товарні відділи.
Раціональна організація приймання продукції від постачальників має важливе значення для своєчасного, повного, комплексного постачання підприємств сировиною, матеріалами, паливом, інструментами, устаткуванням та іншими засобами виробництва.
Правильна приймання та оформлення документами, що надійшли товарів
Чи є надійною основою збереження товарно-матеріальних цінностей.
Загальний порядок приймання товарно-матеріальних цінностей встановлено "Положенням про поставку продукції виробничо-технічного призначення". Порядок і терміни приймання товарно-матеріальних цінностей в певній кількості і якості, оформлення актів приймання і пред'явлення претензій визначені інструкцією про порядок приймання продукції виробничо-технічного призначення і товарів народного споживання за кількістю та інструкцією про порядок приймання продукції виробничо-технічного призначення за якістю. Особливості приймання окремих видів продукції визначаються в ГОСТах [12.01.005-89], технічних умовах, Особливих умов поставки і договорах поставки, що передбачають особливі порядки приймання продукції при поставках.
На підприємствах державної форми власності здійсненням всіх дій пов'язаних з поставками і оформленням необхідних документів, за наявності відповідного програмного забезпечення, займається певну кількість персоналу підприємства, але, як правило, розробка такого програмного забезпечення велася на мовах низького рівня програмування, а за останні 6-8 років розвиток машинних засобів (ПЕОМ), програмних засобів різко збільшилася, тому раніше розроблене ПЗ не відповідає більш високим вимогам, що пред'являються до сучасних програмних продуктів. Що ж стосується підприємств, фірм різний форм приватної власності, то вони часто не мають зовсім відповідного програмного забезпечення, що значно збільшує трудомісткість процесу контролю та обліку проведення поставок. Розробляється програмний продукт і покликаний вирішувати дані проблеми.

1.2 Формулювання завдань
Будь-яке підприємство, здійснюючи свою діяльність, для одержання продукції від постачальників має укласти з останніми договір на поставку продукції. Зазвичай на однойменну продукцію підприємство-замовник укладає кілька договорів з підприємствами-постачальниками. Потім замовник по мірі потреби у певної продукції висилає постачальнику заявку на поставку продукції і отримує від останнього рахунок-фактуру, у якому зазначено найменування продукції та її відпускна ціна. На підставі цих рахунків підприємство-замовник визначає оптимальну заявку і надсилає постачальнику замовлення на постачання продукції. Після отримання замовленої продукції замовник відправляє рахунок в бухгалтерію, що оплачує його в банку протягом терміну, передбаченого договором. Тому для документального забезпечення процесу постачання на підприємство програма повинна створювати (роздруковувати) такі необхідні документи:
- Бланк договору підприємства-замовника з фірмою-постачальником (із зазначенням найменування та юридичних адрес сторін, асортименту продукції для поставок, її кількості і ймовірної вартості, а також умови та терміни дії договору);
- Замовлення на поставку необхідної продукції (вказується кількість, найменування, номенклатура, терміни поставки).
Також створюється автоматизована система за наявними даними про постачальників і знову з отриманими даними повинна визначати оптимальний рахунок-фактуру з точки зору кількість-ціна.
Будь-яку постачання підприємство-замовник зобов'язаний сплатити у встановлені договором строки, тому АС повинна здійснювати підрахунок суми боргу (грошей для виплати) на поточну дату.
На рис 1.1 представлена функціональна схема здійснення поставок на підприємство.









Таким чином для розробки АСИС необхідно виконати наступні завдання:
* Реалізація управління доступом до АСИС;
* Створити СУБД для роботи АСИС;
* Розробити довідкову інформацію по АСИС;
* Виконати аналіз і урахування поставок.
1.3 Мотивація завдань.
Підприємство або фірма, виробляючи свою продукцію, потребує постачання сировини від інших підприємств. Але на одне і теж сировину у різних виробників-постачальників різна відпускна ціна, тому з метою зниження собівартості продукції, що випускається підприємство замовник укладає договори з великою кількістю постачальників і потім висилає постачальникам заявку на постачання продукції із зазначенням типу та її кількості. Оскільки підприємство-замовник при отриманні вантажів так чи інакше пов'язане з документами, з документальним оформленням постачань, то проектована АСИС повинна створювати всі бланки документів, пов'язаних з поставками.
Оскільки всі постачальники висилають замовнику рахунки-фактури (прейскурант цін на замовлену продукцію), то серед їх безлічі необхідно визначити найбільш вигідну для підприємства-замовника, як за ціною, так і за якістю, що і повинна виконувати створювана АС.
Оскільки договори з постачальниками укладаються на певний строк, передбачувана кількість продукції, що постачається і на певну суму, то під час здійснення замовлення на постачання продукції, в договорі обумовлюється термін, протягом якого замовлення повинен бути сплачений, тому необхідно знати суму до оплати на вказане число, як загальну так і по різних постачальникам окремо.
Так як всі перераховані вище дії здійснюються впродовж тривалого часу, то при прийнятті рішення про продовження терміну дії договору доцільно брати до уваги такі чинники: якість поставок конкретними постачальниками (мається на увазі виконання термінів здійснення поставок, відповідність номенклатури поставленої продукції замовленої, відсутність або відсоток браку) , його терпимість по відношенню до оплати за постачання. Тому необхідно зберігати всю інформацію про постачання на підприємство, що б надалі її можна було б використовувати.
1.3. Технічне завдання.
Введення.
Автоматизована довідково-інформаційна система (АСИС) "Облік поставок" буде використовуватися на підприємствах різних форм власності і забезпечувати контроль та облік поставок вироблених на підприємство. Також при використанні даного ПЗ буде матися можливість складання звітності про постачання на підприємство, виявлення заборгованості з оплати поставок. Розробляється за може бути використано як керівником підприємства, для здійснення контролю вироблених поставок на підприємство, так і начальниками цехів, для ведення обліку поставок.
1.3.1. Підстави для розробки.
Підставою для виконання роботи є наказ про базу переддипломної практики від 10 червня 1999 р. № 270 за Державним аерокосмічного університету та наказ про дипломному проектуванні від 26 червня 2000 р. № 271.
1.3.2. Призначення раз?? аботкі.
Метою дипломного проектування є розробка та створення програмного продукту "Облік поставок". Даний програмне забезпечення призначене для контролю, обліку, автоматизації та систематизації інформації про постачання різного виду продукції на підприємство будь-якої форми власності, які займаються будь-яким видом виробництва або діяльності.
Розробляється програмний продукт повинен забезпечувати створення інформаційної бази про здійснені поставки на підприємство, а також здійснювати створення таких документів:
* Бланк договору підприємства замовника з фірмою-постачальником (із зазначенням найменування та юридичних адрес сторін, що беруть участь в договорі, асортименту продукції для поставок, її кількості, можливої вартості, умови та терміни дії договору);
* Заявку на поставку необхідної продукції (вказується кількість, найменування, номенклатура, терміни поставки, сума поставки);
* Замовлення на поставку.
Комерційна версія програмного продукту дозволить проводити:
* Більш повний контроль та організацію обліку про постачання на підприємство;
* Автоматизувати процес оформлення поставок на підприємство;
* Зменшить тимчасові витрати на оформлення документів, пов'язаних з поставками;
* Обчислювати заборгованість з оплати здійснених поставок на зазначений період;
* Забезпечити користувача системою допомоги як за поняттями предметної області, так і з користування програмним продуктом.
Розробляється автоматизована система повинна буде реалізувати наступні функції:
1. Забезпечення введення даних про постачання на підприємство;
2. Аналіз введеної інформації;
3. Підрахунок заборгованості підприємства за здійснені поставки;
4. Визначати оптимальний рахунок-фактуру з точки зору "кількість-ціна";
5. Виробляє друк документації, пов'язаної з організацією поставок (бланк договору, замовлення, заявки).
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 та ін дозволило подолати і цей недолік.
Переваги реляційної моделі можна розділити на дві групи:
1) переваги для користувача:
* Реляційна БД являє собою набір таблиць з якими користувач звик працювати;
* Не потрібно пам'ятати шляху доступу до даних і будувати алгоритми і процедури обробки свого запиту;
* Реляційні мови легкі для вивчення і освоєння, в той час як мови спілкування з ієрархічної і мережної моделями призначені для програмістів і мало придатні для користувачів;
2) достоїнства обробки даних реляційної БД:
* Зв'язність. Реляційне подання дає ясну картину взаємозв'язків атрибутів з різних відносин;
* Точність. Спрямовані зв'язку в реляційної БД відсутні. Відносини за своєю природою мають більш точним змістом і піддаються маніпулювання з використанням таких засобів, як алгебра та обчислення відносин [5], що забезпечують наочність і гнучкість моделі даних;
* Гнучкість. Операції проекції та об'єднання [17] дозволяють розрізати і склеювати відносини, так що програміст може отримувати різноманітні файли в потрібній формі;
* Секретність. Контроль секретності спрощується. Для кожного відносини є можливість завдання правомірності доступу, засекречені показники можна виділити в окремі відносини з перевіркою прав доступу.
* Простота впровадження. Фізичне розміщення однорідних (табличних) файлів набагато простіше, ніж розміщення ієрархічних і мережевих структур.
* Незалежність даних. БД повинна допускати можливість розширення, тобто додавання нових атрибутів і відносин.
Висновок: оскільки серед перерахованих логічних моделей даних реляційна володіє значними перевагами і недоліками малими, то вона і буде взята в основу для побудови СУБД.
2.3 Вибір концептуальної моделі.
Для вибору концептуальної моделі даних розглянемо три їх різновиди:
* Семантична модель;
* Фрейми;
* Модель "сутність-зв'язок".
Семантична модель грунтується на побудові семантичної мережі. Під семантичною мережею розуміють орієнтований граф, що складається з позначених вершин і дуг і задає об'єкти і відносини предметної області. Семантичні мережі мають ряд переваг, а саме:
* Опис об'єктів предметної області відбувається природною мовою;
* Усі записи, що надходять в БД накопичуються у відносно однорідної структурі.
Але незважаючи на ці переваги, семантична модель даних має ряд недоліків, один з яких і найбільш істотний, полягає в тому, що побудова реляційної моделі даних на основі семантичних мереж утруднено.
Фрейми виражаються структурами даних з прив'язаними процедурами обробки цих даних. Фрейми можуть бути наступних видів: подієві, характерістікі, логічні предикати. Використання фреймової моделі так само недоцільно, оскільки дана модель не відображає типи зв'язків [14] в реляційної моделі даних.
Модель "сутність-зв'язок" описується в термінах сутність, зв'язок, значення. Сутність - поняття яке може бути ідентифіковано. Зв'язок - підключення сутностей. Для представлення зв'язків та сутностей введений спеціальний метод: ER-Діаграми [27]. Розрізняються суті трьох основних класів: стрижневі, асоціативні і характеристичні. Стрижнева сутність - це незалежна сутність (їй властиво незалежне існування). Асоціативна сутність або асоціація розглядається як зв'язок між двома або більше сутностями типу "багато-ко-многим" або подібні до них. Характеристична сутність (або характеристика) являє собою сутність, єдина мета якої, в рамках розглянутої предметної області, полягає в описі чи уточнення деякої іншої сутності. ER-Діаграми - графічне відображення взаємозв'язків сутностей. Кожне безліч сутностей представляється прямокутником, а безліч зв'язків - ромбом. Зв'язки можуть бути трьох типів: "один до одного", "один до багатьох", "багато до багатьох". дані типи зв'язку властиві реляційної моделі, як і сутності, яким у реляційної моделі відповідають таблиці.
Висновок: у зв'язку з тим, що модель "сутність-зв'язок" найбільш близька за принципами організації до реляційної моделі та реалізація останньої на основі перших найбільш зручна, то як концептуальної моделі обрана модель "сутність-зв'язок".
2.4 Процес моделювання.
2.4.1 Виділення сутностей.
Сутність "постачальник" є стрижневою сутністю розробляється моделі. З постачальником укладається договір, на підставі якого ведеться вся інша діяльність підприємстві з постачання, відправлення заявки постачальникам, отримання від них рахунки-фактури, відправлення замовлення на поставку, отримання товару, оплата поставки. Як ключ для даної суті вводиться атрибут № Постачальника.
Всі сутності, їх атрибути та ключі представлені в табл. 2.1.
Таблиця 2.1
Назва суті
Атрибут
Ключ
Договір
№ Договору, дата договору, сума договору, строк дії.
№ Договору
Постачальник
№ Постачальника, найменування постачальника, адреса, телефон.
№ Постачальника
Асортимент товарів
№ Товару, найменування товару.
№ Товару
Заявка
№ Заявки, асортимент заявки, номер договору, дата заявки.
№ Заявки
Замовлення
№ Замовлення, № Договору, асортимент замовлення, дата замовлення, номер рахунку.
№ Замовлення
Рахунок-фактура
№ Рахунку, асортимент рахунку, ціна за одиницю товару, сума рахунку.
№ Рахунку

2.4.2. Виділення зв'язків між сутностями
Виділення зв'язків між сутностями здійснюється на підставі аналізу предметної області. Всі виділені зв'язку представлені на Рис.2.1














Рис 2.1. Зв'язок між сутностями
2.5 Побудова логічної моделі.
Виконавши аналіз сутностей і зв'язків меду ними побудуємо