Організація роботи рекламного агентства

 

Вступ

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

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

Однак, далеко не всі передбачають залучення нових клієнтів. Власне, найпоширеніший спосіб це створення реклами. Проте, як залучити клієнтів рекламному агентству? Реклама про рекламу сприймається досить саркастично з боку споживачів. Тому, в такому випадку, потрібно розробляти інший спосіб. Саме цю роль, на мою думку, і виконає моя інформаційна система - покращуючи внутрішню організацію роботи агентства, вона неминуче збільшить клієнтську базу. Адже, за словами російської письменниці-маркетолога Л.Ю. Гермогенової, «немає кращої реклами, ніж задоволений клієнт».[1]

Під час розроблення системи, основним орієнтиром буде технологія одного з методів інтеграції даних (а саме, консолідації даних) - технологія управління контентом підприємства (Enterprise Content Management або ECM). Дана технологія являє собою набір інструментів та методів, що використовується для збору, управління, накопичення, зберігання та доставки інформації усім користувачам всередині організації.[4]

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

Особливу увагу буде звернено на таку компоненту як управління потоками даних (Flow Data Managment), що при ефективній чіткій організації обовязково дасть змогу досягнути поставленої мети.

Структурне проектування

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

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

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

Для структурного аналізу заданої ПО у даній роботі застосовано пять моделей структурного проектування ІС:Flow Diagram (DFD).

ICAM Definition 0 (IDEF0).

ICAM Definition 3 (IDEF3).

Entity-Relation Diagram (ERD).

ICAM Definition 1X (IDEF1X).

Data Flow Diagram (DFD)

Діаграма потоків даних - модель проектування, графічне представлення «потоків» даних в інформаційній системі. Тобто акцент виноситься на саме дані (анкети, записи, чеки, документація і т.д.) в інформаційній системі, їх створення, перетворення і використання.

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

Рис. 1

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

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

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

Підсистема обслуговування клієнтів:

Рис. 2

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

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

Інший результат - «розроблені зразки» передаються клієнту. З них він повинен вибрати один - «затверджений зразок», який пізніше використовується як вхідний потік для виробника, на основі якого, власне, виготовляється продукт.(рівень деталізації 2).

Розроблення зразків:

Рис. 3

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

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

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

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

Рис. 4

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

Система на контекстній діаграмі, знову ж таки, виступає в ролі «чорного ящика». Тому, розглянемо нижчі рівні деталізації роботи ІС.(рівень деталізації 1)

Виготовлення реклами:

Рис. 5

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

Розроблення зразків:

Рис. 6

Definition 3 (IDEF3)

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

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

Рис. 7

інформаційний система рекламний агентство

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

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

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

Якщо зразок вибрано, то потрібно прийняти його оплату. Якщо оплата не відбулася, знову маємо варіант відмови виробництва. Якщо ж все відбулося коректно, зразок передається на виробництво.Relation Diagram (ERD)

Однією з основних частин інформаційного забезпечення є інформаційна база. Інформаційна база є сукупністю даних, організованою певним способом, яка зберігається в пам'яті обчислювальної системи у вигляді файлів, за допомогою яких задовільняються інформаційні потреби управлінських процесів і вирішуваних завдань. Розробка бази даних виконується за допомогою моделювання даних. Мета моделювання даних полягає в забезпеченні розробника ІС концептуальною схемою бази даних у формі однієї моделі або декількох локальних моделей, які відносно легко можуть бути відображені в будь-яку систему баз даних.[3]

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

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

Найбільш поширеними методами для побудови ERD-діаграм є метод Баркера і метод IDEF1Х.(метод Баркера):

Рис. 8

Основним обєктом в системі є реклама. Йому відповідає сутність «продукт». Реклама має свій унікальний ідентифікатор id, назву, тип, рахунок-фактуру, статус виконання. Однак окрім таких звичайних атрибутів, що властиві тільки їй і не існують без неї, сама реклама залежить і від інших сутностей, таких як Виробник, що є окремою зовнішньою сутністю на DFD діаграмах, Розробник, який є членом персоналу, та Клієнт, тобто замовник продукту. Останній звязок реалізовано через сутність «Реєстр» - обєкт журналювання замовлень.

Сутність «Працівник» для повнішої характеристики, використовує ще дві: персональні дані та відділ. Сутність «Оплата» є найслабше звязана, так як не кожне замовлення клієнта обовязково закінчується чемною оплатою, тому звязок зображений пунктирною лінією, тобто є необовязковим.Definition 1Х (IDEF1Х)X є методом для розробки реляційних баз даних і використовує умовний синтаксис, спеціально розроблений для зручної побудови концептуальної схеми. Концептуальною схемою називають універсальне уявлення структури даних в рамках підприємства, незалежне від кінцевої реалізації бази даних і апаратної платформи. Будучи статичним методом розробки, IDEF1X спочатку не призначений для динамічного аналізу за принципом "AS IS", тим не менш, він іноді застосовується в цій якості, як альтернатива методу IDEF1. Використання методу IDEF1X найбільш доцільне для побудови логічної структури бази даних після того, як всі інформаційні ресурси досліджені і рішення про впровадження реляційної бази даних, як частини корпоративної інформаційної системи, було прийнято. [8](IDEF1Х):

