Використання автоматизованих інформаційних технологій в управлінні

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

скачати

МІНІСТЕРСТВО АГЕНСТВО ДО ОСВІТИ
Камський Державний ІНЖЕНЕРНО-економічної академії
Економічний факультет
Кафедра «Економіка і менеджмент»
Навчальна практика з інформатики та інформаційних технологій в економіці для студентів спеціальності 08050265 «Економіка і управління на підприємстві (сфера обслуговування)»
Виконав: студент групи 5122-б
Карімулліна Д.Р.
Перевірив:
старший викладач
Лук'янова А.В.
Набережні Челни.
2008

Зміст
Введення:
1. Системи розподіленої обробки даних.
1.1 Розподілена обробка даних
1.2 Термінологія
1.3 Моделі «клієнт-сервер» в технології баз даних
1.4 Дворівневі моделі
1.5 Модель сервера баз даних
1.6 Модель сервера додатків
1.7 Моделі серверів баз даних
1.8 Типи паралелізму
2. Загальна характеристика програмних засобів підготовки табличних документів.
2.1 Lotus 1-2-3.
2.2 QUATTRO PRO
2.3 Excel
3. Завдання Word.
4. Завдання Excel
5. Завдання Power Point
Висновок
Список використаної літератури:

Введення

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

1. Системи розподіленої обробки даних

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

1.2 Термінологія

Користувач БД - програма або людина, що звертається до БД на ЯМД.
Запит - процес звернення користувача до БД з метою введення, отримання або зміни інформації в БД.
Транзакція - послідовність операцій модифікації даних в БД, переводить БД з одного несуперечливого стану в інший несуперечливе стан.
Логічна структура БД - визначення БД на фізично незалежному рівні, ближче всього відповідає концептуальної моделі БД.
Топологія БД = Структура розподіленої БД - схема розподілу фізичної БД по мережі.
Локальна автономність - означає, що інформація локальної БД і пов'язані з нею визначення даних належать локального власнику і їм управляються.
Віддалений запит - запит, який виконується з використанням модемного зв'язку.
Можливість реалізації віддаленої транзакції - обробка однієї транзакції, що складається з безлічі SQL-запитів на одному віддаленому вузлі.
Підтримка розподіленої транзакції - дозволяє обробку транзакції, що складається з декількох запитів SQL, які виконуються на декількох вузлах мережі (віддалених або локальних), але кожен запит в цьому випадку обробляється тільки на одному вузлі, тобто запити не є розподіленими. При обробці однієї розподіленої транзакції різні локальні запити можуть оброблятися в різних вузлах мережі.
Розподілений запит - запит, при обробці якого використовуються дані з БД, розташовані в різних вузлах мережі.
Системи розподіленої обробки даних в основному пов'язані з першим поколінням БД, які будувалися на мультипрограмних операційних системах і використовували централізоване зберігання БД на пристроях зовнішньої пам'яті центральної ЕОМ і термінальний багатокористувацький режим доступу до неї. При цьому для користувача термінали не мали власних ресурсів - тобто процесорів і пам'яті, які могли б використовуватися для зберігання та обробки даних. Першою повністю реляційної системою, що працює в многопользовательском режимі, була СУБД SYSTEM R, розроблена фірмою IBM, саме в ній були реалізовані як мова маніпулювання даними SQL, так і основні принципи синхронізації, які застосовуються при розподіленій обробці даних, які до цих пір є базисними практично у всіх комерційних СУБД.
Загальна тенденція руху від окремих mainframe-систем до відкритих розподіленим системам, об'єднуючим комп'ютери середнього класу, отримала назву DownSizing. Цей процес зробив величезний вплив на розвиток архітектур СУБД і поставив перед їх розробниками ряд складних завдань. Головна проблема полягала в технологічній складності переходу від централізованого управління даними на одному комп'ютері і СУБД, що використала власні моделі, формати подання даних і мови доступу до даних і т. д., до розподіленої обробки даних в неоднорідному обчислювальному середовищі, що складається із з'єднаних в глобальну мережу комп'ютерів різних моделей і виробників.
У той же час відбувався зустрічний процес - UpSizing. Бурхливий розвиток персональних комп'ютерів, поява локальних мереж також зробили серйозний вплив на еволюцію СУБД. Високі темпи зростання продуктивності і функціональних можливостей PC привернули увагу розробників професійних СУБД, що призвело до їх активного поширення на платформі настільних систем.
Сьогодні взяла гору тенденція створення інформаційних систем на такій платформі, яка точно відповідала б її масштабами і завданням. Вона отримала назву RightSizing (приміщення рівно в той розмір, який необхідний).
Однак і в даний час великі ЕОМ зберігаються і співіснують з сучасними відкритими системами. Причина цього проста - свого часу в апаратне та програмне забезпечення великих ЕОМ були вкладені величезні кошти: в результаті багато хто продовжує їх використовувати, незважаючи на морально застарілу архітектуру. У той же час перенесення даних і програм з великих ЕОМ на комп'ютери нового покоління сам по собі представляє складну технічну проблему і вимагає значних витрат.

1.3 Моделі «клієнт-сервер» в технології баз даних

