50346 (Інформаційна система на допомогу консультанту з продажу побутової техніки), страница 3

• даталогічний етап;

• етап тестування і супроводу.

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

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

Всяка прикладна програма є відображенням якоїсь частини реального світу і тому містить його формалізований опис у виді даних. Великі масиви даних розміщають, як правило, окремо від коду програми, що виконується, і організують у виді бази даних. Починаючи з 60-х років для роботи з даними стали використовувати особливі програмні комплекси, названі системами керування базами даних (СУБД). Системи керування базами даних відповідають за:

• фізичне розміщення даних і їхніх описів;

• пошук даних;

• підтримка баз даних в актуальному стані;

• захист даних від некоректних відновлень і несанкціонованого доступу;

• обслуговування одночасних запитів до даних від декількох користувачів (прикладних програм).

З розвитком комп'ютерної техніки зросла складність інформаційних систем і обсяги баз даних^[11]. У даний час розробка таких систем – це задача для колективів розроблювачів, що вимагає спеціальних методик і інструментів. Розробку інформаційних систем прийнято розбивати на наступні етапи:

• етап аналізу предметної області (зовнішній рівень проектування);

• етап проектування (інфологічний рівень проектування);

• даталогічний етап;

• етап тестування і супроводу.

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

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

Зовнішній рівень проектування

На зовнішньому рівні проектування перш за все потрібно вивчити функціонування об’єкта управління і визначитись, які саме дані доцільно зберігати в базі. Результатом такого проектування є перелік задач, що мають розв’язуватись системою, та перелік атрибутів, що мають зберігатись в БД для успішної автоматизації поставлених задач^[2].

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

Існує два підходи для проектування на цьому рівні:

– від запиту;

– від предметної області.

При проектуванні від запиту вивчають всі потреби користувачів та створюють відповідну систему. Таке проектування здійснюється швидко і не потребує значних затрат. Але при зміні потреб користувачів доводиться змінювати систему.

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

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

Інфологічний рівень проектування

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

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

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

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

Домен – це потенційна безліч значень простого типу даних, вона має подібність з підтипом даних у деяких мовах програмування. Домен визначається двома елементами – типом даних і логічним вираженням, що застосовується до даних. Якщо результат цього вираження дорівнює значенню «істина», то екземпляр даних належить домену^[9].

Відношення – це двовимірна таблиця особливого виду, що складається з заголовка і тіла.

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

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

• відношення – таблиця;

• атрибут – стовпчик або поле;

• кортеж – запис або рядок.

Таким чином, ступінь відношення – це число колонок у таблиці, а кардинальне число – кількість рядків.

Для даного відношення завжди існує набір атрибутів, що однозначно ідентифікують кортеж. Такий набір атрибутів називається ключем.

Ключ повинний задовольняти наступним вимогам:

• повинний бути унікальним;

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

На практиці як первинний ключ часто застосовують спеціальний числовий атрибут – автоінкрементне поле, значення якого може генеруватися тригером або спеціальними засобами, визначеними в механізмі СУБД.

Засновник реляційного підходу Дейт установив, що реляційна модель складається з трьох частин:

• структурної;

• маніпуляційної;

• цілісної.

У структурній частині моделі фіксуються відношення, як єдина структура даних, використовувана в реляційної моделі

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

Під цілісною частиною розуміють якийсь механізм забезпечення цілісності даних. Цілісна частина укладає в собі дві основних вимоги цілісності реляційних баз даних – цілісність сутностей і цілісність по посиланнях^[4].

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

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

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

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

• Найменування товару. Служить первинним ключем, по якому можна дістати доступ до будь-якого рядка таблиці. Тип даних – строковий (Character), довжина – 20 символів. Ширина поля – 20 символів. Можливі значення – назви товарів, що мають відношення до офісу.

• Ціна одиниці товару. Зберігає ціну певного виду товарів. Тип даних – грошовий (Currency) точністю до 2 знаків після коми. Ширина поля – 7 символів. Можливі значення обмежені шириною поля.

