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

[ виправити ] текст може містити помилки, будь ласка перевіряйте перш ніж використовувати.

скачати

КУРСОВИЙ ПРОЕКТ

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

Введення

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

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

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

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

1. Постановка завдання

1.1 Аналіз предметної області

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

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

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

1.2 Обгрунтування актуальності розв'язуваної задачі

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

Модельована інформаційна система призначена для спрощення ведення передплатний діяльності, а саме покликана вирішувати такі практичні завдання:

введення та зберігання відомостей про організації - клієнтів;

введення та зберігання відомостей про клієнтів фізичних осіб;

складання рейтингу найбільш популярних видань;

складання списку поштових відділень, які спрацювали краще за інших за звітний період;

аналіз загального обсягу передплати і числа передплатних видань;

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

складання звіту по організаціям та обсягами передплати.

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

2. Проектування логічної моделі системи

2.1 Функціональна модель

Для проведення аналізу та функціонального проектування інформаційної системи використовується CASE - засіб Bpwin. Bpwin підтримує три методології: IDEF 0, DFD та IDEF 3, дозволяють аналізувати організаційну систему.

Інформаційна система функціонує наступним чином.

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

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

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

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

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

2.1.1 Контекстна діаграма і деталізація процесів

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

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

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

Функціональна модель (діаграми першого і другого рівнів) розглянутої інформаційної системи зображена в додатку 5.1.

2.1.2 Миниспецификация процесів

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

2.2 Інформаційна модель

2.2.1 Ідентифікація сутностей і зв'язків. ER-діаграма логічного рівня

Для відображення інформаційної моделі даного процесу були використані наступні сутності:

Видання

ВедПодпіска (відомча підписка)

ЧастПодпіска (підписка фізичних осіб)

Поштове відділення

ІзданіеПочтОтдел

ЧастЦена (ціна передплати видання для приватних осіб)

ВедЦена (ціна передплати видання для організацій)

Схема кожного з відносин представлена ​​на малюнку 3.

Для однозначного визначення записів у кожному з відносин виділено первинний ключ (простий або складений).

Зовнішні ключі для відносин БД:

у відносинах ВедЦена і ЧастЦена - це ключ Індекс;

у відносинах ВедПодпіска і ЧастПодпіска - це складовою ключ: Індекс, НомерПО.

На логічному рівні проектування в моделюється базі даних наявні такі типи зв'язків між описаними сутностями:

1) зв'язок типу один до багатьох;

2) зв'язок типу багато до багатьох між Виданням і поштове відділення.

2.2.2 Визначення доменів для схем відносин. Уточнення типів даних для атрибутів схем відносин. Реалізація посилальної цілісності

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

Все не ключові атрибути функціонально повно і не транзитивній залежать від первинного ключа. Отже, ставлення знаходиться в БКНФ.

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

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

Таким чином, всі відносини знаходяться в БКНФ.

На логічному рівні в моделюється системі присутня зв'язок типу "багато до багатьох" між сутністю Видання і сутністю Поштове відділення. Для її реалізації на фізичному рівні була введена додаткова залежна сутність ІзданіеПочтОтдел.

Наведена у додатку 5.3 діаграма наочно відображає всі атрибути відносин та їх фізичні характеристики.

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

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

Таблиця 1 - Результат зв'язування об'єктів моделі процесів

Attribute Name

Entity Name

Arrow Name

Activity Name

Адреса

ЧастПодпіска

Дані клієнта

Зміна даних по частПодпіске




Реєстрація частПодпіскі

Індекс

ВедПодпіска

Запит про обсяги

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



звіт по виданнях

Аналіз обсягу ведподпіскі по виданнях



звіт по організаціям

Аналіз обсягів передплати на організації


ЧастПодпіска

Запит про обсяги част

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



звіт по част видавництва

Аналіз обсягу частподпіскі по виданнях

Код

ЧастПодпіска

Дані клієнта

Зміна даних по частПодпіске




Реєстрація частПодпіскі



Запит про обсяги част

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

НазвІзданія

Видання

Запит про обсяги

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



Запит про обсяги част

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



звіт по виданнях

Аналіз обсягу ведподпіскі по виданнях