Обчислювальна модель «клієнт-сервер» початково пов'язана з парадигмою відкритих систем, яка з'явилася в 90-х роках і швидко еволюціонувала. Сам термін «клієнт-сервер» початково застосовувався до архітектури програмного забезпечення, яке описувало розподіл процесу виконання за принципом взаємодії двох програмних процесів, один з яких у цій моделі називався «клієнтом», а інший - «сервером». Клієнтський процес запитував деякі послуги, а серверний процес забезпечував їх виконання. При цьому передбачалося, що один серверний процес може обслужити безліч клієнтських процесів.
Раніше додаток (для користувача програма) не поділялася на частини, воно виконувалося деяким монолітним блоком. Але виникла ідея більш раціонального використання ресурсів мережі. Дійсно, при монолітному виконанні використовуються ресурси тільки одного комп'ютера, а інші комп'ютери у мережі розглядаються як термінали. Але тепер, на відміну від епохи main-фреймів, всі комп'ютери в мережі володіють власними ресурсами, і розумно так розподілити навантаження на них, щоб максимально використовувати їхні ресурси.
І як у промисловості, тут виникає древня як світ ідея розподілу обов'язків, поділу праці. Конвеєри Форда зробили свого часу прорив в автомобільній промисловості, показавши найвищу продуктивність праці саме через те, що весь процес складання був розбитий на дрібні й максимально прості операції і кожен робочий спеціалізувався на виконанні тільки однієї операції, але цю операцію він виконував максимально швидко і якісно.
Звичайно, в обчислювальній техніці не можна було безпосередньо використовувати технологію автомобільного або будь-якого іншого механічного виробництва, але ідею використовувати було можна. Однак для втілення ідеї необхідно було розробити модель розбиття єдиного монолітного додатки на окремі частини і визначити принципи взаємозв'язку між цими частинами.
Основний принцип технології «клієнт-сервер» стосовно до технології баз даних полягає в розділенні функцій стандартного інтерактивного додатку на 5 груп, що мають різну природу:
· Функції введення і відображення даних (Presentation Logic);
· Прикладні функції, що визначають основні алгоритми вирішення завдань програми (Business Logic);
· Функції обробки даних усередині програми (Database Logic),
· Функції управління інформаційними ресурсами (Database Manager System);
· Службові функції, які відіграють роль зв'язок між функціями перших чотирьох груп.
Презентаційна логіка (Presentation Logic) як частина програми визначається тим, що користувач бачить на своєму екрані, коли працює додаток. Сюди відносяться всі інтерфейсні екранні форми, які користувач бачить чи заповнює в ході роботи програми, до цієї ж частини належить все те, що виводиться користувачеві на екран як результати вирішення деяких проміжних задач або як довідкова інформація. Тому основними завданнями презентаційної логіки є:
· Формування екранних зображень;
· Читання і запис в екранні форми інформації;
· Управління екраном;
· Обробка рухів миші і натиснення клавіш клавіатури.
Деякі можливості для організації презентаційної логіки додатків надає знако-орієнтований користувальницький інтерфейс, що задається моделями CICS (Customer Control Information System) і IMS / DC фірми IBM і моделлю TSO (Time Sharing Option) для централізованої main-фреймової архітектури. Модель GUI - графічного інтерфейсу користувача, підтримується в операційних середовищах Microsoft's Windows, Windows NT, в OS / 2 Presentation Manager, X-Windows і OSF / Motif.
Бізнес-логіка, або логіка власне додатків (Business processing Logic), - це частина коду програми, яка визначає власне алгоритми вирішення конкретних завдань програми. Зазвичай цей код пишеться з використанням різних мов програмування, таких як С, C + +, Cobol, SmallTalk, Visual-Basic.
Логіка обробки даних (Data manipulation Logic) - це частина коду програми, яка пов'язана з обробкою даних у програмі. Даними управляє власне СУБД (DBMS). Для забезпечення доступу до даних використовуються мова запитів і засоби маніпулювання даними стандартної мови SQL
Зазвичай оператори мови SQL вбудовуються в мови 3-го або 4-го покоління (3GL, 4GL), які використовуються для написання коду програми.
Процесор управління даними (Database Manager System Processing) - це власне СУБД, яка забезпечує зберігання і управління базами даних. В ідеалі функції СУБД повинні бути приховані від бізнес-логіки додатка, проте для розгляду архітектури додатку нам треба їх виділити в окрему частину програми.
У централізованій архітектурі (Host-based processing) ці частини застосунків розташовуються в єдиному середовищі і комбінуються всередині однієї виконуваної програми.
У децентралізованою архітектурою ці завдання можуть бути по-різному розподілені між серверним і клієнтським процесами. Залежно від характеру розподілу можна виділити наступні моделі розподілів (див. рис. 10.3):
· Розподілена презентація (Distribution divsentation, DP);
· Віддалена презентація (Remote Presentation, RP);
· Розподілена бізнес-логіка (Remote business logic, RBL);
· Розподілене керування даними (Distributed data management, DDM);
· Віддалене управління даними (Remote data management, RDA).
Ця умовна класифікація показивет, як можуть бути розподілені окремі завдання між серверним і клієнська процесами. У цій класифікації відсутня реалізація віддаленої бізнес-логіки. Дійсно, вважається, що вона не може бути вилучена сама по собі повністю. Вважається, що вона може бути розподілена між різними процесами, які в загальному-то можуть виконуватися на різних платформах, але повинні коректно кооперуватися (взаємодіяти) один з одним.

1.4 Дворівневі моделі