• Кількість одиниць товару. Зберігає число одиниць товару, що знаходяться в даний момент на складі. Тип даних – цілий (Integer). Ширина поля – 4 символи. Можливі значення обмежені шириною поля.

• Одиниця вимірювання. Зберігає назву одиниці вимірювання товару. Тип даних – строковий (Character), довжина – 15 символів. Ширина поля – 15 символів. Можливі значення – відповідно до першого поля таблиці.

• Дата надходження. Зберігає число, місяць і рік надходження товару. Тип даних – вираз дати (Date). Ширина поля – 8 символів. Можливі значення записуються у форматі: мм/дд/гггг, де мм – номер місяця (01..12), дд – день (01..31), гггг – номер року.

• Фірмавиробник. Зберігає назву фірми виробника товару. Тип даних – строковий (Character), довжина – 20 символів. Ширина поля – 20 символів. Можливі значення – різні’.

• Постачальник. Зберігає номер партії завозу товару. Тип даних – строковий (Character), довжина – 11 символів. Ширина поля – 11 символів. Можливі значення не обмежені.

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

• забезпечення швидкого доступу до даних в таблицях

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

• забезпечення цілісність даних таким чином, щоб при зміні одних об’єктів автоматично відбувалися відповідні зміни в зв’язаних з ними об’єктами

Процес зменшення надлишковості інформації в базі даних називається нормалізацією. В теорії нормалізації баз даних розроблені досить формалізовані підходи до розбиття даних, які володіють складною структурою.

Теорія нормалізації оперує з п’ятьма нормальними формами таблиць. Ці форми призначені для зменшення надлишкової інформації від першої до п’ятої нормальної форми. Тому кожна наступна форма повинна задовольняти умовам попередньої і деяким додатковим умовам. При практичному проектуванні баз даних четверта і п’ята форми зазвичай не використовуються.

Перша нормальна форма таблиці

Таблиця в першій нормальній формі повинна задовольняти такі умови:

• Таблиця не повинна мати записи що повторюються

• В таблиці повинні бути відсутніми групи полів що повторюються

• Рядки повинні бути невпорядковані

• Стовпчики повинні бути не впорядковані

Для задоволення умови 1 кожна таблиця повинна мати унікальний індекс. Умова 2 поступає видалення груп що повторюються.

Друга нормальна форма таблиці

Про таблицю кажуть що вона знаходиться в другій нормальній формі, якщо:

• Вона задовольняє вимогам першої нормальної форми

• Любе не ключове поле однозначно ідентифікується повним набором ключових полів

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

Третя нормальна форма таблиці

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

Жодне з не ключових полів таблиці не ідентифікується з допомогою іншого не ключового поля.

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

Структура бази містить 12 інформаційних об’єктів різних типів, що дає можливість відображати повну інформацію як про саму службу, так і про продукцію, яка реалізується.

Коди продукції та міститимуться в полі серійнийном в таблицях замовників та продукції;

Назва товару, що реалізується міститиметься в полі Товар, а ціна одиниці даного продукту (в гривнях) в полі ціна;

Назва підприємства чи установи, що виробляє продукцію міститься в полі Виробник таблиці замовників;

Кількість замовленої продукції(штук) відображена в полі кількпродаж;

Вище описані дані зручно вводяться та редагуються у відповідних формах. Крім того користувач може переглянути вже введені дані в загальному вигляді.

Середовище Microsoft Visual FoxPro 8.0 дає програмісту можливість виконувати поставлені завдання як самостійно, так і за допомогою великої кількості «помічників».

3.2 Створення таблиць

Дані в майбутню базу завантажуватимуться з 2 основних таблиць (Table1.dbf, Table2.dbf). Розглянемо структуру кожної з них.

Структура таблиці Table1.dbf

Як видно з структура таблиці Table1.dbf має вигляд:

Структура таблиці Table2.dbf