Реферат звіт про проходження навчальної практики містить

Вид материала

Содержание

Класичний приватний університет
Використаная література
Аналіз предметної області і запитів до БД
Дата поламки
Побудова концептуальної моделі
Назва зв’язку
2.2. Відображення концептуальної схеми на логічну схему
2.3. Вибір язика маніпулювання даними
4. Опис роботи програми ведення документації сервісного центру
4.1 Заповнення таблиці «КЛІЄНТИ»
4.2 Заповнення таблиці «ТЕХНІКА»
4.3 Допоміжні таблиці
4.4 Робота з SQL-запитами
Звіт про виконану роботу кожного з майстрів сервісного центру за певний період.
Рахунок для клієнта із підсумком загальної вартості обслуговування.
Відомість о техніці, що була обслугована за певний період.
Відомість о техніці, що не була обслугована за певний період.
Відомість о техніці, що була обслугована за певний період із підсумком вартості (Мал.12).
Відомість о техніці, що не була обслугована за певний період (Мал.13).
Рахунок із загальною вартістю обслуговування (Мал.14).
...
Полное содержание

Подобный материал:

Класичний приватний університет

коледж

циклова комісія «розробка програмного забезпечення»

ЗВІТ

про проходження навчальної практики

ДЛЯ СТУДЕНТІВ СПЕЦІАЛЬНОСТІ 5.080405

«ПРОГРАМУВАННЯ ДЛЯ ЕЛЕКТРОННО-ОБЧИСЛЮВАЛЬНОЇ ТЕХНІКИ І АВТОМАТИЗОВАНИХ СИСТЕМ»

Підготував:

Студент ____________ групи

_____________________________________ _________ (підпис)

(прізвище, ім’я по батькові) (підпис)

Перевірив:

Керівник практики

_____________________________________ _________

(прізвище, ім’я по батькові) (підпис)

Запоріжжя

2009

КЛАСИЧНИЙ ПРИВАТНИЙ УНІВЕРСИТЕТ

КОЛЕДЖ

ЦИКЛОВА КОМІСІЯ РОЗРОБКА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ

Затверджую

Голова циклової комісії

_______ Хрипко С.Л.

“__” ___________ 200_ р.

ЗАВДАННЯ

на навчальну практику

Завдання 1. Створити базу даних з двох таблиць формату *.mdb згідно варіанту. Встановити необхідні властивості та зв’язки.

Завдання 2. Створити додаток, який працює з двома зв’язаними таблицями бази даних.

Студент __________________________ /_________________/

(підпис)

РЕФЕРАТ

Звіт про проходження навчальної практики містить:

35 листів друкованого тексту;

15 ілюстрацій;

2 таблиці;

5 використаних джерел.

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

У якості інструменту будування бази даних був використаний Microsoft Access. Тому що від початку цю систему керування базами даних відрізняла простота використання у поєднанні з широкими можливостями по розробці закінчених додатків.

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

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

ЗМІСТ

РЕФЕРАТ

ВСТУП

ГЛОСАРІЙ

Аналіз предметної області і запитів до БД
1. Аналіз концептуальних вимог
2. Вияв інформаційних об’єктів і зв’язків між ними
3. Побудова концептуальної моделі
Логічне проектування
1. Вибір конкретної СУБД
2. Відображення концептуальної схеми на логічну схему
3. Вибір язика маніпулювання даними
Access

Таблиці
Форми
Звіти

Опис роботи програми ведення документації сервісного центру

Заповнення таблиці «КЛІЄНТИ»
Заповнення таблиці «ТЕХНІКА»
Допоміжні таблиці
Робота з SQL-запитами
Звіти

ВИСНОВОК

ВИКОРИСТАНАЯ ЛІТЕРАТУРА

ВСТУП

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

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

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

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

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

Одне з основних призначень СУБД – підтримка програмними засобами подання, що відповідає реальності.

Предметною областю називається фрагмент реальності, що описується або моделюється за допомогою БД і її додатків. У предметної області виділяються інформаційні об'єкти – ідентифікуються об'єкти реального світу, процеси, системи, поняття і т.д., відомості про які зберігаються в БД.

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

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

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

Сукупність простих даних можна об'єднати в складений даний двома способами. По-перше, можна з'єднати кілька різнотипних даних. Наприклад, дане КЛІЄНТ складається з даних ПІБ, ID-НОМЕР, ТЕЛЕФОН, АДРЕСА, СУМА. За цим принципом утворюється структурний дане або дане типу структура. Опис структури складається з переліку її складових частин, значення – зі значень складових її даних. По-друге, складене дане може об'єднувати сукупність однотипних даних (список клієнтів, список обслугованих клієнтів і т.п.). Складене дане цього типу називається масивом. В описі масиву достатньо вказати опис одного елемента, значення масиву представляється однорідним списком значень його елементів.

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