Дворівнева модель фактично є результатом розподілу п'яти зазначених функцій між двома процесами, які виконуються на двох платформах: на клієнті або на сервері. У чистому вигляді майже ніяка модель не існує, однак розглянемо найбільш характерні особливості кожної дворівневої моделі.
Модель віддаленого управління даними. Модель файлового сервера
Модель віддаленого управління даними також називається моделлю файлового сервера (File Server, FS). У цій моделі презентаційна логіка і бізнес-логіка розташовуються на клієнті. На сервері розташовуються файли з даними і підтримується доступ до файлів. Функції управління інформаційними ресурсами в цій моделі знаходяться на клієнтові.
У цій моделі файли бази даних зберігаються на сервері, клієнт звертається до сервера з файловими командами, а механізм управління всіма інформаційними ресурсами, власне база мета-даних, знаходиться на клієнті.
Переваги цієї моделі в тому, що ми вже маємо поділ монопольного додатки на два взаємодіючих процесу. При цьому сервер (серверний процес) може обслуговувати безліч клієнтів, які звертаються до нього з запитами. Власне СУБД повинна знаходитися в цій моделі на клієнті.
Який алгоритм виконання запиту клієнта?
Запит клієнта формулюється в командах ЯМД. СУБД перекладає цей запит в послідовність файлових команд. Кожна файлова команда викликає перекачування блоку інформації на клієнта, далі на клієнті СУБД аналізує отриману інформацію, і якщо в отриманому блоці не міститься відповідь на запит, то приймається рішення про перекачку наступного блоку інформації і т. д.
Перекачування інформації з сервера на клієнт проводиться до тих пір, поки не буде отримана відповідь на запит клієнта.
Недоліки:
· Високий мережевий трафік, який пов'язаний з передачею по мережі безлічі блоків і файлів, необхідних додатком;
· Вузький спектр операцій маніпулювання з даними, що визначається тільки файловими командами;
· Відсутність адекватних засобів безпеки доступу до даних (захист тільки на рівні файлової системи).
Модель віддаленого доступу до даних
У моделі віддаленого доступу (Remote Data Access, RDA) база даних зберігається на сервері. На сервері же знаходиться ядро ​​СУБД. На клієнті розташовується презентаційна логіка і бізнес-логіка програми. Клієнт звертається до сервера із запитами на мові SQL.
Переваги даної моделі;
· Перенесення компонента уявлення і прикладного компонента на клієнтський комп'ютер істотно розвантажив сервер БД, зводячи до мінімуму загальне число процесів в операційній системі;
· Сервер БД звільняється від невластивих йому функцій; процесор або процесори сервера цілком завантажуються операціями обробки даних, запитів і транзакцій. (Це стає можливим, якщо відмовитися від терміналів, що не надто ресурсами, і замінити їх комп'ютерами, які виконують роль клієнтських станцій, які володіють власними локальними обчислювальними ресурсами);
· Різко зменшується завантаження мережі, так як по ній від клієнтів до сервера передаються не запити на введення-виведення в файлової термінології, а запити на SQL, і їх обсяг істотно менше. У відповідь на запити клієнт одержує тільки дані, релевантні запиту, а не блоки файлів, як в FS-моделі.
Основна перевага RDA-моделі - уніфікація інтерфейсу «клієнт-сервер», стандартом при спілкуванні програми-клієнта і сервера стає мова SQL.
Недоліки:
· Все-таки запити на мові SQL при інтенсивній роботі клієнтських додатків можуть істотно завантажити мережу;
· Так як у цій моделі на клієнті розташовується і презентаційна логіка, і бізнес-логіка програми, то при повторенні аналогічних функцій в різних додатках код відповідної бізнес-логіки повинен бути повторений для кожного клієнтського додатку. Це викликає зайве дублювання коду додатків;
· Сервер в цій моделі грає пасивну роль, тому функції управління інформаційними ресурсами повинні виконуватися на клієнті. Дійсно, наприклад, якщо нам необхідно виконувати контроль страхових запасів товарів на складі, то кожен додаток, яке пов'язане зі зміною стану складу, після виконання операцій модифікації даних, що імітують продаж або видалення товару зі складу, повинне виконувати перевірку на обсяг залишку, і в разі , якщо він менше страхового запасу, формувати відповідну заявку на поставку потрібного товару. Це ускладнює клієнтське додаток, з одного боку, а з іншого - може викликати необгрунтовану замовлення додаткових товарів кількома додатками.

1.5 Модель сервера баз даних

Для того щоб позбутися від недоліків моделі віддаленого доступу, повинні бути дотримані наступні умови:
1. Необхідно, щоб БД в кожен момент відображала поточний стан предметної області, яке визначається не тільки власне даними, але і зв'язками між об'єктами даних. Тобто дані, які зберігаються в БД, в кожен момент часу повинні бути суперечити одна одній.
2. БД повинна відображати деякі правила предметної області, закони, за якими вона функціонує (business rules). Наприклад, завод може нормально працювати тільки в тому випадку, якщо на складі є деякий достатній запас (страховий запас) деталей певної номенклатури, деталь може бути запущена у виробництво тільки в тому випадку, якщо на складі є в наявності достатньо матеріалу для її виготовлення, і т. д.
3. Необхідний постійний контроль за станом БД, відстеження всіх змін і адекватна реакція на них: наприклад, при досягненні деяким вимірюваним параметром критичного значення має відбутися відключення певної апаратури, при зменшенні товарного запасу нижче допустимої норми повинна бути сформована заявка конкретного постачальника на постачання відповідного товару.
4. Необхідно, щоб виникнення деякої ситуації в БД чітко і оперативно впливало на хід виконання прикладної задачі.
5. Однією з найважливіших проблем СУБД є контроль типів даних. На даний момент СУБД контролює синтаксично тільки стандартно-допустимі типи даних, тобто такі, які визначені в DDL (data definition language) - мові опису даних, який є частиною SQL. Однак у реальних предметних областях у нас діють дані, які несуть у собі ще й семантичну складову, наприклад, це координати об'єктів або одиниці різних метрик, наприклад робочий тиждень на відміну від реальної має відразу після п'ятниці понеділок.
Дану модель підтримують більшість сучасних СУБД: Informix, Ingres, Sybase, Oracle, MS SQL Server. Основу даної моделі становить механізм збережених процедур як засіб програмування SQL-сервера, механізм тригерів як механізм відстежування поточного стану інформаційного сховища і механізм обмежень на призначені для користувача типи даних, що іноді називається механізмом підтримки доменної структури.
У цій моделі бізнес-логіка розділена між клієнтом і сервером. На сервері бізнес-логіка реалізована у вигляді збережених процедур - спеціальних програмних модулів, які зберігаються в БД і управляються безпосередньо СУБД. Клієнтський додаток звертається до сервера з командою запуску збереженої процедури, а сервер виконує цю процедуру і реєструє всі зміни в БД, які в ній передбачені. Сервер повертає клієнту дані, релевантні його запитом, які потрібні клієнтові або для виведення на екран, або для виконання частини бізнес-логіки, яка розташована на клієнті. Трафік обміну інформацією між клієнтом і сервером різко зменшується.
Централізований контроль в моделі сервера баз даних виконується з використанням механізму тригерів. Тригери також є частиною БД.
Термін «тригер» узятий з електроніки та семантично дуже точно характеризує механізм відстеження спеціальних подій, які пов'язані зі станом БД. Тригер в БД є як би деяким тумблером, який спрацьовує при виникненні певної події в БД. Ядро СУБД проводить моніторинг всіх подій, які викликають створені і описані тригери в БД, і при виникненні відповідної події сервер запускає відповідний тригер. Кожен тригер являє собою деяку програму, яка виконується над базою даних. Тригери можуть викликати збережені процедури.
Механізм використання тригерів припускає, що при спрацьовуванні одного тригера можуть виникнути події, які викличуть спрацьовування інших тригерів. Цей потужний інструмент вимагає тонкого і узгодженого застосування, щоб не вийшов нескінченний цикл спрацьовування тригерів.
У даній моделі сервер є активним, тому що не тільки клієнт, але і сам сервер, використовуючи механізм тригерів, може бути ініціатором обробки даних у БД.
І збережені процедури, і тригери зберігаються в словнику БД, вони можуть бути використані декількома клієнтами, що. істотно зменшує дублювання алгоритмів обробки даних у різних клієнтських додатках.
Для написання збережених процедур і тригерів використовується розширення стандартної мови SQL, так званий вбудований SQL.
Недоліком даної моделі є дуже велике завантаження сервера. Дійсно, сервер обслуговує чимало клієнтів і виконує наступні функції:
· Здійснює моніторинг подій, пов'язаних з описаними тригерами;
· Забезпечує автоматичне спрацьовування тригерів при виникненні пов'язаних з ними подій;
· Забезпечує виконання внутрішньої програми кожного тригера;
· Запускає процедури, що зберігаються за запитами користувачів;
· Запускає збережені процедури з тригерів;
· Повертає необхідні дані клієнта;
· Забезпечує всі функції СУБД: доступ до даних, контроль і підтримку цілісності даних в БД, контроль доступу, забезпечення коректної паралельної роботи всіх користувачів з єдиної БД.
Якщо ми переклали на сервер більшу частину бізнес-логіки додатків, то вимоги до клієнтів в цій моделі різко зменшуються. Іноді таку модель називають моделлю з «тонким клієнтом», на відміну від попередніх моделей, де на клієнта покладалися набагато серйозніші завдання. Ці моделі називаються моделями з "товстим клієнтом».
Для розвантаження сервера була запропонована трирівнева модель.

1.6 Модель сервера додатків

Ця модель є розширенням дворівневої моделі і в ній вводиться додатковий проміжний рівень між клієнтом і сервером.
У цій моделі компоненти програми діляться між трьома виконавцями:
· Клієнт забезпечує логіку уявлення, включаючи графічний користувальницький інтерфейс, локальні редактори; клієнт може запускати ло-кальний код додатку клієнта, який може містити звернення до локальної БД, розташованої на комп'ютері-клієнті. Клієнт виконує комунікаційні функції front-end частині програми, які забезпечують доступ клієнту в локальну або глобальну мережу. Додатково реалізація взаємодії між клієнтом і сервером може включати в себе управління розподіленими транзакціями, що відповідає тих випадків, коли клієнт також є клієнтом менеджера розподілених транзакцій.
· Сервери додатків складають новий проміжний рівень архітектури. Вони спроектовані як виконання загальних незавантажувальних функцій для клієнтів. Сервери додатків підтримують функції клієнтів як частин взаємодіючих робочих груп, підтримують мережеву доменну операційне середовище, зберігають і виконують найбільш загальні правила бізнес-логіки, підтримують каталоги з даними, забезпечують обмін повідомленнями і підтримку запитів, особливо у розподілених транзакціях.
· Сервери баз даних у цій моделі займаються виключно функціями СУБД: забезпечують функції створення і ведення БД, підтримують цілісність реляційної БД, забезпечують функції сховищ даних (warehouse services). Крім того, на них покладаються функції створення резервних копій БД і відновлення БД після збоїв, управління виконанням транзакцій і підтримки застарілих (успадкованих) додатків (legacy application).
Відзначимо, що ця модель має більшу гнучкість, ніж дворівневі моделі. Найбільш помітні переваги моделі сервера додатків в тих випадках, коли клієнти виконують складні аналітичні розрахунки над базою даних, які відносяться до області OLAP-прнложеній. (On-line analytical processing.) У цій моделі велика частина бізнес-логіки клієнта ізольована від можливостей вбудованого SQL, реалізованого в конкретній СУБД, і може бути виконана на стандартних мовах програмування, таких як С, C + +, SmallTalk, Cobol. Це підвищує переносимість системи, її масштабованість.
Функції проміжних серверів можуть бути в цій моделі розподілені в рамках глобальних транзакцій шляхом підтримки ХА-протоколу (X / Open transaction interface protocol), який підтримується більшістю постачальників СУБД.

1.7 Моделі серверів баз даних

У період створення перших СУБД технологія «клієнт-сервер» тільки зароджувалася. Тому спочатку в архітектурі систем не було адекватного механізму організації взаємодії процесів типу «клієнт» і процесів типу «сервер». У сучасних же СУБД він є фактично основним і від ефективності його реалізації залежить ефективність роботи системи в цілому.
Розглянемо еволюцію типів організації подібних механізмів. В основному цей механізм визначається структурою реалізації серверних процесів, і часто він називається архітектурою сервера баз даних.
Спочатку, як ми вже відзначали, існувала модель, коли управління даними (функція сервера) і взаємодія з користувачем були поєднані в одній програмі. Це можна назвати нульовим етапом розвитку серверів БД.
Потім функції управління даними були виділені в самостійну групу - сервер, проте модель взаємодії користувача з сервером відповідала парадигмі «один-до-одного», тобто сервер обслуговував запити тільки одного користувача (клієнта), і для обслуговування декількох клієнтів потрібно було запустити еквівалентне число серверів.
Виділення сервера в окрему програму було революційним кроком, який дозволив, зокрема, помістити сервер на одну машину, а програмний інтерфейс з користувачем - на іншу, здійснюючи взаємодія між ними через мережу. Однак необхідність запуску великого числа серверів для обслуговування безлічі користувачів сильно обмежувала можливості такої системи.
Для обслуговування великого числа клієнтів на сервері має бути запущено велику кількість одночасно працюючих серверних процесів, а це різко підвищувало вимоги до ресурсів ЕОМ, на якій запускалися всі серверні процеси. Крім того, кожний серверний процес у цій моделі запускався як незалежний, тому якщо один клієнт сформував запит, який був тільки, що виконаний іншим серверним процесом для іншого клієнта, то запит, тим не менш, виконувався повторно. У такій моделі вельми складно забезпечити взаємодію серверних процесів. Ця модель найпростіша, і історично вона з'явилася першою.
Проблеми, що виникають в моделі «один-до-одного», вирішуються в архітектурі «систем з виділеним сервером», який здатний обробляти запити від багатьох клієнтів. Сервер єдиний володіє монополією на управління даними і взаємодіє одночасно з багатьма клієнтами. Логічно кожен клієнт зв'язаний з сервером окремої ниткою («thread»), або потоком, по якому пересилаються запити. Така архітектура отримала назву многопотоковой односерверной («multi-threaded»).
Вона дозволяє значно зменшити навантаження на операційну систему, що виникає при роботі великої кількості користувачів («trashing»).
Крім того, можливість взаємодії з одним сервером багатьох клієнтів дозволяє повною мірою використовувати колективні об'єкти (починаючи з відкритих файлів і закінчуючи даними з системних каталогів), що значно зменшує потреби в пам'яті і загальне число процесів операційної системи. Наприклад, системою з архітектурою «один-до-одного» буде створено 100 копій процесів СУБД для 100 користувачів, тоді як системі з многопотоковой архітектурою для цього знадобиться тільки один серверний процес.
Проте таке рішення має свої недоліки. Так як сервер може виконуватися тільки на одному процесорі, виникає природне обмеження на застосування СУБД для мультипроцесорних платформ. Якщо комп'ютер має, наприклад, чотири процесори, то СУБД з одним сервером використовують тільки один з них, не завантажуючи залишилися три.
У деяких системах ця проблема вирішується введенням проміжного диспетчера. Подібна архітектура називається архітектурою віртуального сервера («virtual server»).
У цій архітектурі клієнти підключаються не до реального сервера, а до проміжного ланці, званому диспетчером, який виконує тільки функції диспетчеризації запитів до актуальних серверів. У цьому випадку немає обмежень на використання багатопроцесорних платформ. Кількість актуальних серверів може бути погоджено з кількістю процесорів в системі.
Однак і ця архітектура не позбавлена ​​недоліків, тому що тут у систему додається новий шар, який розміщується між клієнтом і сервером, що збільшує витрату ресурсів на підтримку балансу завантаження актуальних серверів («load balancing») і обмежує можливості управління взаємодією «клієнт-сервер» . По-перше, стає неможливим направити запит від конкретного клієнта конкретного сервера, по-друге, сервери стають рівноправними - немає можливості встановлювати пріоритети для обслуговування запитів.
Подібна організація взаємодії клієнт-сервер може розглядатися як аналог банку, де є кілька вікон касирів, і спеціальний банківський службовець - адміністратор залу (диспетчер) направляє кожного знову прийшов відвідувача (клієнта) до вільного касира (актуальному серверу). Система працює нормально, поки всі відвідувачі рівноправні (мають рівні пріоритети), проте варто лише з'явитися відвідувачам з вищим пріоритетом, які повинні обслуговуватися в спеціальному вікні, як виникають проблеми. Облік пріоритету клієнтів особливо важливий в системах оперативної обробки транзакцій, однак саме цю можливість не може надати архітектура систем з диспетчеризацією.
Сучасне рішення проблеми СУБД для мультипроцесорних платформ полягає в можливості запуску декількох серверів бази даних, в тому числі і на різних процесорах. При цьому кожен із серверів повинен бути багатопотокових. Якщо ці дві умови виконані, то є підстави говорити про многопотоковой архітектурі з декількома серверами.
Вона також може бути названа багатонитковою мультисерверної архітектурою. Ця архітектура пов'язана з питаннями розпаралелювання виконання одного користувача запиту кількома серверними процесами.
Існує кілька можливостей розпаралелювання виконання запиту. У цьому випадку для користувача запит розбивається на ряд підзапитів, які можуть виконуватися паралельно, а результати їх виконання потім об'єднуються в загальний результат виконання запиту. Тоді для забезпечення оперативності виконання запитів їх вкладені запити можуть бути спрямовані окремим серверним процесам, а потім отримані результати об'єднані в загальний результат. У даному випадку серверні процеси не є незалежними процесами, такими, як розглядалися раніше. Ці серверні процеси прийнято називати нитками (treads), і управління нитками безлічі запитів користувачів вимагає додаткових витрат від СУБД, проте при оперативній обробці інформації в сховищах даних такий підхід є найбільш перспективним.

1.8 Типи паралелізму

Розглядають кілька шляхів розпаралелювання запитів.
Горизонтальний паралелізм. Цей паралелізм виникає тоді, коли збережена в БД інформація розподіляється по декількох фізичних пристроїв зберігання - кільком дискам. При цьому інформація з одного відносини розбивається на частини по горизонталі. Цей вид паралелізму іноді називають розпаралелюванням або сегментацією даних. І паралельність тут досягається шляхом виконання однакових операцій, наприклад фільтрації, над різними фізичними збереженими даними. Ці операції можуть виконуватися паралельно різними процесами, вони незалежні. Результат: виконання цілого запиту складається з результатів виконання окремих операцій.
Час виконання такого запиту при відповідному сегментації даних істотно менше, ніж час виконання цього ж запиту традиційними способами одним процесом.
Вертикальний паралелізм. Цей паралелізм досягається конвеєрним виконанням операцій, які становлять запит користувача. Цей підхід вимагає серйозного ускладнення в моделі виконання реляційних операцій ядром СУБД. Він припускає, що ядро ​​СУБД може зробити декомпозицію запиту, базуючись на його функціональних компонентах, і при цьому ряд підзапитів може виконуватися паралельно, з мінімальною зв'язком між окремими кроками виконання запиту.
Дійсно, якщо ми розглянемо, наприклад, послідовність операцій реляційної алгебри:
R5 = R1 [А, С]
R6 = R2 [ABD]
R7 = R5 [A> 128]
R8 = R5 [A] R6
то операції першу і третю можна об'єднати і виконати паралельно з операцією два, а потім виконати над результатами останню четверту операцію.
Загальний час виконання подібного запиту, звичайно, буде істотно менше, ніж при традиційному способі виконання послідовності з чотирьох операцій.
І третій вид паралелізму є гібридом двох раніше розглянутих.
Найбільш активно застосовуються всі види паралелізму в OLAP-додатках, де ці методи дозволяють істотно скоротити час виконання складних запитів над дуже великими обсягами даних.

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

Електронна таблиця (табличні процесори) - пакети програм, призначені для обробки табличним чином організованих даних. Користувач має можливість за допомогою засобів пакету здійснювати різноманітні обчислення, будувати графіки, управляти форматом введення-виведення даних, компонувати дані, проводити аналітичні дослідження і т.п.
У теперішній час найбільш популярними й ефективними пакетами даного класу є: Excel, Improv, Quattro Pro, Lotus 1-2-3.

2.1 Lotus 1-2-3

З'явилася в 1982 р . на ринку програмування коштів Lotus 1-2-3 був першим табличним процесором, інтегрованим у своєму складі, крім звичайних інструментів, графіку і можливість роботи з системами управління базами даних. Оскільки Lotus був розроблений для комп'ютерів типу IBM, він зробив для цієї фірми той же, що VisiCalc свого часу зробив для фірми Apple. Далі на ринку вийшли нові електронні таблиці, такі як VP Planner компанії Paperback Software і Quattro Pro компанії Borland International, які запропонували користувачеві практично той же набір інструментарію, але за значно нижчими цінами.

2.2 QUATTRO PRO

Процесор QUATTRO PRO майже всіх версій володіє такими перевагами, як:
- Надзвичайно зручний користувальницький інтерфейс, що дає можливість подання даних у найрізноманітнішої і нестандартної форми і забезпечує широкі можливості по обробці даних;
- Багатовіконний режим роботи, що дозволяє організувати на екрані зручну робоче середовище і створювати системи пов'язаних електронних таблиць (ЕТ)
- Доступ до будь-яких, необмеженим за розмірами зовнішніх баз даних, створених на основі найбільш популярних систем управління базою даних (СКБД);
- Висока якість друку вихідних документів; можливість побудови різноманітних графіків, діаграм, малюнків, а також можливість створення слайд-фільмів для презентації готових результатів і додатків;
- Легкість створення програм автоматичної обробки інформації в таблицях і зручні засоби відладки і редагування створених програм.
Основна увага в даній роботі буде приділено наступних питань:
- Оформлення для виводу на принтер вихідних документів з високою якістю друку;
- Графічне представлення отриманих результатів і висновок їх на принтер у складі вихідних документів;
- Способи графічного аналізу результатів.

2.3 Excel

Одним з найбільш розповсюджених засобів роботи з документами, що мають табличну структуру, є Microsoft Excel.
Ця програма призначена для роботи з таблицями даних, переважно числових. При формуванні таблиці виконують введення, редагування та форматування текстових і числових даних, а так само формул. Наявність засобів автоматизації полегшує ці операції. Створена таблиця може бути виведена на друк.
Документ Excel називається робочою книгою. Робоча книга являє собою набір робочих аркушів, кожний з яких має табличну структуру і може містити одну або декілька таблиць. У вікні документа в програмі Excel відображається тільки поточний робочий лист, з яким і ведеться робота. Кожен робочий лист має назви, яка відображається на ярличку листа, який відображається в його нижній частині. За допомогою ярликів можна перейти до інших робочих листів, що входять в ту ж саму робочу книгу. Щоб перейменувати робочий лист, треба двічі клацнути на його ярличку.
Робочий лист складається з рядків і стовпців. Стовпці озаглавлені великими латинськими літерами і, далі, з двох літер комбінаціями. Всього робочий лист може містити до 256 стовпців, пронумерованими від A до ΙV. Рядки послідовно нумеруються цифрами, від 1 до 65 536 (максимально допустимий номер рядка).
На перетині стовпчиків і рядків утворюється комірки таблиці. Вони є мінімальними елементами для зберігання даних. Позначення окремої комірки поєднує в собі номера стовпця і рядка (у цьому порядку), на перетині яких вона розташована, наприклад: A1 або DE234. Позначення осередку (її номер) виконує функції її адреси. Адреси клітинок використовуються при записі формул, що визначають взаємозв'язок між значеннями, розташованими в різних осередках.
Одна з комірок завжди є активною і виділяється рамкою активної комірки. Ця рамка в програмі грає роль курсору. Операції введення і редагування завжди виробляються в активній клітинці. Перемістити рамку активної комірки можна за допомогою курсорних клавіш або покажчика миші.
На дані, розташовані в сусідніх комірках, можна посилатися у формулах як єдине ціле. Таку групу осередків називають діапазоном.
Окрема осередок може містити дані, що відносяться до одного з трьох типів: тексту, число або формула, - а так само залишатися порожньою. Програма при збереження робочої книги записує у файл тільки прямокутну область робочих листів, що примикають до лівого верхнього кута (осередок A1) і містити всі заповнені комірки.
Тип даних, що розміщуються в осередку, визначається автоматично при введенні. Якщо ці дані можна інтерпретувати як число, програма так і робить. В іншому випадку дані розглядаються як текст. Введення формули завжди починається з символу знаку рівності.
Зміст електронної таблиці: формули, посилання і осередки, абсолютні та відносні посилання, автоматизація введення (автозавершення, автозаповнення), надбудови, побудова діаграм і графіків, і багато іншого.

3. Завдання Word

Створення багаторівневого списку і робота з ним.
Порядок роботи:
1.Створення таблиці - Таблиця → Вставити → Таблиця → Кількість стовпців - 4; Число рядків - 2;
У першій і в другому рядку таблиці введені заголовки: «Класифікація прикладного програмного забезпечення, Початковий вигляд списку, Змінений вигляд списку».
2.Самий швидкий спосіб створення багаторівневого списку - ввести текст, а потім перетворити його на багаторівневий список за допомогою команди меню Формат → Список → Багаторівневий.
3. Щоб змінити вигляд списку, копіюється початковий вигляд списку у відповідну клітинку таблиці праворуч, і виконуються дії:
а) вибираємо команду меню Формат → Список;
б) у діалоговому вікні Список вкладку відповідного типу списку - Багаторівневий;
в) клацанням на кнопці Змінити відкриваємо діалогове вікно Зміна багаторівневого списку і в ньому встановлюємо необхідні параметри для змінного списку.
4. При зміна маркера для маркованого списку, у вікні зміна клацаємо Знак, і в розкривним списку Шрифт вибираємо новий вид маркера.
5. Перед тим, як внести зміни в багаторівневий список, встановлюємо курсор перед текстом списку в правій комірці і виконуємо команду Вставка → Розрив → Новий розділ → на поточній сторінці, а потім приступаємо до перетворення списку.
6. При зміна оформлення рівня багаторівневого списку вибираємо номер цього рівня в розкривним списку Рівень діалогового вікна Зміна багаторівневого списку і встановлюємо необхідні параметри (списки, що розкриваються: нумерація:, почати з:, попередній рівень:, положення номера на:, положення тексту - відступ).
7. Якщо рівень має номер, він формується автоматично, і включає номери всіх рівнів, що передують даному. Номери рівнів розділені крапкою.
Так, номер другого рівня формується таким чином: першою цифрою номера рівня є значення номера Рівень 1 розкривного списку попередній рівень:, за ним йде «.» І далі значення поля почати з:, в якому указується початкове значення номера для 2-го (вибраного ) рівня. Номер третього рівня має такі елементи, розділені крапкою: номер елемента Рівень 1 з розкривного списку попередній рівень:, номер елемента Рівень 2 з розкривного списку попередній рівень:, значення поля почати з:, в якому зазначений початковий номер 3-го (обраного) рівня . Формується номер рівня відображається в полі Формат номера. Можна змінити його при необхідності, слідуючи вищеописаному. Якщо оформляється рівень має маркер, він вибирається із списку, нумерація. У разі відсутності потрібного символу, виберіть елемент списку Новий маркер, а потім і сам символ.
8. Після перетворення виділених абзаців у багаторівневий список всі елементи списку мають один і той же (перший) рівень. Зниження рівня елементів створеного багаторівневого списку виконується або клацаннями на кнопці Знизити рівень → панелі інструментів режиму Структура (команда Вид → Структура) або клацаннями на кнопці Збільшити відступ панелі інструментів Форматування (кількість клацань на один менше, ніж номер самого рівня). Для підвищення рівня служить кнопка Зменшити відступ панелі інструментів Форматування, або кнопка Підвищити рівень панелі інструментів режиму Структура.