звіт по організаціям

Аналіз обсягів передплати на організації



звіт по част видавництва

Аналіз обсягу частподпіскі по виданнях

НомерПО

ЧастПодпіска

Дані клієнта

Зміна даних по частПодпіске




Реєстрація частПодпіскі

Обсяг

ВедПодпіска

Запит про обсяги

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



звіт по виданнях

Аналіз обсягу ведподпіскі по виданнях



звіт по організаціям

Аналіз обсягів передплати на організації

Організація

ВедПодпіска

Дані організації

Зміна даних по ведПодпіске




Реєстрація ведПодпіскі



Запит про обсяги

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



звіт по організаціям

Аналіз обсягів передплати на організації

період

ВедПодпіска

Запит про обсяги

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

Період

ЧастПодпіска

Дані клієнта

Зміна даних по частПодпіске




Реєстрація частПодпіскі



Запит про обсяги част

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



звіт по част видавництва

Аналіз обсягу частподпіскі по виданнях

Прізвище

ЧастПодпіска

Дані клієнта

Зміна даних по частПодпіске




Реєстрація частПодпіскі





3. Реалізація системи

3.1 Опис програмного забезпечення, розробленого в архітектурі "клієнт - сервер"

Моделируемое програмне забезпечення передбачає роботу з двома клієнтами: касиром-оператором і начальником поштового відділення, які користуються одними даними, але виконують різні види робіт з цими даними. Тому було розроблено два додатки "Опрацювати дані для касира-оператора" і "Опрацювати дані для начальника".

Робота з базою даних починається з автоматичного відкриття головної кнопкової форми. На формі знаходяться такі управляючі елементи - кнопки та їх підписи. При натисненні на кнопку з допомогою миші розкривається форма або виконується певний запит. Для полегшення роботи кожна кнопка забезпечена спливаючій підказкою. Для здійснення пошуку необхідних даних на головну кнопкову форму виведені кнопки для виклику відповідних запитів. Для виходу з бази даних передбачена кнопка "Вихід".

Кнопкова форма клієнтського додатку "Опрацювати дані для начальника поштового відділення" представлена ​​на рисунку 1.

Малюнок 1 - Форма клієнтського додатку "Опрацювати дані для начальника поштового відділення"

Кнопкова форма клієнтського додатку "Опрацювати дані для касира-оператора" представлена ​​на рисунку 2.

Малюнок 2 - Форма клієнтського додатку "Опрацювати дані для касира-оператора"

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

3.2 SQL-визначення регламентованих запитів та уявлень

На базі описаних вище таблиць для обробки даних і для знаходження необхідної інформації були збудовані такі запити.

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

SELECT DISTINCTROW TOP 3 ВедПодпіска.НомерПО, Sum (ВедПодпіска.Об'ем) AS Обсяг

FROM ВедПодпіска

GROUP BY ВедПодпіска.НомерПО

ORDER BY Sum (ВедПодпіска. Об'єм) DESC;

Для отримання даних про обсяг відомчої передплати по окремим виданням був складений запит наступного виду:

SELECT DISTINCTROW Ізданіе.НазвІзданія, Sum (ВедПодпіска.Об'ем) AS Обсяг

FROM Видання INNER JOIN ВедПодпіска ON Ізданіе.Індекс = ВедПодпіска.Індекс

GROUP BY Ізданіе.НазвІзданія;

Для отримання даних про обсяг приватної передплати за окремим виданням був складений запит наступного виду:

SELECT DISTINCTROW Ізданіе.НазвІзданія, Count (ЧастПодпіска.Індекс) AS Обсяг

FROM Видання INNER JOIN ЧастПодпіска ON Ізданіе.Індекс = ЧастПодпіска.Індекс

GROUP BY Ізданіе.НазвІзданія;

Для отримання даних про обсяг підписки на організації був складений запит наступної структури:

SELECT DISTINCTROW ВедПодпіска.Організація, Sum (ВедПодпіска.Об'ем) AS Обсяг

FROM ВедПодпіска

GROUP BY ВедПодпіска.Організація;

Для виконання запиту на отримання даних про загальний обсяг відомчої передплати і кількості передплатних видань соствлен SQL-запит наступного виду:

SELECT DISTINCTROW Count ([V в_подпіскі по виданням]. НазвІзданія) AS [Число підписних видань], Sum ([V в_подпіскі по виданням]. Об'єм) AS [Обсяг ведПодпіскі]

FROM [V в_подпіскі по виданнях];

4. Дослідження операційних характеристик ІДС

4.1 Опис бази даних контрольного прикладу

Для проведення випробувань створеної ІДС розроблений контрольний приклад, що дозволяє перевірити працездатність і відмовостійкість останньої.

База даних контрольного прикладу містить у собі наступні дані, що дозволяють протестувати роботу всіх запитів (рис. 3).

Малюнок 3

4.2 Аналіз результатів тестування ІДС

Набір дій оператора і результати роботи ІДС наведені в таблиці.

Дії оператора

Відповідь ІДС

1

Введення даних про клієнта з допомогою форми "ЧастПодпіска"

Дата: 23.11.2004

Номер ПО: 2

Прізвище: Іванов С.С.

Адреса: Першотравнева 45-78

Індекс: 00003

Період: 12

Код: 2

Записано.

2

Запит на знаходження обсягу відомчої передплати по організаціям

Виведена на екран таблиця, що містить відомості про наступні організаціях:

Міськсвітло, Дорстрой, МДУ ім Кулешова, ОблПочта, Податкова, Хімволокно.

3

Запит на знаходження обсягу відомчої передплати по виданнях

Виведена на екран таблиця, що містить відомості про таких виданнях:

Могилевська правда, Могильовскі відомості, копієчка, Дніпровський тиждень, Скандинавські кросворди

4

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

На екран виводиться звіт, що містить необхідні цифри.

5

Введення даних про організацію-клієнта за допомогою форми "ВедПодпіска":

Дата: 15.01.2005

Номер ПО: 1

Індекс: 63926

Організація: Дорстрой

Об'єм: 2

Період: 6

Записано.

6

Запит на знаходження періодичних видань та обсягу підписки фізичними особами

На екран виводиться таблиця, яка містить загальні цифри по виданнях: Дніпровський тиждень, Скандинавські кросворди, Могильовскі відомості, Могилевська правда.

7

Виклик таблиці "Ведподпіска" для редагування даних

Внесено і відображені в таблиці зміни в полі "Обсяг" для запису Хімволокно, 12.01.2005 з 6 на 10 шт.

8

Отримання звіту про 3-х кращих поштових відділеннях

На екран виводиться аркуш звіту з номерами 3-х кращих ПЗ в порядку убування обсягів передплати: 3,1,2.

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

Висновок

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

Це програмне забезпечення розроблене в архітектурі "клієнт-сервер" на мові SQL.

Можливо подальше вдосконалення створеного програмного забезпечення.

Список використаних літературних джерел

  1. Ляхович В.Ф. Основи інформатики. - Ростов н / Д: вид-во "Фенікс", 2000. - 608 с.

  2. Тихомиров Ю. В. Microsoft SQL Server 7.0: Розробка додатків. - СПб.: БХВ - Петербург, 2000. - 352 с.

Додаток А

Рис. А.1 - Функціональна діаграма потоків даних

Додаток Б

Рис. Б1 - ER-діаграма (фізичний рівень)

Додати в блог або на сайт

Цей текст може містити помилки.

Програмування, комп'ютери, інформатика і кібернетика | Курсова
67кб. | скачати


Схожі роботи:
Розробка багатокористувацької інформаційної системи для автоматизації роботи книжкового інтернет-магазину
Розробка автоматизованої інформаційної системи Система обліку ВАТ ЮТК
Розробка інформаційної системи Бібліотека
Розробка автоматизованої інформаційної системи
Розробка маркетингової інформаційної системи підприємства
Первинне спостереження основа інформаційної системи бухгалтерського обліку
Розробка автоматизованої інформаційної системи Бібліотека ВНЗ
Розробка шкільної інформаційної системи на основі IT-технологій
Розробка та програмна реалізація інформаційної системи Кадри
© Усі права захищені
написати до нас