Розробка гнучкої системи управління інформаційними потоками магазину комп"ютерної техніки

Міністерство освіти і науки України Криворізький інститут Кременчуцького університету економіки, інформаційних технологій і управління Кафедра технічної кібернетики ДИПЛОМНА РОБОТА зі спеціальності

7.91 402 «Гнучкі комп’ютеризовані системи та робототехніка»

ПОЯСНЮВАЛЬНА ЗАПИСКА

«Розробка гнучкої системи управління інформаційними потоками магазину комп’ютерної техніки»

Студента групи ГКС-05-д Книжника Олександра Анатолійовича

Керівник роботи доц., к.т.н. Моня Григорій Михайлович

Консультанти:

зі спеціальної частини доц., к.т.н. Лукашенко Й. М з програмної частини доц., к.т.н. Вдовиченко І.Н.

з економічної частини доц., к.е.н. Тимко Є.В.

з охорони праці доц., к.т.н. Климович Г. Б нормоконтроль ст. викл. Захарова Г. Б.

Завідувач кафедри ТК доц., к.т.н. Старіков О.М.

Кривий Ріг

Міністерство освіти і науки України Криворізький інститут Кременчуцького університету економіки, інформаційних технологій і управління Кафедра технічної кібернетики Спеціальність 7.91 402 «Гнучкі комп’ютеризовані системи та робототехніка»

ЗАТВЕРДЖУЮ Зав. кафедрою доц., к.т.н. Старіков О.М.

_______________________

" 1 «листопада 2009 р.

ЗАВДАННЯ на дипломну роботу студента Книжника Олександра Анатолійовича

(прізвище, ім'я, по-батькові)

1. Тема роботи: Розробка гнучкої системи управління інформаційними потоками магазину______

комп’ютерної техніки _________________________________________

затверджена наказом по інституту від «29 «жовтня 2009 р. № 73С-01______________

2. Термін здачі студентом закінченої роботи 25.05.10. _

3. Вхідні дані до роботи: Вимоги до кінцевого програмного продукту, вихідні масиви даних, програмна документація.

4. Зміст розрахунково-пояснювальної записки (перелік питань, що підлягають розробці): Постановка завдання; Теоретичне дослідження принципів організації баз даних в DELPHI;Особливості використання мови SQL при розробці інформаційних систем; Опис функціональних можливостей та програмної реалізації проектованої системи; Економічне обґрунтування доцільності розробки програмного продукту; Охорона праці.

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

1. Загальний склад засобів для роботи системи з БД

2. Схема взаємодії з базою даних за допомогою SQL

3. Архітектура системи при роботі з локальними БД

4. Логіко-функціональна схема роботи користувача із системою

5. Структурна схема взаємозв'язку таблиць бази даних

6. Ієрархія форм системи

7. Приклади вікон системи в різних робочих режимах

8. Приклади вигляду форм системи на етапі проектування

6. Консультанти з роботи, з вказівками розділів роботи, що належать до них

7. Дата видачі завдання 01.11.09 р.

Керівник ____________________

Завдання прийняв до виконання ____________________

КАЛЕНДАРНИЙ ПЛАН

Студент-дипломник _________________

Керівник роботи _________________

Анотація Метою дипломної роботи є створення гнучкої системи управління інформаційними потоками магазину комп’ютерної техніки. Розроблена система реалізована з використанням системи програмування Delph 7 і сервера баз даних під керуванням MS SQL Server 2008.

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

Розділів 6, схем та малюнків 53, таблиць 18, бібліографічних посилань 30, загальний обсяг — 128.

Аннотация Целью дипломной работы является создание гибкой системы управления информационными потоками магазина компьютерной техники. Разработанная система реализована с использованием системы программирования Delphi 7 и сервера баз данных под управлением MS SQL Server 2008.

В исследовательской части дипломной работы был осуществлен сравнительный анализ различных архитектур баз данных и был сделанный аргументированный выбор в пользу клиент-серверной архитектуры.

Разделов 6, схем и рисунков 53, таблиц 18, библиографических ссылок 30, общий объем — 128.

The summary

The purpose of the diploma work is development of the flexible informative threads control system. The developed system is realized with the use of the system of programing Delphi 7 and SQL-Server under the management of MS SQL Server 2008.

Comparative analysis of different architectures of databases was carried in the research part of diploma work and there was the done argued choice in behalf on client — server architecture.

Sections 6, circuits and figures 53, tables 18, bibliographic references 30, total amount — 128.

ЗМІСТ

ВСТУП

1. ПОСТАНОВКА ЗАВДАННЯ

1.1 Найменування та галузь використання

1.2 Підстава для створення

1.3 Характеристика розробленого програмного забезпечення

1.4 Мета й призначення

1.5 Загальні вимоги до розробки

1.6 Джерела розробки

2. ТЕОРЕТИЧНЕ ДОСЛІДЖЕННЯ ПРИНЦИПІВ ОРГАНІЗАЦІЇ БАЗ ДАНИХ В DELPHI

2.1 Основні поняття і різновиди архітектур баз даних

2.2 Архітектура «файл-сервер» і локальні бази даних

2.3 Архітектура «клієнт-сервер»

2.4 Обґрунтування вибору архітектури стосовно проектованої системи

3. ОСОБЛИВОСТІ ВИКОРИСТАННЯ МОВИ SQL ПРИ РОЗРОБЦІ ІНФОРМАЦІЙНИХ СИСТЕМ

3.1 Історія розвитку і основні концепції мови SQL

3.2 Структура запитів до окремих таблиць

3.3.1 Оператор SELECT

3.3.2 Вибірка по умові

3.3.3 Агрегатні функції

3.3.4 Сортування записів

3.4. Багатотабличні запити

3.4.1 Об'єднання таблиць

3.4.2 Вкладені підзапити

3.4.3 Використання оператора EXISTS

3.4.4 Використання об'єднання UNION

4. ОПИС ФУНКЦІОНАЛЬНИХ МОЖЛИВОСТЕЙ ТА ПРОГРАМНОЇ РЕАЛІЗАЦІЇ ПРОЕКТОВАНОЇ СИСТЕМИ

4.1 Функціональне призначення та технологічні особливості розробки

4.2 Логіко-функціональна схема роботи користувача з системою

4.3 Опис моделі й структури таблиць і подань бази даних SalesRecord

4.4. Інтерфейс користувача проектованої системи

4.5 Програмна реалізація системи SalesRecord

5. ЕКОНОМІЧНЕ ОБҐРУНТУВАННЯ ДОЦІЛЬНОСТІ РОЗРОБКИ ПРОГРАМНОГО ПРОДУКТУ

6. ОХОРОНА ПРАЦІ

6.1 Аналіз небезпечних і шкідливих факторів обчилювальному центрі

6.2 Заходи щодо нормалізації шкідливих і небезпечних факторів

6.2.1 Захист від електромагнітних випромінювань

6.2.2 Захист від ураження електричним струмом

6.2.3 Захист від статичної електрики

6.2.4 Захист від шуму та вібрації

6.2.5 Оздоровлення повітряного середовища

6.2.6 Захист від рентгенівського випромінювання

6.2.7 Забезпечення раціонального освітлення

6.3 Пожежна безпека ВИСНОВКИ СПИСОК ЛІТЕРАТУРИ

ВСТУП

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

Існує багато вагомих причин перекладу існуючої інформації на комп’ютерну основу. Зараз вартість зберігання інформації у файлах ЕОМ дешевше, ніж на папері. Бази даних дозволяють зберігати, структурувати інформацію й витягати оптимальним для користувача образом. Використання клієнт/серверних технологій дозволяють зберегти значні засоби, а головне й час для одержання необхідної інформації, а також спрощують доступ і ведення, оскільки вони ґрунтуються на комплексній обробці даних і централізації їхнього зберігання. Крім того ЕОМ дозволяє зберігати будь-які формати даних текст, креслення, дані в рукописній формі, фотографії, записі голосу й т.д.

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

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

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

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

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

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

1. ПОСТАНОВКА ЗАВДАННЯ

1.1 Найменування та галузь використання

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

1.2 Підстава для створення

Підставою для розробки є наказ № 73С-01 від 29 жовтня 2009 р. по Криворізькому інституту КУЕІТУ.

Початок робіт: 01.11.09. Закінчення робіт: 25.05.10.

1.3 Характеристика розробленого програмного забезпечення

Гнучка система управління інформаційними потоками магазину комп’ютерної техніки була реалізована за допомогою інструментального засобу прискореної розробки програм системи програмування Delphi7, технології Rave Reports і сервера баз даних під керуванням MS SQL Server 2008.

Склад розробленої системи:

· SalesRecord. exe — виконуємий файл, розробленої системи;

· SalesRecord_Data.mdf — файл бази даних SalesRecord, сервера баз даних MS SQL Server 2008.

· SalesRecord_Log.ldf — журнал транзакцій бази даних SalesRecord, сервера баз даних MS SQL Server 2008.

· Report. rav — проект звіту середовища Rave (Report Authoring Visual Environment).

1.4 Мета й призначення

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

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

1.5 Загальні вимоги до розробки

Вимоги до програмного забезпечення:

· Робота в середовищі операційних систем Windows 2000/XP/Vista/7;

· Відсутність додаткових вимог до розміщення здійсненних файлів;

· Додаткове програмне забезпечення: установка сервера БД MS SQL Server 2008;

Мінімальні вимоги до апаратного забезпечення:

· IBM-Сумісний комп’ютер, не нижче Pentium III, RAM-256Mb, SVGA-800*600*16bit, вільний простір на жорсткому диску на сервері не менш 100 Мб, на клієнтській машині - біля 5 Мб.

1.6 Джерела розробки

Джерелами розробки дипломної роботи є:

· загальний опис технології процесу;

· довідкова література;

· наукова література;

· технічна література;

· програмна документація.

2. ТЕОРЕТИЧНЕ ДОСЛІДЖЕННЯ ПРИНЦИПІВ ОРГАНІЗАЦІЇ БАЗ ДАНИХ В DELPHI

2.1 Основні поняття і різновиди архітектур баз даних

Для розгляду способів організації баз даних потрібно визначити декілька понять.

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

Основною функцією компілятора мови БД є компіляція операторів мови БД в деяку виконувану програму.

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

Загальний склад засобів, необхідних для роботи готового додатку з БД, показаний на рис. 2.1.

Рис. 2.1 Загальний склад засобів для роботи готової системи з БД Згідно цій загальній схемі, ми маємо ланцюжок:

Додаток —> Ядро БД —> бази даних. У структурі додатку є ланцюжок Невізуальні компоненти —> Візуальні компоненти. Невізуальні компоненти надають програмісту деякі функції по управлінню ядром бази даних, а також самими даними. За допомогою Візуальних компонент дані відображаються на екрані (таблиці, списки, випадні списки, графіки і ін.). Місцеположення ядра БД і самих баз даних в цьому ланцюжку не відбиті.

Місцеположення Ядра БД і баз даних залежить від використовуваної архітектури. Є чотири різновиди архітектури баз даних:

· локальні бази даних;

· архітектура «файл-сервер» ;

· архітектура «клієнт-сервер» ;

· багатоланкова (триланкова N-tier або multi-tier) архітектура.

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

2.2 Архітектура «файл-сервер» і локальні бази даних

Локальні бази даних і архітектура «файл-сервер»

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

При роботі в архітектурі «файл-сервер» БД і програма розташовані на файловому сервері мережі (наприклад, Novell NetWare). Можлива також і розрахована на багато користувачів робота з однією і тією ж БД, коли кожен користувач з свого комп’ютера запускає програму, розташовану на мережевому сервері. Тоді на комп’ютері користувача запускається копія програми. По кожному запиту до БД із програми дані з таблиць БД перегоняться на комп’ютер користувача, незалежно від того, скільки реально потрібно даних для виконання запиту. Після цього виконується запит.

Кожен користувач має на своєму комп’ютері локальну копію даних, що час від часу оновлюються з реальної БД, розташованої на мережевому сервері. При цьому зміни, які кожен користувач вносить в БД, можуть бути до певного моменту невідомі іншим користувачам, що робить актуальним завдання систематичного оновлення даних на комп’ютері користувача з реальної БД. Іншим актуальним завданням є блокування записів, які змінюються одним з користувачів: це необхідно для того, щоб в цей час інший користувач не вніс змін в ті ж дані. У архітектурі «файл-сервер» вся тяжкість виконання запитів до БД, управління цілісністю БД лягає на програму користувача. БД на сервері є пасивним джерелом даних.

Кардинальних відмінностей з погляду архітектури між розрахованою на одного користувача архітектурою і архітектурою «файл-сервер» немає. І в тому і в іншому випадку як СУБД застосовуються так звані «персональні» (або «локальні») СУБД. такі як Paradox, dBase і ін. Сама база даних в цьому випадку є набір таблиць, індексних файлів, мемо-полів і ін., що зберігаються в одному каталозі на диску у вигляді окремих файлів.

2.3 Архітектура «клієнт-сервер»

Архітектура «файл-сервер» неефективна, принаймні, в двох відносинах. При виконанні запиту до бази даних, розташованої на файловому сервері, насправді відбувається запит до локальної копії даних на комп’ютері користувача. Тому перед виконанням запиту дані в локальній копії оновлюються з реальної БД. Дані оновлюються в повному об'ємі. Так, якщо таблиця БД складається з 1000 записів, а для виконання запиту (наприклад, видати суму премій за жовтень у відділі Y) реально потрібно 10 записів, все одно перегоняться всі 1000 записів. Таким чином, не потрібно мати дуже багато користувачів і запитів від них, щоб серйозно завантажити мережу, що, звичайно ж, не може не позначитися на її швидкодії.

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

Архітектура «клієнт-сервер» розділяє функції програми користувача (званого клієнтом) і сервера.

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

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

· посилка до сервера запитів;

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

· реалізація інтерфейсу користувача.

SQL-сервер — це програма, розташована на комп’ютері мережевого сервера. SQL-сервер повинен бути завантажений на момент надходження запиту від клієнта. Функціями сервера БД є:

· прийом запитів від програм-клієнтів, інтерпретація запитів, виконання запитів в БД, відправка результату виконання запиту програмі-клієнту;

· управління цілісністю БД, забезпечення системи безпеки, блокування невірних дій програм-клієнтів;

· зберігання бізнес-правил, часто використовуваних запитів у вже інтерпретованому вигляді;

· забезпечення одночасно безпечної і відмовостійкої, розрахованої на багато користувачів роботи з одними і тими ж даними.

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

До розрядку промислових СУБД належать: Oracle, Gupta, Informix, Sybase, MS SQL Server DB2, InterBase і ряд інших.

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

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

2.4 Обґрунтування вибору архітектури стосовно проектованої системи

Використання архітектури «сервер» клієнта:

· різко зменшує мережевий трафік;

· знижує складність програм-клієнтів (оскільки тим вже немає необхідності забезпечувати цілісність і безпеку БД і стежити за параметрами розрахованої на багато користувачів роботи з БД);

· знижує вимоги до апаратних засобів, на яких ці програми функціонують (тобто до комп’ютерів користувачів-клієнтів);

· підвищує надійність БД, її цілісність, безпеку і секретність.

3. ОСОБЛИВОСТІ ВИКОРИСТАННЯ МОВИ SQL ПРИ РОЗРОБЦІ ІНФОРМАЦІЙНИХ СИСТЕМ

3.1 Історія розвитку і основні концепції мови SQL

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

Непроцедурна мова SQL (Structured Query Language — структурована мова запитів), що розглядається ж нижче, орієнтована на операції з даними, представленими у вигляді логічно взаємозв'язаних сукупностей таблиць. Особливість пропозицій цієї мови полягає в тому, що вони орієнтовані більшою мірою на кінцевий результат обробки даних, чим на процедуру цієї обробки. SQL сам визначає, де знаходяться дані, які індекси і навіть які найбільш ефективні послідовності операцій слід використовувати для їх отримання: не треба указувати ці деталі в запиті до бази даних.

Для ілюстрації відмінностей між ММД розглянемо наступну ситуацію. Хай, наприклад, ми збираємося подивитися кінофільм і хочемо скористатися для поїздки в кінотеатр послугами таксі. Одному шоферу таксі досить сказати назву фільму — і він сам знайде вам кінотеатр, в якому показують потрібний фільм. (Подібним же чином, самостійно, відшукує запитані дані SQL.)

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

Може трапитися і так, що нам доведеться самому дізнатися адресу кінотеатру і запропонувати водію проїхати до нього по таких-то і таких-то вулицях. У найгіршому випадку нам, можливо, навіть доведеться по дорозі давати вказівки: «Повернути наліво… проїхати п’ять кварталів… повернути направо…». (Аналогічно більший або менший рівень деталізації запиту доводиться створювати користувачу в різних СУБД, що не мають мови SQL.)

Поява теорії реляційних баз даних і запропонованої Коддом мови запитів «alpha», заснованої на реляційному численні, ініціювало розробку ряду мов запитів, які можна віднести до двох класів:

Мови, алгебри, що дозволяють виражати запити засобами спеціалізованих операторів, вживаних до відносин (JOIN — з'єднати, INTERSECT — перетнути, SUBTRACT — відняти і т.д.).

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

Розробка, в основному, йшла у відділеннях фірми IBM (мови ISBL, SQL, QBE) і університетах США (PIQUE, QUEL). Останній створювався для СУБД INGRES (Interactive Graphics and Retrieval System), яка була розроблена на початку 70-х років в Університеті шт. Каліфорнія і сьогодні входить в п’ятірку кращих професійних СУБД. Сьогодні зі всіх цих мов повністю збереглися і розвиваються QBE (Query-By-Example — запит за зразком) і SQL, а з інших узяті в розширення внутрішніх мов СУБД тільки найцікавіші конструкції.

На початку 80-х років SQL «переміг» інші мови запитів і став фактичним стандартом таких мов для професійних реляційних СУБД. У 1987 році він став міжнародним стандартом мови баз даних і почав упроваджуватися у всі поширені СУБД персональних комп’ютерів. Чому ж це відбулося?

Безперервне зростання швидкодії, а також зниження енергоспоживання, розмірів і вартості комп’ютерів привели до різкого розширення можливих ринків їх збуту, круга користувачів, різноманітності типів і цін. Природно, що розширився попит на різноманітне програмне забезпечення.

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

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

Для виключення вказаних і деяких інших недоліків була запропонована технологія клієнт-сервер, по якій запити призначених для користувача ЕОМ (Клієнт) обробляються на спеціальних серверах баз даних (Сервер), а на ЕОМ повертаються лише результати обробки запиту. При цьому, природно, потрібна єдина мова спілкування з Сервером і як така мова вибрана SQL. Тому всі сучасні версії професійних реляційних СУБД (DB2, Oracle, Ingres, Informix, Sybase, Progress, Rdb) і навіть нереляційних СУБД (наприклад, Adabas) використовують технологію клієнт-сервер і мову SQL.

Існує думка: Оскільки велика частина запитів формулюється на SQL, практично байдуже, що це за СУБД — був би SQL.

Реалізація в SQL концепції операцій, орієнтованих на табличне представлення даних, дозволило створити компактну мову з невеликим (менше 30) набором операторів. Мова SQL може використовуватися як інтерактивна (для виконання запитів) і як вбудована (для побудови прикладних програм).

На рис. 3.1 показана схема, що відображає принцип використання SQL. Користувач передає запит інтерпретатору, який, у свою чергу, повертає уявлення, таблицю або курсор. Ці об'єкти знаходяться на так званому віртуальному рівні і формуються тільки за запитом. Але вони взаємодіють з реальним рівнем, тобто з таблицями баз даних, на основі яких відбувається формування віртуальних об'єктів. Звичайно, дане розділення є умовним, але воно добре відображає ідеологію SQL.

3.2 Структура запитів до окремих таблиць

Достатньо поширеним є завдання отримання даних з однієї або декількох таблиць і формування на їх основі яких-небудь звітів. У даному розділі будуть викладені базові поняття SQL і способи створення відповідних запитів.

3.3.1 Оператор SELECT

Оператор SELECT є виразом, що ініціює виконання запиту. В даному випадку запит є командою на отримання даних. Вираз SELECT має строго певний формат:

SELECT [[ALL] | DISTINCT] *

FROM уявлення [псевдонім]

[. базова_таблиця [псевдонім]]

[WHERE умова]

[GROUP BY назва поля (полів) [HAVING фраза]]:

Рис. 3.1 Схема взаємодії з базою даних за допомогою SQL

3.3.2 Вибірка по умові

Вибірку по умові реалізує оператор WHERE. Оператор є частиною виразу SELECT і служить для завдання умов відбору записів в результуючий набір. В ході виконання запиту відбувається перевірка всіх записів на відповідність умові відбору. Як приклад можна привести досить простий запит:

SELECT State, City, Company FROM Customer

WHERE State = 'CA'

При обробці запиту був похідний відбір всіх записів, поле State яких має значення СА.

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

SELECT Company, Phone, Fax FROM Customer

WHERE Phone = Fax

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

SELECT DISTINCT Country FROM Customer

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

SELECT OnHand, OnOrder,(OnHand*OnOrder) AS

Твір, (OnHand+OnOrder) AS Сума FROM Parts

У даному прикладі проводиться перемножування і підсумовування значень полів OnHand і OnOrder.

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

Запит SELECT може також включати числові і текстові константи. Як приклад можна привести наступний запит:

SELECT OnHand, OnOrder,'MUL',(OnHand + 1) AS Плюс,'SUB',(OnHand — 1) AS Мінус FROM Parts

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

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

Логічні оператори дозволяють задати в запиті логічні умови. Оператор AND реалізує логічне «І». Оператор OR реалізує логічне «АБО». Вираз з його використанням, вважатиметься істинним, якщо хоч би одна з умов теж є істиною. Оператор NOT означає логічне заперечення. Його дія зводиться до того, що він інвертує логічну умову, перед якою його розташовують.

Як приклад можна привести запит, що дозволяє вибрати співробітників, одержуючих заробітну платню в певному чисельному проміжку. Дані витягуватимуться з таблиці Employee:

SELECT LastName, FirstName, Salary FROM Employee

WHERE Salary >= 25 000 AND Salary <= 30 000

В результаті виконання запиту повертаються імена співробітників із заробітною платнею від 25 до 30 тисяч включно. В даному випадку оператор AND використовується для завдання діапазону вибираних значень.

Тепер можна змінити даний запит. Можна відшукати всіх співробітників, для яких окрім приведених вище умов поле PhoneExt яких має значення 22:

SELECT LastName, FirstName, Salary, PhoneExt FROM Employee

WHERE Salary >= 25 000 AND Salary <= 30 000 and PhoneExt = '22'

Якщо ж потрібно буде відшукати співробітників, поле PhoneExt яких має значення, не рівне 22, запит буде трохи змінений:

SELECT LastName, FirstName, Salary, PhoneExt FROM Employee

WHERE Salary >= 25 000 AND Salary <= 30 000 and not PhoneExt = '22'

Як видно з тексту запиту, логічна умова NOT дозволила виключити непотрібні номери.

Тепер можна розглянути приклад запиту з використанням оператора OR. Припустимо, менеджеру знадобилося одержати списки всіх співробітників по прізвищу Johnson. Або тих співробітників, які одержують заробітну платню більше 45 000. Скласти запит буде неважко:

SELECT LastName, FirstName, Salary FROM Employee

WHERE LastName = 'Johnson' or Salary > 45 000

Варто звернути увагу на дію оператора 0R. У набір даних були включені записи, значення поля Salary яких перевищувало 40 000, і ті записи, в яких поле LastName мало значення Johnson.

Використання оператора IN

Оператор IN визначає масив значень, в який може входити або не входити значення поля даного запису. Наприклад, необхідно вибрати співробітників із заробітною платнею 40 000, 55 500 і 25 000. Запит потрібно буде переробити:

SELECT LastName, FirstName, Salary FROM Employee

where Salary = 40 000 or Salary = 55 500 or Salary = 25 000

Проте цей же запит можна написати в коротшій і красивішій формі за допомогою оператора IN:

SELECT LastName, FirstName, Salary FROM Employee

where Salary IN (40 000, 55 500, 25 000)

Як аргументи оператору IN були передані значення полів, по яких проводився відбір записів.

Оператор IN може використовуватися і для пошуку символьних значень. Припустимо, нам необхідно з’ясувати назви компаній, що знаходяться в містах Christiansted, Grand Cayman і St. Thomas. Ці дані міститися в таблиці Customer. Запит знову знадобиться трохи змінити:

SELECT Company, City FROM Customer

WHERE City IN (`Christiansted','Grand Cayman','St.Thomas')

Використання оператора BETWEEN

Оператор BETWEEN використовується для вказівки діапазону значень, які використовуються для установки умови відбору записів. Цей оператор чутливий до порядку переліку параметрів, що визначають межі діапазону. Як приклад можна привести простий запит:

SELECT CustomerID, EmployeeID, ShipName FROM Orders

WHERE EmployeeID BETWEEN 3 AND 5

В результаті виконання запиту були вибрані записи, значення поля EmployeeID, яких знаходяться в проміжку від трьох до п’яти включно.

Наступний приклад показує, як можна вибрати номери замовлень, зроблених за певний проміжок часу від 04.07.1996 до 08.07.1996:

SELECT OrderlD, OrderDate, ShipName FROM Orders

WHERE OrderDate BETWEEN '07.04.1996' AND '07.08.1996'

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

SELECT OrderID, OrderDate, ShipName, Freight FROM Orders

WHERE OrderDate NOT BETWEEN '07.04.1996' AND '07.08.1996' AND Freight > 100

Використання оператора LIKE

Оператор LIKE використовується для вибору всіх записів, в які входить підрядок, вказаний як параметр. Як умову оператор також приймає спеціальні символи. Символ підкреслення замінює будь-який одиночний символ, а знак відсотка позначає будь-яку кількість символів.

Припустимо, необхідно вибрати компанію, в назві якої не вистачає декількох букв. В цьому випадку назву можна позначити як S? mons?bistro. Відповідний запит використовуватиме вказаний оператор LIKE:

SELECT CompanyName, ContactName FROM Customers

WHERE CompanyName LIKE 'S_rnons_bistro'

Можна скласти запит, в якому проводитиметься пошук якогось підрядка, що входить в запис. Припустимо, що необхідно знайти всі компанії, в назвах яких зустрічається послідовність символів «ric».

Задачу вирішує нескладний запит

SELECT CompanyName, ContactName FROM Customers

WHERE CompanyName LIKE `%Ric%'

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

SELECT CompanyName, ContactName FROM Customers

WHERE CompanyName LIKE `%R c%'

3.3.3 Агрегатні функції

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

· Оператор COUNT повертає кількість записів, що задовольняють умові запиту.

· Оператор SUM підсумовує значення записів поля.

· Оператор AVG обчислює середнє значення записів поля.

· Оператор МАХ повертає найбільше значення даного поля.

· Оператор MIN повертає найменше значення даного нуля.

Агрегатні функції використовуються подібно до імен полів в запиті, а справжні імена полів передаються їм як аргументи. З операторами SUM і AVG можуть використовуватися тільки числові поля. З операторами COUNT, MAX і MIN можуть використовуватися числові і символьні поля. У разі застосування функцій МАХ і MIN до символьних полів їх значення будуть трансльовані в ASCII-код. Мінімальному значенню функції відповідатиме символ алфавіту, що знаходиться ближче до його початку, максимального, — що знаходиться ближче до кінця.

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

SELECT AVG (Freight) AS Середнє, MIN (Freight) AS Мін, MAX (Freight) AS Макс, SUM (Freight) AS Сумарне, COUNT (Freight) AS Кількість FROM Orders

WHERE Freight >300

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

SELECT COUNT (DISTINCT City) AS Кількість_міст FROM Customers

В ході виконання запиту з оператором DISTINCT було зафіксовано 69 записів. Без використання оператора — 91. Для виключення повторів при використанні функцій AVG і SUM теж може бути використаний цей оператор.

Оператор GROUP BY використовується для визначення полів, до яких можуть застосовуватися агрегатні функції. У випадку, якщо цей оператор явно не вказаний, всі поля, вказані у виразі SELECT, трактуються як аргументи агрегатних функцій. Поля, вказані як параметри оператора GROUP BY, стають такими, що групуються. Всі записи результуючого набору, що мають однакові значення групуючих полів, утворюють єдину групу. Далі до кожної такій групі буде застосована агрегатна функція. Фактично, оператор GROUP BY дає можливість об'єднувати поля і агрегатні функції в єдиному запиті.

Ілюструє вищесказане запит, що відшукує міста, в яких розташовані фірми, кількість цих міст і максимальне значення поштового індексу для фірми, розташованої в даному місті:

SELECT City, COUNT (*) AS Кількість, MAX (PostalCode) AS Почтовий_індекс FROM Customers GROUP BY City

Легко відмітити, що поле City не входить в агрегатну функцію як параметр, тому його було оголошено з використанням оператора GROUP BY. В ході виконання запиту були вибрані міста, і для кожного міста була підрахована кількість входжень.

Цей приклад можна ускладнити. Можна створити запит, який одержує тільки ті міста, які повторюються в таблиці більше двох разів, і при цьому в кінцевий результат не повинне включатися місто Buenos Aires. Оператор WHERE в даному випадку використовувати не вийде, оскільки він працює тільки з окремими записами, а не з масивами. Доведеться використовувати оператора HAVING, який є аналогом оператора WHERE, але може працювати з агрегатними функціями. Сам запит буде досить сильно змінений:

SELECT City, COUNT (*) AS Кількість, MAX (PostaTCode) AS

Почтовый_индекс FROM Customers Where City <> 'Buenos Aires'

GROUP BY City HAVING COUNT (*) >=3

3.3.4 Сортування записів

Оператор ORDER BY використовується для впорядковування записів результуючого набору даних. Записи сортуються відповідно до порядку проходження полів і їх значень. Якщо сортування проводитиметься за збільшенням, то слід використовувати параметр ASC. Для сортування по убуванню використовується параметр DESC. Як приклад можна привести нескладний SQLзапит

SELECT CompanyName, ContactName, City FROM Customers

ORDER BY City

Сортування записів проводиться по полю City.

До створеного запиту можна додати сортування по кількості міст у порядку убування записів:

SELECT City, COUNT (*) AS Кількість, MAX (PostalCode) AS Почтовый_индекс FROM Customers Where City <> 'Buenos Aires'

GROUP BY City HAVING COUNT (*) >=3

ORDER BY Кількість DESC, City ASC

Потрібно звернути увагу на те, що як аргумент параметра ORDER BY була використана назва поля, оскільки його значення є результатом агрегатної функції COUNT. Для включення сортування по убуванню був вказаний параметр DESC, розташований після назви поля.

3.4 Багатотабличні запити

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

3.4.1 Об'єднання таблиць

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

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

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

SELECT Orders. ShipName AS Судно, Orders. Freight AS

Вес_груза, Orders. OrderDate

AS Дата_Отправки, Customers. ContactName, Customers. Phone

FROM Customers, Orders

WHERE Customers. CustomerID=Orders.CustomerID

При виконанні запиту були вибрані поля тільки тих записів, у яких значення поля CustomerID співпадали. За допомогою цього поля були об'єднані і зв’язані дві таблиці.

Цей запит можна ускладнити. Припустимо, що необхідно одержати інформацію саме про ті судна, вантаж яких важив більше 500 тонн і був відправлений до періоду з 17.03.1998 по 17.07.1998:

SELECT Orders. ShipName AS Судно, Orders. Freight AS Вес_груза, Orders. OrderDate AS Дата_Отправки, Customers. ContactName, Customers. Phone

FROM Customers, Orders

WHERE Customers. CustomerID = Orders. CustomerID AND Freight > 500 AND

Orders.OrderDate BETWEEN '03.17.1998' AND '07.17.1998'

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

3.4.2 Вкладені підзапити

Вкладені запити можуть використовуватися як додаткові умови відбору записів. Для того, щоб зрозуміти механізм роботи цієї умови, слід розглянути простий запит, в якому виводиться список назв судів, які обслужив співробітник на ім'я Steven Buchanan і дат їх відправки:

SELECT ShipName AS Название_судна, OrderDate AS Дата_отправки FROM Orders WHERE EmployeeID IN

(SELECT EmployeeID FROM Employees

WHERE FirstName = 'Steven' AND LastName = 'Buchanan'):

У цьому запиті оператор IN може бути замінений оператором рівності. Проте слід враховувати, що оператор IN повертає масив значень, а скалярний оператор рівності — тільки одне.

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

Можна ускладнити вкладений запит. У прикладі буде приведений запит, що відображає список співробітників, що обслужили більше дев’яноста суден:

SELECT TitleOfCourtesy, FirstName, LastName FROM Employees

WHERE EmployeeID IN

(SELECT EmployeeID FROM Orders GROUP BY EmployeeID

HAVING

COUNT (EmployeeID) > 100)

ORDER BY FirstName, LastName

У вкладеному запиті проводиться відбір ідентифікаторів працівників, що зустрічаються в таблиці більше 90 разів.

3.4.3 Використання оператора EXISTS

Логічні оператори EXIST і NOT EXIST повертають значення True або False залежно від наявності записів, що задовольняють умові пошуку. Як правило, оператор EXISTS використовується з вкладеними запитами. Для ілюстрації принципів його застосування можна використовувати досить простий запит

SELECT TitleOfCourtesy, FirstName, LastName FROM Employees

WHERE EXISTS

(SELECT * FROM Orders

WHERE Freight > 1000)

ORDER BY LastName

У підзапиті вибираються рядки, значення яких більше 1000. Оскільки подібні рядки існують, то оператору WHERE передається значення True і вираз SELECT вибирає відповідні записи.

Можна змінити умову, що накладається на полі Freight, і використовувати замість оператора EXISTS оператор NOT EXISTS

SELECT TitleOfCourtesy.FirstName.LastName FROM Employees

WHERE NOT EXISTS

(SELECT * FROM Orders

WHERE Freight > 2000)

ORDER BY LastName

Результат виконання запиту буде аналогічний попередньому. Потрібно розібратися, чому так відбулося. Оператор NOT EXISTS поверне значення True тільки в тому випадку, якщо жоден запис не задовольнятиме заданій умові. Оскільки жодне судно не перевезло більш ніж 2 тисячі тонн вантажу, то жоден запис не буде вибраний.

3.4.4 Використання об'єднання UNION

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

SELECT CustomerID FROM Customers

UNION

SELECT CustomerID FROM Orders

В ході виконання запиту в результуючу таблицю були включені записи з двох таблиць.

4. ОПИС ФУНКЦІОНАЛЬНИХ МОЖЛИВОСТЕЙ ТА ПРОГРАМНОЇ РЕАЛІЗАЦІЇ ПРОЕКТОВАНОЇ СИСТЕМИ

4.1 Функціональне призначення та технологічні особливості розробки

Гнучка система управління інформаційними потоками магазину комп’ютерної техніки була реалізована за допомогою інструментального засобу прискореної розробки програм системи програмування Delphi, технології Rave Reports і сервера баз даних під керуванням MS SQL Server 2008.

Розроблена система реалізує наступні функції:

· Облік і формування асортиментів комп’ютерної техніки (КТ) необхідної на складі;

· Облік постачальників комп’ютерної техніки;

· Облік поставленої на склад комп’ютерної техніки;

· Облік проданої зі складу комп’ютерної техніки;

· Формування списку комп’ютерної техніки для замовлення на склад;

· Контроль продажу комп’ютерної техніки зі складу;

· Вивід на друк й збереження в окремому файлі у форматах (*.pdf; *.rtf; *.html; *.prn; *.txt) звітів: асортименти на складі; постачальники комп’ютерної техніки; замовити комп’ютерну техніку.

Склад розробленої системи:

· SalesRecord. exe — виконуємий файл, розробленої системи;

· SalesRecord_Data.mdf — файл бази даних SalesRecord, сервера баз даних MS SQL Server 2008.

· SalesRecord_Log.ldf — журнал транзакцій бази даних SalesRecord, сервера баз даних MS SQL Server 2008.

· Report. rav — проект звіту середовища Rave (Report Authoring Visual Environment)

4.2 Логіко-функціональна схема роботи користувача з системою

В загальному вигляді логіко-функціональну схему роботи користувача з системою можна представити наступним чином (рис. 4.1).

Рис. 4.1 Логіко-функціональна схема роботи користувача із системою

4.3 Опис моделі й структури таблиць і подань бази даних SalesRecord