Тип списку
Багаторівневий
Класифікація прикладного програмного забезпечення
Початковий вигляд списку
Змінений вигляд списку
1. Загального призначення
1.1. Редактори:
1.1.1. текстові;
1.1.2. текстові процесори;
1.1.3. графічні.
1.2. Електронні таблиці.
1.3. СУБД.
1.4. Експертні системи та штучний інтелект.
2. Методо-орієнтовані.
2.1. Математичного програмування.
2.2. Математичної статистики.
2.3. Мережевого планування і управління
2.4. Теорії масового обслуговування.
3. Спеціалізовані.
3.1. Проблемно-орієнтовані
3.1.1. банківські;
3.1.2. бухгалтерського обліку;
3.1.3. фінансового менеджменту;
3.1.4. правові довідкові системи.
1) Загальних призначення.
a) Редактори:
ü текстові;
ü текстові процесори;
ü графічні.
b) Електронні таблиці.
c) СУБД
d) Експертні системи та штучний інтелект.
2) Метод-орієнтовані.
a) Математичного програмування.
b) Математичної статистики.
c) Мережевого планування і управління.
d) Теорії масового обслуговування.
3) Спеціалізовані
a) Проблемно-орієнтовані
ü банківські;
ü бухгалтерського обліку;
ü фінансового менеджменту;
ü правові довідкові системи.

4. Завдання Excel

Завдання № 1. Побудова зведеної таблиці
Зведені таблиці призначені для узагальнення, аналізу й обробки даних. За замовчуванням зведена таблиця створюється на основі даних у таблицях Excel, однак вона може бути створена на основі інших джерел даних, у тому числі зовнішніх. Одне з головних застосувань зведених таблиць - створення підсумкових таблиць для декількох категорій даних, коли по кожній категорії підводяться проміжні підсумки. Після створення зведеної таблиці можна швидко побудувати діаграму, що відображає підсумкові дані.
Хід роботи:
1. Будуємо вихідну таблицю, виділяємо будь-яку клітинку у списку, для якого потрібно створити зведену таблицю, і вибираємо команду Дані → Зведена таблиця.
2. У першому вікні майстра зведених таблиць і діаграм встановлюємо перемикач Вид створюваного звіту в положення зведена таблиця.
3. Серед положень перемикача Створити таблицю на основі даних, що знаходяться вибираємо потрібний: У списку або базі даних Excel, У зовнішньому джерелі даних, У декількох діапазонах консолідації, В іншій зведеної таблиці або діаграми і натискаємо Далі.
4. У полі Діапазон вводимо діапазон комірок і натискаємо кнопку Далі.
5. Вказую місце розташування зведеної таблиці, натискаю кнопку Макет і ставлю порядок розташування рядків і стовпців у таблиці. В область даних перетягують кнопки тих полів, за якими підводяться підсумки (сумарне значення нарахувань, всього утримано, всього нараховано). В області даних два рази клацаю лівою кнопкою миші на кнопці поля і в списку Операція вибираю застосовувану операцію: Сума, Кількість значень, Середнє, Максимум, Мінімум, Добуток, Кількість чисел, Зміщене відхилення, незміщене відхилення, Зміщена дисперсія, несмещенная дисперсія.
6. У рядках розміщую П.І.Б. працівників, у стовпцях Дату, як фільтр використовую Відділ.
7. Завершивши створення макету, натискаю кнопку ОК. Додаткові параметри для зведеної таблиці можна задати, натиснувши кнопку Параметри і встановивши потрібні прапорці.
Завдання № 2 Обчислення рівня осідання коштів, що надійшли на рахунки за вкладами комерційного банку
Хід роботи:
1. Заповнюємо в табличному варіанті вихідні дані, останній рядок вихідної таблиці розраховуємо за формулою: US (i) = (SK (i) - SN (i)) / P (i) * 100, де i = [1, N], N - кількість банків.
2. Сортуємо документ за спаданням і за зростанням рівня осідання коштів комерційного банку:
а) виділяємо клітинку таблиці і вибираємо команду Дані → Сортування;
б) у списку Сортувати за вказуємо назву стовпця, в якому потрібно виконати сортування;
в) встановлюємо перемикач в потрібне положення: За зростанням, За зменшенням;
г) натискаю кнопку ОК.
3. За допомогою команди Розширений фільтр формують новий документ зі структурою вихідного документа, але містить інформацію тільки про тих банках, рівень осідання коштів в яких вище середнього рівня цього показника у вихідному документі по всіх чотирьох банків:
а) виділяємо клітинку таблиці і вибираємо команду Дані → Автофільтр → Розширений фільтр;
б) у діалоговому вікні виділяємо вихідний діапазон і діапазон умов, який заздалегідь підготували у вигляді таблиці (тому що нам потрібно знайти інформацію про банки, рівень осідання коштів в яких вище середнього рівня цього показника у вихідному документі по всіх чотирьох банків; то ми на початку, встановлюємо курсор в осередок і викликаємо Вставка - Функція - середнє значення і задаємо для цієї функції критерій, за яким буде шукатися середнє значення);
г) натискаємо кнопку ОК.
4. Створення діаграм:
Типом діаграми, що використовується за умовчанням є, гістограма. Діаграму можна побудувати за допомогою значка «Діаграма» на стандартній панелі інструментів, виконуючи по кроках вимоги майстра діаграм. Вихідні дані попередньо повинні бути виділені. На третьому кроці діаграми необхідно вказати назву діаграми, назва осей.
Зміна значень, що відображаються на діаграмі.
Значення, що відображаються на діаграмі, пов'язані з листом, з якого створювалася діаграма. При зміні даних на аркуші діаграма оновлюється автоматично.
Додавання даних до діаграми.
Найбільш простим способом додавання даних до діаграми є їх копіювання і вставка з таблиці на аркуш діаграми.
Зміна підписів, заголовків та інших текстів діаграми
Велика частина текстів діаграми, наприклад підписи поділок осі категорій, імена рядів даних, текст легенди та підписи даних пов'язана з осередками робочого аркуша (таблиці), використовуваного для створення діаграми. Якщо змінити текст цих елементів на діаграмі, вони втратять зв'язок з осередками аркуша. Щоб зберегти зв'язок, слід змінювати текст цих елементів на раб. Аркуші, тобто у самій таблиці. Змінимо підписи поділок на осі категорій. Для зміни підписи поділок на осі категорій (вісь Х) вкажіть клітинку, яка містить змінну підпис, введіть нове значення, а потім натисніть клавішу Enter.
Зміна тексту легенди
Для цього виберіть клітинку в таблиці, введіть нове ім'я та натисніть Enter. Зміни будуть відображені на діаграмі.
Лінії тренду на діаграмі
Лінії тренда зазвичай використовуються в задачах прогнозування. Лінію тренда можна продовжити вперед або назад, екстраполювати її за межі, в яких дані вже відомі, і показати тенденцію їх зміни. Лініями тренда можна доповнити ряди даних, представлених на плоских діаграмах з областями, лінійчатих діаграмах, гістограмах, графіках, діаграмах. Не можна доповнити лініями тренду ряди даних на об'ємних діаграмах. Для створення тренду на діаграмі потрібно виділити діаграму, виконати в меню «Діаграма» команду «Додати лінію тренду», вказати, для якого ряду, і вибрати тип лінії тренду. Якщо необхідно показати прогноз і рівняння лінії тренду, можна виконати вкладки «Параметри». Тут же можна відзначити пункт «Показувати рівняння лінії тренду на діаграмі». Побудуйте кругову діаграму: показую всі потрібні значення, і відформатуй діаграму. За допомогою контекстного меню на самій круговій діаграмі покажу числові значення секторів за допомогою Команди Формат рядів даних - Підписи даних - Значення. А при створення змішаної діаграми заходжу у вкладку нестандартні діаграми і знаходжу ту, яка потрібна мені.