Рис. 9

Обєктно-орієнтоване проектування

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

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

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

діаграми прецедентів (Use Case Diagram);

діаграми класів (Class Diagram);

діаграми станів (Statechart Diagram);

діаграми дій (Activity Diagram);

діаграми послідовності (Sequence diagram);

діаграми взаємодій (Collaboration diagram);

діаграми розміщення (Deployment Diagram);

діаграми компонентів (Component Diagram).case diagram:

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

Діаграми прецедентів відображають елементи моделі варіантів використання.CASE DIAGRAM:

Рис. 10

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

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

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

Рис. 11

З точки зору ER проектування, діаграми класів відображають практично таку ж ідею. Тільки проектування класів безпосередньо орієнтуються на можливість реалізації цієї схематичної моделі за допомогою якоїсь з обєктно-орієнтованих мов програмування (С++, С#, Java тощо), в той час як ER проектування передує створенню реляційних баз даних, де кожна сутність - це окрема таблиця.diagram:

Діаграма станів використовується для опису поведінки об'єктів (окремих екземплярів класу). Діаграма станів є графом спеціального виду, який представляє деякий автомат. Вершинами цього графа є стани. Дуги графа служать для позначення переходів зі стану в стан. Перехід об'єкта зі стану в стан відбувається в результаті настання деякої події. Зміна станів відбувається миттєво за умови завершення дії попереднього стану, та, інколи, отримання певного вихідного результату.[2]DIAGRAM:

Рис. 12

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

Діаграми діяльності в UML використовуються для моделювання процесу виконання операцій. Їх графічна нотація багато в чому схожа на нотацію діаграми станів, оскільки на цих діаграмах також присутні позначення станів і переходів. Кожен стан на діаграмі діяльності відповідає виконанню деякої елементарної операції, а перехід в наступний стан виконується тільки при завершенні цієї операції.[5]DIAGRAM:

Рис. 13

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

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

Рис. 14

diagram:

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

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

Рис. 15

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

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

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

Рис. 16

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

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

Рис. 17

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

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

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

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

Рис. 18

Кнопки швидкого доступу реалізовують найпотрібніші елементарні функції. Наприклад, кнопка «Новий клієнт» миттєво відкриє форму, що базована на таблиці Клієнт в режимі додавання записів в окремому вікні:

Рис. 19

Після введеної потрібної інформації, вікно потрібно закрити. Якщо ж потрібно занести нову інформацію, знову можна натиснути кнопку додати.

Слід зазначити, що при введенні записів, поле id упускається, так як воно є ключовим полем, а, відповідно, унікальним. Це зроблено з метою уникнення випадкових механічних помилок повязаних з суперечністю ключів, що можуть спричинити деструкцію всієї бази даних. Тому, при натисканні кнопки «Додати», ключ для запису генерується автоматично, ґрунтуючись на механізмі автолічильника.

Аналогічна ситуація відбувається з натиском кнопки на стартовій сторінці «Нове замовлення». Вікно, що зявиться має подібний дизайн з такою ж кнопкою «Додати», яка функціонує аналогічно. Поле id також упускається з наведених вище причин.

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

Рис. 20

Потім вводиться пароль:

Рис. 21

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

Рис. 22

Після введених потрібних даних, відкривається вікно введення даних. Номери чеків виступають в ролі унікальних ідентифікаторів, тобто ключів. З натисканням кнопки «Видрукувати чек» зроблений запис автоматично передається в базу даних, в таблицю Payment:

Рис. 23

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

Рис. 24

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

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

Рис. 25

Таблиця клієнтів:

Рис. 26

Таблиця продуктів:

Рис. 27

Таблиця працівників:

Рис. 28

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

Рис. 29

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

Висновки

Результатом даної курсової роботи стала запрограмована інформаційна система для покращення організації роботи рекламного агентства. У роботі наведені усі етапи розроблення цієї системи, зокрема етапи структурного та обєктно-орієнтованого проектувань. Розроблені діаграми охоплюють усі аспекти функціонування системи: потоків даних (DFD, IDEF0, IDEF3), бази даних обслуговування клієнтів (ERD, IDEF1X), послідовності роботи (Activity Diagram, Sequence Diagram), мережевий аспект (Deployment Diagram, Component Diagram).

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

Список використаної літератури

1.Гермогенова Л.Ю. «Эффективная реклама в России: практика и рекомендации», Руспартнер Лтд, 1994 - 252 с.

2.Леоненков А.А., «Самоучитель UML», БХВ-Петербург, 2007.

.Литвин В.В., Шаховська Н.Б. «Проектування інформаційних систем» навчальний посібник, Компютинг, Магнолія - 2011, Львів, 300 с.

.Шаховська Н.Б., Конспект лекцій з курсу «Організація сховищ та просторів даних», Львів, 2013.

.James Rumbaugh, Ivar Jacobson, Grady Booch (1999). The unified modeling language reference manual (англ.). Addison Wesley Longman Inc.

6.<http://uadoc.zavantag.com/text/1719/index-9.html>

.<http://uk.wikipedia.org/wiki/IDEF0>

.<http://www.idef.com/IDEF1x.htm>

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

Больше работ по теме: