ПВНЗ Європейський університет

Стр 1 из 4Следующая ⇒

ПВНЗ Європейський університет

Конотопська філія

МЕТОДИЧНІ ВКАЗІВКИ

Про виконання практичного завдання

За курсом

ПРОЕКТУВАННЯ ІНФОРМАЦІЙНИХ СИСТЕМ

БІЛОУС С.О.

КОНОТОП

Р.

Вступ

При проектуванні програм з'ясовуються вимоги і побажання клієнта і визначається можливий підхід до рішення задачі. Задача аналізується. На основі цього аналізу реалізується конкретна модель у конкретному програмному середовищі. Результати кожного етапу проектування використовуються як вихідний матеріал наступного етапу.

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

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

Попереднє планування, підготовка даних, послідовність створення інформаційної моделі.

При проектуванні системи обробки даних більше всього нас цікавить організація даних. Допомогти зрозуміти організацію даних покликана інформаційна модель.

Процес створення інформаційної моделі починається з визначення концептуальних вимог ряду користувачів. Концептуальні вимоги можуть визначатися і для деяких задач (додатків), що найближчим часом реалізовувати не планується. Це може трохи підвищити трудомісткість роботи, однак допоможе найбільше повно врахувати всі нюанси функціональності, необхідної для розроблювальної системи, і знизить імовірність переробки надалі. Вимоги окремих користувачів повинні бути представлені в єдиному «узагальненому представленні». Останнє називають концептуальною моделлю.

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

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

• Клас - це безліч предметів реального світу, зв'язаних спільністю структури і поводженням.

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

Проектування концептуальної моделі бази даних: Аналіз даних: збір основних даних (наприклад, об'єкти, зв'язки між об'єктами).

Визначимо первісні дані:

Заявки – які поступають від магазинів на визначений період.

Договори - заключені з постачальниками на визначений вид товару.

Постачальники - організації чи фізичні особи, з якими заключені договори на постачання товару.

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

Рахунки - ведуться на етапі заключення договорів з постачальниками, а також із замовниками.

Накладні - створюються на підставі одержання замовлення від замовника, для відвантаження.

Довідки - одержання/видача різних довідок, як замовнику так і постачальнику.

Товар - є присутнім на підставі заявки і договору з постачальником.

Визначення взаємозв'язків.

Взаємозв'язок виражає відображення чи зв'язок між двома безлічами даних. Розрізняють взаємозв'язки типу «один до одного», «один до багатьох» і «багато до багатьох».

Наприклад, якщо замовник робить замовлення на покупку товару вперше, здійснюється первинна реєстрація його даних і зведень про зроблене замовлення. Якщо ж замовник робить замовлення повторно, здійснюється реєстрація тільки даного замовлення. Поза залежністю від того, скільки разів даний замовник робив замовлення, він має унікальний ідентифікаційний номер (унікальний ключ замовлення). Інформація про кожного замовника включає найменування замовника, адресу, телефон, факс, прізвище, ім'я, по батькові, ознаку юридичної особи і примітку. Таким чином, властивостями об'єкта Замовник є «унікальний ключ замовника», «найменування замовника».

Наступний інтерес, що представляє для нас, об'єкт — Товар. Цей об'єкт має властивості «унікальний ключ товару», «найменування товару».

Другий розглянутий об'єкт — Постачальник. Його властивостями є «унікальний ключ постачальника», «найменування постачальника».

Третій розглянутий об'єкт — Замовник. Його властивостями є «унікальний ключ замовника», «найменування замовника».

Взаємозв'язок «один до одного» (між двома типами об'єктів) Допустимо, у визначений момент часу один замовник може зробити тільки одне замовлення. У цьому випадку між об'єктами Замовник і Товар установлюється взаємозв'язок «один до одного».

Взаємозв'язок «один до багатьох» (між двома типами об'єктів).

У визначений момент часу один замовник може стати власником декількох товарів, при цьому декілька замовників не можуть бути власниками одного товару (на умові якщо замовник не претендує на частину товару). Взаємозв'язок «один до багатьох» можна позначити за допомогою одинарної стрілки в напрямку до «одного» і подвійної стрілки в напрямку до «багатьох» .У цьому випадку одного запису даних першого об'єкта (його часто називають батьківським чи основними) буде відповідати кілька записів другого об'єкта (дочірнього чи підлеглого). Взаємозв'язок «один до багатьох» дуже поширений при розробці реляційних баз даних. Як батьківський об'єкт часто виступає довідник, а в дочірньому зберігаються унікальні ключі для доступу до записів довідника. У нашому прикладі як такий довідник можна представити об'єкт Замовник, у якому зберігаються зведення про всіх замовників. При звертанні до запису для визначеного замовника нам доступний список усіх покупок, що він зробив, і зведення про які зберігаються в об'єкті Товар.

Взаємозв'язок «один до одного» (між двома властивостями)

Ми припускаємо, що ключ (номер) магазина є його унікальним ідентифікатором, тобто він не змінюється і при наступних надходженнях замовлень від даного магазина. Якщо поряд з номером магазина в базі даних зберігається й інший його унікальний ідентифікатор (наприклад, адреса), то між такими двома унікальними ідентифікаторами існує взаємозв'язок «один до одного».

Взаємозв'язок «один до багатьох» (між двома властивостями).

Ім'я постачальника і його номер існують спільно. Постачальників з однаковими іменами може бути багато, але усі вони мають різні номери. Кожному постачальнику привласнюється унікальний номер. Це означає, що даному номеру постачальника відповідає тільки одне ім'я. Взаємозв'язок «один до багатьох» позначається одинарною стрілкою в напрямку до «одного» і подвійною стрілкою в напрямку до «багатьох».

Початкова схема даних

Визначення об'єктів Виділимо наступні об'єкти:

1. ТОВАР - (Т);

2. ЗАМОВНИК - (З);

3. ПОСТАЧАЛЬНИК - (П);

4. РАХУНКИ - (Р);

5. ДОГОВІР -(Д);

6. НАКЛАДНІ - (Н).

Таблиця 3. Проект таблиці для фізичної моделі.

№ п/п	Найменування поля	Примітка
ТОВАР
1.	Key tovar	Унікальний ключ товару
2.	Key postav	Унікальний ключ постачальника
3.	Key zakaz	Унікальний ключ замовника
4.	Name tovar	Найменування товару
5.	Date	Дата виготовлення
6.	Матка	Акцизна марка
7.	Kod	Розшифровка штрих-коду
8.	Srok god	Термін придатності
9.	Ves Ь	Вага Брутто
10.	Ves n	Вага Нетто
11.	Cena 1	Ціна за одиницю
12.	Cena	Сумарна ціна
13.	Upakovka	Вид упакування
ЗАМОВНИК
1.	Key zakaz	Унікальний ключ замовника
2.	Name zakaz	Найменування замовника
3.	Yrid zakaz	Юридична приналежність
4.	FIO zakaz	ПІБ керівника
5.	Adres zakaz	Адреса
6.	Tel zakaz	Телефон/факс
7.	Cena z	Передбачувана ціна
8.	Number N	Номер накладної
9.	Oplata	Позначка про оплату
10.	Date N	Дата накладної
ПОСТАЧАЛЬНИК
1.	Key jioctav	Унікальний ключ постачальника
2.	Name postav	Найменування постачальника
3.	Yrid poctav	Юридична приналежність
4.	FIO postav	ПІБ керівника
5.	Adres postav	Адреса
6.	Tel_postav	Телефон/факс
7.	Number D	Номер договору
8	Date Z	Дата заключення
РАХУНОК
1.	Number S	Номер рахунка
2.	Date P	Дата продажу
3.	Key tovar	Унікальний ключ товару
4.	NDS	ПДВ
5.	Summa	Сума до оплати