5. Завдання Power Point

Етапи створення презентації:

1. Визначити кількість слайдів - 5 слайдів
2. Розробити структуру слайдів:
1 Слайд - титульний лист (назва, організаційно-правова форма підприємства, форма власності, основний вид продукції або вид діяльності, коротка історія створення і становлення, штатна чисельність працівників);
2 Слайд - укрупнена структура підприємства;
3 Слайд - зображення і основні характеристики виробленої продукції, основні ринки, на яких працює підприємство, основні конкуренти;
4 Слайд - об'ємні, вартісні показники роботи підприємства, відносні показники ефективності діяльності в таблицях і на діаграмах за кілька періодів (не менше 3 періодів);
5 Слайд - місія, головні цілі роботи підприємства та основні напрямки його розвитку в різних сферах (матеріальна, фінансова, соціальна).
Створення титульного аркуша презентації.
1. Запускаю програму MS Power Point. У правій частині вибираю пункт «Нова презентація». Потім з'являється область, яка містить різні варіанти розмітки слайдів. Вибираю найперший тип - титульний слайд. На екрані з'явиться перший слайд з розміткою для введення тексту. Встановіть вид екрану Звичайний (Вигляд / Звичайний). І розмітку (у правій частині) - «заголовок і текст».
2. Вибираю меню Формат / Оформлення слайду. Праворуч активізується вікно з шаблонами, виберіть будь-який.
3. Вводжу з клавіатури текст заголовка «Державна освітня установа вищої професійної освіти« Камська державна інженерно - економічна академія »(ІНЕКО), що здійснюють підготовку у сфері професійної освіти і науки». У нижню рамку введіть текст у вигляді списку, який містить інформацію про історію створення ІНЕКО.
4. Збережіть створений файл у своїй папці з ім'ям «Моя презентація».
Створення другого слайда презентації - тексту зі списком.
Виберете команду Вставка / Створити слайд. І розмітку (у правій частині) - «заголовок і текст». У верхній рядок введу «укрупнена структура підприємства». У нижню рамку введіть текст у вигляді списку (про факультетах, про те що входить до складу академії).
Створення третього слайда презентації
Виконайте команду Вставка - Новий слайд. Виберете розмітку «тільки заголовок» і натисніть ОК. Відкрила панель малювання і намалювала схеми такого вигляду: навчає, академія навчає в ....
Створення четвертого слайда презентації
Виконайте команду Вставка - Новий слайд. Вставляю діаграму і заповнюю її, в ній показую приріст студентів у ІНЕКО за останні три роки.
Створення п'ятого слайда презентації
Виконайте команду Вставка - Новий слайд. У ньому в графі текст викладаю місію та основні цілі академії.
Додаткові ефекти
Виберете меню Показ слайдів / Почати показ. Почнеться демонстрація слайдів. Під час демонстрації для переходу до наступного слайда використовую ліву кнопку миші або клавішу Enter. Після закінчення демонстрації натискаю клавішу Esc для переходу у звичайний режим екрану програми.
Встановлюю курсор на перший слайд. Для налаштування анімації виділяю заголовок, і виконайте команду Показ слайдів / Настройка анімації. Встановлюю параметри налаштування анімації і вибираю ефект - виліт ліворуч.
Для заголовка другого слайда наклала ефект анімації - поява зверху по словах. Спосіб переходу між слайдами визначає, яким чином буде відбуватися поява нового слайда при демонстрації презентації.
У меню Показ слайдів вибираю команду Зміна слайдів. Вибираю наступні види ефектів:
Ефект - жалюзі вертикальні
Звук - дзвіночки
Швидкість - середня
Зміна слайдів - автоматично через 10 секунд.
Після вибору всіх параметрів зміни слайдів, натискаю кнопку «застосувати до всіх слайдів». Для включення до слайд номера слайда та поточної дати виконую команду Вставка / Номер слайда. У вікні установливают команду: Включити в слайд «дату і час», встановивши галочку у вікні «автопоновлення». А також поставила галочку у вікні «номер слайда». Після цього натиснула кнопку «застосувати до всіх».

Висновок

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

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

1. Інформатика: Учеб. для вузів .- М.: Висш.шк., 2000. Острейковскій В.А.
2. Інформатика: Учеб.3-е перераб.ізд. / Под ред. проф. Н.В. Макарової .-.: Фінанси і статистика, 1999.
3. Комп'ютерний сайт www.5ballov.ru
4. Інформатика. Базовий курс. 2-е вид. / Под ред. С. В. Симоновича. - Пітер, 2006.
5. Бази даних: Навчальний посібник / Під загальною редакцією професора Ахмадеева І.А. - Набережні Човни: Кампо, 2004.
6. Курс лекції, та методичних вказівок до нього Лисанова Д.М., 2007р, ІНЕКО.
Додати в блог або на сайт

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

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


Схожі роботи:
Роль інформаційних технологій в управлінні підприємством
Правове регулювання створення та використання інформаційних технологій інформаційних систем
Використання новітніх інформаційних технологій
Використання інформаційних технологій у навчанні геометрії
Використання інформаційних технологій в навчальному процесі
Основні напрямки використання інформаційних технологій
Використання інформаційних технологій в системах управління
Використання інформаційних технологій Інтернет в фармації
Використання інформаційних технологій на уроках математики
© Усі права захищені
написати до нас