Елементи масиву можуть ідентифікуватися ключем – даними, значення якого взаємно однозначно визначають примірники елементів.

Складові типи даних являють ієрархічні зв'язки значень даних у БД. Представлення предметної області у вигляді структур даних з ієрархічними зв'язками носить назву ієрархічної моделі даних.

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

Процес побудови концептуального опису з урахуванням всіх необхідних факторів називається процесом проектування БД.

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

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

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

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

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

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

ГЛОСАРІЙ

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

Система управління базами даних (СУБД) – сукупність мовних та програмних засобів, призначених для створення, ведення і сумісного використання БД багатьма користувачами.

Банк даних (БНД) – заснована на технології БД система програмних, мовних, організаційних і технічних засобів, призначених для централізованого накопичення і колективного використання даних.

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

Електронно-обчислювальна машина (ЕОМ) – машина для проведення обчислень.

Курсор – миготлива вертикальна риска на екрані монітора.

Виділити – встановити покажчик миші (світла стрілка) на об'єкт і двічі клацнути лівою кнопкою миші.

Список, що розкривається – це згорнутий до одного рядка список, який з'являється повністю при натисканні миші на трикутнику в правій частині видимого рядка списку.

Аналіз предметної області і запитів до БД

На даному етапі необхідно проаналізувати запити користувачів, вибрати інформаційні об'єкти та їх характеристики і на основі аналізу структурувати предметну область (мал. 1).

Аналіз предметної області доцільно розбити на три фази:

Аналіз концептуальних вимог та інформаційних потреб;
Виявлення інформаційних об'єктів і зв'язків між ними;
Побудова концептуальної моделі предметної області та проектування концептуальної схеми БД.

Об'єкти реального світу	Обмеження експлуатації (технологія)			Вхідні / вихідні / документи
	Рівень реальності
Опис об’єктів предметної області			Зовнішні користувацькі подання (опис функцій додатків - задач)
	Рівень концептуального проектування
Опис предметної області на мові опису даних вибраної СУБД		Опис вхідних та вихідних форм документів і функцій обробки даних на мовах опису вхідних і вихідних форм запитів вибраної СУБД
	Рівень формальних текстів (логічне проектування)

Опис Рівень фізичної Бібліотека Бібліотека

бази реалізації вхідних і запитів

даних вих. форм

Мал. 1 Структурування предметної області

Аналіз концептуальних вимог

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

Аналіз вимог користувачів до БД (концептуальних вимог);
Виявлення наявних завдань з обробки інформації, яка повинна бути представлена в БД (аналіз додатків);
Виявлення перспективних завдань (перспективних програм);
Документування результатів аналізу.

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

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

Техніка яких марок обслуговуються центром?
Які категорії техніки обслуговуються центром?
Техніка яких моделей обслуговує центр?
Які види поломок сервісний центр ремонтує?
Чи надає сервісний центр запасні частини?
Яка вартість послуг?
Яка поточна кількість клієнтів?
Як часто оновлюється інформація в БД?
Які існують види звітів, довідок і діаграм?

Необхідно вирішити задачі:

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

На основі інформації що зберігається в БД необхідно видавати такі звіти:

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

Вияв інформаційних об’єктів і зв’язків між ними

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

При виборі інформаційних об'єктів необхідно відповісти на ряд питань:

На які таблиці можна розбити дані, що підлягають зберіганню в БД?
Яке ім'я можна присвоїти кожній таблиці?
Які найбільш цікаві характеристики (з точки зору користувача) можна виділити?
Які імена можна присвоїти обраним ознаками?

У нашому випадку передбачається завести наступні таблиці (Таб.1):

Таблиця 1. Вибір інформаційних об’єктів

ТЕХНІКА	ID-НОМЕР
	КАТЕГОРІЯ
	МАРКА
	МОДЕЛЬ
	ПОЛАМКА
	РІШЕННЯ
	ДАТА ПОЛАМКИ
	ДАТА РЕМОНТУ
	ГАРАНТІЯ
	МАЙСТЕР
	ВАРТІСТЬ
КЛІЄНТИ	ID-НОМЕР
	ПІБ
	ТЕЛЕФОН
	АДРЕСА
	ЗНИЖКА

Виділимо зв'язки між інформаційними об'єктами (Мал.2):

