Реферат: Інформаційна система на допомогу консультанту з продажу побутової техніки

--PAGE_BREAK--2. Опис предметної області 2.1Постановка задачі


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

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

Крім того, для діалогу користувача із системою необхідно створити так називане, «Меню».

Предмет складання бази даних – облік замовлень кур’єрської служби. Складемо концептуальну модель представлення реальності в базі даних. Згідно умові, єдиною об'єктною множиною є об'єктна множина «друкована продукція». Кожний з цих об'єктів володіє однаковим по структурі безліччю атрибутів (ознак). Кожний з атрибутів характеризує конкретний об'єкт з якої-небудь сторони: кількість, якість, ціна і т.д.

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

База даних побутова техніка міститиме такі дані про:

ü      Назву продукції, що реалізується;

ü      Код продукції;

ü      Ціну (за одиницю продукції);

ü      Ідентифікаційний номер продукції;

ü      Кількість замовленої продукції;

ü      Сплачену загальну ціну;

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


При виборі програмного середовища я орієнтувався на такі три причини:

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

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

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

Саме тому я і вибрав середовище Microsoft FoxPro.

3. Опис створення програми3.1 Проектування баз даних


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

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

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

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

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

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

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

Всяка прикладна програма є відображенням якоїсь частини реального світу і тому містить його формалізований опис у виді даних. Великі масиви даних розміщають, як правило, окремо від коду програми, що виконується, і організують у виді бази даних. Починаючи з 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 основних таблиць (Table
1.dbf,
Table
2.dbf). Розглянемо структуру кожної з них.

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

<img width=«378» height=«330» src=«ref-1_1635218213-25993.coolpic» v:shapes="_x0000_i1025">
Як видно з структура таблиці Table
1
.dbf має вигляд:






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


<img width=«335» height=«293» src=«ref-1_1635244206-21317.coolpic» v:shapes="_x0000_i1026">
Як видно з структура таблиці Table
2
.dbf має вигляд:





У Visual FoxPro7.0. вся інформація зберігається в базі даних, що складається з таблиць, відносин між таблицями, індексів, тригерів і збережених процедур. Кожна таблиця має унікальне ім'я і зберігається в окремому файлі, найменування якого збігається з ім'ям таблиці. Створений файл має розширення DBF.

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

Для збереження значень полів типу Memo і General застосовуються окремі файли. Memo-полю чи таблиць містять текстову інформацію, а полючи типу General використовуються, як правило, для збереження двійкової інформації і даних інших додатків, що працюють у середовищі Windows.

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

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

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

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

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

Запити є засобом вибірки даних з однієї або декількох таблиць. У Visual FoxPro для створення запиту ви можете використовувати як конструктор запитів, так і спеціалізована мова Structured Query Language (SQL). Результати виконання запиту можуть відображатися у формі, виводитися у виді звітів і діаграм або зберігатися в зазначеній вами таблиці.

Програми, написані мовою Visual FoxPro, є об’єктно-орієнтованими. За допомогою них ви обробляєте події у формі, створюєте об'єкти, здійснюєте різні обчислення, керуєте базою даних. Для зручності роботи ви можете об'єднати програми в бібліотеки.

Для створення форм у Visual FoxPro можна використовувати не тільки базові класи, але і створювати власні. Наприклад, ви можете визначити клас форм, у якому заданий визначений колір тла і стандартний набір кнопок для керування даними. Щоб стандартизувати розробку, корисно мати один або кілька користувацьких класів для кожного базового класу. Класи, створені в Visual FoxPro, зберігаються в бібліотеках класів.

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

Кожен компонент зберігається в окремому файлі, причому імена файлів, що містять основні компоненти, ви задаєте самостійно, а найменування файлів, що містять об'єкти, зв'язані з таблицею, збігаються з ім'ям таблиці. У залежності від типу об'єкта, що утримується в ньому, Visual FoxPro автоматично привласнює кожному файлові розширення, що допомагає в ідентифікації об'єкта. [1]

При розробці системи всі форми продукції та замовників були зв’язані між собою по індексу. Усі елементи зв’язані з базою (відповідні поля при зміні записів завантажуються синхронно в усі поля).

Кнопки на формах автоматично пов’язані із записами. Розглянемо зокрема подію при натискуванні на кнопку «Наступний запис» форми table1. Як бачимо, виконується команда 1. buttonset1.cmdNext.click що присвоює елементам, які відображають інформацію, наступний запис (для кожного поля свій)


    продолжение
--PAGE_BREAK--