ТЕХНІКА		КЛІЄНТИ
ID- номер		ID- номер
Категорія		ПІБ
Марка		Телефон
Модель		Адреса
Поламка		Знижка
Рішення
Дата поламки
Дата ремонту
Гарантія
Майстер
Вартість

Малюнок 2. Зв’язки між інформаційними об’єктами

У ході цього процесу необхідно відповісти на наступні питання:

Які типи зв'язків між інформаційними об'єктами?
Яке ім'я можна присвоїти кожному типу зв'язків?
Які можливі типи зв'язків, які можуть бути використані згодом?

Спроба поставити обмеження на об'єкти, їх характеристики та зв'язки призводить до необхідності відповіді на наступні питання:

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

При проектуванні БД існують взаємозв'язки між інформаційними об'єктами трьох типів: «один до одного», «один до багатьох», «багато до багатьох».

У даному випадку зв'язок буде типу «один до багатьох» – унікальний номер клієнта буде прописуватися на записах техніки, що обслуговується.

Побудова концептуальної моделі

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

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

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

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

Наприклад:

Тип сутності – клієнт.

Екземпляр сутності – Іванов, Петров, Сідоров і ін.

У нашому прикладі Сервісний центр, Техніка, Клієнти, Майстри – сутності. Проаналізуємо зв'язки між сутностями (Таб.2):

Таблиця 2. Аналіз зв’язків між сутностями

Назва зв’язку	Між сутностями
Звертається	Клієнт	Сервісний центр
Ремонтує	Майстер	Техніка
Працює	Майстер	Сервісний центр

Тепер можна перейти до проектування інформаційної (концептуальної) схеми БД (атрибути сутностей на діаграмі не показані) (Мал.3):

Клієнт

Сервісний центр

Майстер

Техніка

Малюнок 3. Концептуальна схема БД

Логічне проектування

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

Вибір конкретної СУБД;
Відображення концептуальної схеми на логічну схему;
Вибір мови маніпулювання даними.

2.1. Вибір конкретної СУБД

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

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

Незалежність логічної структури від фізичного і призначеного для користувача подання.
Гнучкість структури бази даних – конструктивні рішення не обмежують можливості розробника БД виконувати в майбутньому найрізноманітніші запити.

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

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

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

2.3. Вибір язика маніпулювання даними

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

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

Access

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

Для роботи з СУБД Access 2003 потрібні:

IBM PC або сумісний комп'ютер з процесором 386 або вище;
Не менше 256 МВ оперативної пам'яті;
100 МВ вільної пам'яті на жорсткому диску;
Операційна система Windows 98 або вище;
Миша.

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

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

Так як Microsoft Access є сучасним додатком Windows, можна використовувати в роботі всі можливості DDE (динамічний обмін даними) і OLE (зв'язок і впровадження об'єктів).

У Microsoft Access для обробки даних базових таблиць використовується потужна мова SQL (структурована мова запитів). Використовуючи SQL можна виділити з однієї або декількох таблиць необхідну для вирішення конкретної задачі інформацію.

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

Все вище сказане дозволило зупинити вибір на СУБД Access для постановки і рішення задачі автоматизації процесу ведення документації та звітності в сервісному центрі.

3.1 Таблиці

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

Малюнок 4. Схема реляційних зв’язків

3.2 Форми

Форми – один з основних засобів для роботи з базами даних в Access – використовуються для уведення нових записів (рядків таблиць), перегляду і редагування вже наявних даних, завдання параметрів запитів і виводу відповідей на них та ін. Форми являють собою прямокутні вікна з розміщеними в них елементами керування. Існує можливість створення форм динамічно при виконанні програми, однак природним режимом їхнього створення є режим візуального конструювання (Мал.5). Вибір команди Форма в меню Вставка виводить на екран вікно Нова Форма, що дозволяє задати таблицю або запит, для яких створюється нова форма, і вказати режим її створення.

Крім створення форми «вручну», створення форми можна автоматизувати, використовуючи Майстер форм (FormWizard). Крім того, можна створити спеціальні форми, у тому числі з аркушами даних (Autoform: Datasheet), діаграмами (Chart Wizard) і зведеними таблицями (PivotTable Wizard) у форматі Excel.

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

Малюнок 5. Створення форм для вводу даних

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

У більшості випадків для створення елемента керування досить перетягнути його на форму з панелі інструментів. Кожен елемент міститься в певний розділ форми. Залежно від типу розділу (Заголовок форми, Область даних та ін) елемент керування буде з'являтися один раз, відображатися на кожній сторінці, у кожній групі записів або для кожного запису.

Якщо за якимись причинами форма вас не задовольняє, натисніть кнопку Конструктор, і ви перейдете в режим конструктора форм, у якому одержите у своє розпорядження всі засоби для створення повноцінної форми.

3.3 Звіти

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

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

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

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

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

Програма, з умовною назвою «Сервісний центр», призначена для автоматизації діловодства, ведення документації та видачі різних звітів і довідок у сервісних центрах.

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

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

Робота починається з основного вікна, на якому має відображатися назва сервісного центру (Мал. 6).

Малюнок 6. Головна форма програми

На цій формі чотири командні кнопки: «ФОРМИ ПРОСМОТРУ ТА ВВОДУ ДАНИХ», «ДОПОМІЖНІ ТАБЛИЦІ», «ЗВІТИ» і кнопка «ВИХІД», що означає завершення роботи з цим вікном, а так як це вікно основне, то завершення роботи з ним означає закінчення роботи з програмою в цілому.

4.1 Заповнення таблиці «КЛІЄНТИ»

Натисніть на кнопку «КЛІЄНТИ» на формі просмотру та вводу даних (Мал. 7).

Форма «КЛІЄНТИ» потрібна, щоб вводити в БД інформацію про клієнтів. Для більш продуктивної праці форма має цілий набор кнопок. Натиснувши кнопку «Додати запис» можна додати у БД новий запис про клієнта сервісного центру (Мал.8). Панель кнопок також має кнопки «Зберегти запис» і «Видалити запис».

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

Малюнок 7. Форми просмотру та вводу даних

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

Малюнок 8. Форма просмотру та вводу даних клієнта

4.2 Заповнення таблиці «ТЕХНІКА»

Натисніть на кнопку «ТЕХНІКА» на формі просмотру та вводу даних (Мал.7).

Форма «ТЕХНІКА» потрібна, щоб вводити в БД інформацію про техніку, що була привезена в сервісний центр (Мал.9).

Форма має цілий набор кнопок. Натиснувши кнопку «Додати запис» можна додати у БД новий запис про техніку, що потрапила до сервісного центру. Панель кнопок також має кнопки «Зберегти запис» і «Видалити запис».

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

Малюнок 9. Форма просмотру та вводу даних о техніці

Таблиця «ТЕХНІКА» пов’язується з таблицею «КЛІЄНТИ» за допомогою поля «ІДЕНТИФІКАЦІЙНИЙ НОМЕР», на формі це поле зі списком. Список ідентифікаційних номерів обирається з наявних номерів клієнтів. Інші списки: категорія техніки, торгова марка, моделі, обслуговуючий майстер, обираються з допоміжних таблиць.

За допомогою цієї форми майстер записує відомості про поламку і ремонтне рішення. Також майстер заносить у форму дані про вартість ремонту. Фактично це вартість матеріалів і запасних частин, вартість послуг майстра вираховується окремо у полі «Вартість послуг» і становить 20% від вартості ремонту.

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

4.3 Допоміжні таблиці

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

Відкрити ці таблиці для просмотру або додавання записів можна за допомогою головної форми (Мал.7). Далі треба обрати таблицю і натиснути відповідну кнопку (Мал.10).

Малюнок 10. Форма вибору допоміжних таблиць

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

4.4 Робота з SQL-запитами

Наша база даних має чотири простих запити:

Звіт про виконану роботу кожного з майстрів сервісного центру за певний період;
Рахунок для клієнта із підсумком загальної вартості обслуговування;
Відомість о техніці, що була обслугована за певний період;
Відомість о техніці, що не була обслугована за певний період.

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

Дані для цього запиту обираються з двох головних таблиць – «КЛІЄНТИ» і «ТЕХНІКА». З таблиці «ТЕХНІКА» обираються такі поля: ДАТА РЕМОНТУ, МАЙСТЕР, КАТЕГОРІЯ, МАРКА, ВАРТІСТЬ. А з таблиці «КЛІЄНТИ» обирається поле ЗНИЖКА.

Оскільки дані повинні обиратися за певний період, то у полі «ДАТА РЕМОНТУ» зашиємо умову: Between [ПОЧАТКОВА ДАТА] And [КІНЦЕВА ДАТА]. Завдяки цій умові користувачу будуть видаватися вікна для вводу початкової і кінцевої дат, що слугуватимуть періодом, за який потрібні нам дані.

Також у запиті є поле, що програмне вираховується. У цьому полі вираховується сума, що є процентною ставкою майстра. Нагадаємо, що ми встановили таку умову – вартість послуг майстра становить 20% від вартості ремонту. Крім цього постійні клієнти мають процентні знижки. Тож вираз у полі має такий вигляд: [ВАРТІСТЬ]*0,2-[ВАРТІСТЬ]*0,2*[ЗНИЖКА]/100.

Рахунок для клієнта із підсумком загальної вартості обслуговування.

Дані для цього запиту обираються з двох головних таблиць – «КЛІЄНТИ» і «ТЕХНІКА». З таблиці «КЛІЄНТИ» обираються такі поля: ID-НОМЕР, ПІБ, ТЕЛЕФОН, ЗНИЖКА. А з таблиці «ТЕХНІКА» обираються поля: КАТЕГОРІЯ, МАРКА, МОДЕЛЬ, ДАТА РЕМОНТУ, ГАРАНТІЯ, МАЙСТЕР, ВАРТІСТЬ.

Щоб обмежити пошуки певним періодом, та один клієнтом, задаються умови. У полі «ID-НОМЕР» задаємо умову: [Введіть ідентифікаційний номер:]. Користувачу буде видаватися діалог, що пропонує задати ідентифікаційний номер клієнта. А у полі «ДАТА РЕМОНТУ» запишемо умову: Between [ПОЧАТКОВА ДАТА] And [КІНЦЕВА ДАТА], завдяки якій запит буде обмежений певним періодом, наприклад днем або тижнем.

Цей запит також має обчислюване поле. У цьому полі вираховується загальна вартість ремонту. Загальна вартість складається з вартості матеріалів і вартості послуг майстра, і від неї віднімається сума, що становить знижку. Тож формула має такий вигляд: [ВАРТІСТЬ]+[ВАРТІСТЬ]*0,2-([ВАРТІСТЬ]+[ВАРТІСТЬ]*0,2)*[ЗНИЖКА]/100.

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

Для цього запиту дані беруться тільки з таблиці «ТЕХНІКА». Обираються такі поля: ID-НОМЕР, КАТЕГОРІЯ, МАРКА, МОДЕЛЬ, ДАТА РЕМОНТУ, ВАРТІСТЬ.

У якості обмежуючої умови обирається ДАТА РЕМОНТУ. Тут задається умова: Between [ПОЧАТКОВА ДАТА] And [КІНЦЕВА ДАТА], щоб відібрати дані за певний період часу.

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

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

Для цього запиту дані беруться тільки з таблиці «ТЕХНІКА». Маємо такі поля: ID-НОМЕР, КАТЕГОРІЯ, МАРКА, МОДЕЛЬ, ПОЛАМКА, РІШЕННЯ, ГАРАНТІЯ, ДАТА ПОЛАМКИ, ДАТА РЕМОНТУ.

Щоб обмежити дані задамо умови. У полі ДАТА ПОЛАМКИ: Between [ПОЧАТКОВА ДАТА] And [КІНЦЕВА ДАТА]. А у полі ДАТА РЕМОНТУ: Is Null, щоб відокремити записи, у яких ДАТА РЕМОНТУ порожня.

Цей запит не має обчислюваних полів.

Звіти

Кнопка «ЗВІТИ» на головній формі (Мал.7) відкриває форму «ЗВІТИ» (Мал.11).

Малюнок 11. Форма вибору звітів

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

Відомість о техніці, що була обслугована за певний період із підсумком вартості (Мал.12).

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

Малюнок 12. Звіт «Відомість о техніці, обслугованій за певний період»

Відомість о техніці, що не була обслугована за певний період (Мал.13).

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

Малюнок 13. Звіт «Відомість о техніці, не обслугованій за певний період»

Рахунок із загальною вартістю обслуговування (Мал.14).

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

Малюнок 14. Звіт «Рахунок із загальною вартістю»

Звіт про виконану роботу майстрів сервісного центру за певний період (Мал.15).

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

Малюнок 15. Звіт про роботу майстрів за певний період

ВИСНОВОК

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

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

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

Також були засвоєні методи написання і планування практичних та науково-технічних робіт. Під час написання роботи були повторені методи роботи з текстовим та графічним редакторами.

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

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

ВИКОРИСТАНАЯ ЛІТЕРАТУРА

Бемер С., Фратер Г., MS Access…для користувача – Київ, «BHV»,1994
Вейскас Д. Ефективна робота з Microsoft Access. С.-Пб., 1995
Семакін І.Г., Шестаков А.П. Основи програмування: Підручник – М.: Майстерність; НМЦ СПО; Вища школа, 2001
Фігурнов В.Е. IBM PC для користувача: стислий курс – М.: ІНФА-М, 2002
Microsoft Office Online (ссылка скрыта) – Довідка

Blog

Реферат звіт про проходження навчальної практики містить

Содержание