База даних "Теорія та практика прикладного програмування"
Проектування інформаційної системи; концептуальне (інфологічне) проектування, побудова ER-діаграми, нормалізація даних. Даталогічне проектування баз даних, фізичне проектування інформаційних систем. СУБД Access: об'єкти, створення таблиць, запитів, форм.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | курсовая работа |
| Язык | украинский |
| Дата добавления | 09.01.2010 |
| Размер файла | 13,9 M |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
2
2
Міністерство освіти і науки України
Українська інженерно-педагогічна академія
Гірничий факультет
Кафедра інформаційних технологій
ПОЯСНЮВАЛЬНА ЗАПИСКА
до курсової роботи
з дисципліни «Проектування та експлуатація інформаційних систем»
на тему:
База даних “Теорія та практика прикладного програмування”
Виконав ст. гр. ДГ-К7-1
Коновалов С. Г.
Керівник Лавриненко Н. В.
Стаханов
2009
Реферат
Курсовий проект: 38 рис., 7 табл., 0 додатків, 10 джерел.
Об'єктом дослідження є довідкова інформація, що міститься у певних главах посібника з прикладного програмування («Культин Н.Б. Основы программирования в Delphi 7. - СПб.: БХВ-Петербург, 2003. - 608 с.: ил.» Сторінки: 123-138, 183-203).
Предметом дослідження є проектування та експлуатація інформаційних систем.
Метою дослідження є закріплення теоретичних знань, отриманих при вивченні навчальної дисципліни «Проектування та експлуатація інформаційних систем» і придбання навичок у використанні сучасних інформаційних технологій для виготовлення програмних продуктів, що підтримують функціонування інформаційних систем.
Методи дослідження. Для вирішення поставлених задач застосовані:
· загальнонаукові методи: теоретичного пошуку; концептуально-порівняльного аналізу, визначення теоретичних і прикладних аспектів дослідження, визначення структури і змісту підготовки;
· емпіричні методи: дослідження предметної області, дослідження об'єкту, що вивчається у штучно створених для нього умовах, порівняння об'єкту, що досліджується з аналогом;
· метод створення інформаційної системи довідкового призначення. Введення даних до ІС згідно моделі сутність-зв'язок з обов'язковою нормалізацією даних; створення запитів та форм.
Наукова новизна дослідження полягає у тому, що в якості інформаційного джерела для бази даних був обраних посібник з прикладного програмування «Культин Н.Б. Основы программирования в Delphi 7».
Теоретична значущість дослідження: розроблена інформаційна система, на базі якої були засвоєні теоретичні відомості про інформацію, її обробку та зберігання; етапи проектування ІС, алгоритм та необхідність нормалізації; загальні відомості про роботу з базами даних та їх супроводження у середовищі MS Access.
Практична значущість була розроблена інформаційна система, що дозволяє отримувати у зручному, простому для сприйняття, та, як наслідок, зрозумілому користувачеві вигляді довідкову інформацію з посібника, яка може бути корисною при вирішенні задач, пов'язаних з прикладним програмуванням.
Результати дослідження можуть бути використані в інженерних та інженерно-педагогічних ВНЗ.
БАЗА ДАНИХ, АДМІНІСТРАТОР, КОРИСТУВАЧ, КІНЦЕВИЙ КОРИСТУВАЧ, КІНЦЕВИЙ КОРИСТУВАЧ, ПРЕДМЕТНА ОБЛАСТЬ, ПРОЕКТУВАННЯ БД, КОНЦЕПУТАЛЬНЕ ПРОЕКТУВАННЯ, СУТНІСТЬ, АТРИБУТ, ЗВ'ЯЗОК, ER-ДІАГРАМА, МОДЕЛЬ «СУТНІСТЬ-ЗВ'ЯЗОК», НОРМАЛІЗАЦІЯ, ФІЗИЧНЕ ПРОЕКТУВАННЯ, СУБД, ТАБЛИЦЯ, ЗАПИТ, ФОРМА, ЗВІТ, МАКРОС, МОДУЛЬ
Зміст
Вступ
1. Опис предметної області
2. Проектування інформаційної системи
2.1 Концептуальне (інфологічне) проектування
2.1.1 Побудова ER-діаграми
2.1.2 Нормалізація даних
2.2 Даталогічне проектування баз даних
2.3 Фізичне проектування інформаційних систем
2.3.1 СУБД Access
2.3.2 Об'єкти Access
2.3.3 Створення таблиць
2.3.4 Створення запитів
2.3.5 Створення форм
3. Інструкція користувача
Висновки
Перелік використаних джерел
Вступ
Бази даних (БД) у наш час складають основу комп'ютерного забезпечення інформаційних процесів, що входять практично до усіх сфер людської діяльності.
Дійсно, процеси обробки інформації мають загальну природу і спираються на опис фрагментів реальності, виражених у вигляді сукупності взаємопов'язаних даних. Бази даних є ефективним засобом подання структур даних і маніпулювання ними. Концепція баз даних передбачає використання інтегрованих засобів зберігання інформації, що дозволяють забезпечити централізоване керування даними та обслуговування ними багатьох користувачів. При цьому БД повинна підтримуватися в середовищі ЕОМ єдиним програмним забезпеченням, що називається системою управління базами даних (СУБД). СУБД разом з прикладними програмами називають банком даних. [1]
Предметною областю називається фрагмент реальності, який описується або моделюється за допомогою БД та її додатків. В предметній області виділяються інформаційні об'єкти -- ідентифікуються об'єкти реального світу, процеси, системи, поняття і т. д., відомості про які зберігаються в БД.
У світі існує безліч систем керування базами даних. Незважаючи на те, що вони можуть по-різному працювати з різними об'єктами і надавати користувачу різні функції й засоби, більшість СУБД спираються на єдиний усталений комплекс основних понять. В якості такого об'єкту ми виберемо СУБД Microsoft Access, що входить в пакет Microsoft Office.
У курсовій роботі представлено проектування інформаційної системи «Теорія та практика прикладного програмування».
Метою даної курсової роботи є закріплення теоретичних знань, отриманих при вивченні навчальної дисципліни «Проектування та експлуатація інформаційних систем» і придбання навичок у використанні сучасних інформаційних технологій для виготовлення програмних продуктів, що підтримують функціонування інформаційних систем.
1. Опис предметної області
База даних «Теорія та практика прикладного програмування» призначена для зберігання, обробки та пошуку інформації про зміст підручника з програмування.
Головним конструктором баз даних є адміністратор. Адміністратор здійснює роботу з супроводу баз даних у комп'ютерних системах. До його основних обов'язків належить забезпечення збереження інформації, коректування БД за завданнями користувачів, визначення ефективності баз даних, консультування користувачів.
Користувач -- це особа, яка користується інформацією, що міситься у базах даних. Зокрема, Користувач автоматизованої системи -- особа, яка бере участь у функціонуванні автоматизованої системи або використовує результати її функціонування. [2]
З точки зору інформаційної безпеки, користувачем є тільки людина. Програма ж, що працює за її завданням, є вже суб'єктом. З її допомогою користувач взаємодіє з системою, можливо включеною в мережу, і отримує створюване нею робоче середовище. Користувачем є людина, що використовує систему або мережу для вирішення поставлених перед нею завдань. Її називають кінцевим користувачем.
Базою даних «Теорія та практика прикладного програмування» можуть користуватися молоді програмісти, які займаються вивченням мови програмування Delphi. У БД зберігається інформація про зміст розділів підручника, компоненти, функції та процедури, що в ньому розглядаються.
Рисунок 1.1 - Модель предметної області ІС «Теорія та практика прикладного програмування»
2. Проектування інформаційної системи
Предметна область -- це частина реального світу, що підлягає вивченню з метою організації управління і, в кінцевому рахунку, автоматизації. Предметна область представляється безліччю фрагментів, наприклад, підприємство -- цехами, дирекцією, бухгалтерією і т. д. Кожен фрагмент предметної області характеризується безліччю об'єктів і процесів, що використовують об'єкти, а також великою кількістю користувачів, що характеризуються різними поглядами на предметну область. [3]
Проектування бази даних -- це впорядкований процес створення такої моделі предметної області, яка зв'язує дані, що зберігаються в базі з об'єктами предметної області, що описуються цими даними.
Проектування баз даних, як правило, відіграє одну з ключових ролей у більшості проектів. Грамотно спроектована база дозволяє без особливих проблем вносити зміни, змінювати структуру системи [4].
Повний етап проектування бази даних складається з трьох частин:
1. Концептуального (або інфологічного) проектування.
2. Даталогічного проектування.
3. Фізичного проектування.
2.1 Концептуальне (інфологічне) проектування
Концептуальне проектування -- це збір, аналіз та редагування вимог до даних. Для цього здійснюються наступні заходи [4]:
· обстеження предметної області, вивчення її інформаційної структури;
· виявлення всіх фрагментів, кожен з яких характеризується користувальницьким поданням, інформаційними об'єктами і зв'язками між ними, процесами над інформаційними об'єктами;
· моделювання та інтеграція всіх уявлень.
Після закінчення цього етапу одержуємо концептуальну модель, інваріантну до структури бази даних. Часто вона представляється у вигляді моделі «сутність-зв'язок».
Рівні подання даних на кожному етапі:
· сутності;
· атрибутів;
· зв'язку.
Сутність -- це будь-який помітний об'єкт (об'єкт, який ми можемо відрізнити від іншого), інформацію про якого необхідно зберігати в базі даних. Сутностями можуть бути люди, місця, літаки, рейси, смак, колір і т. д. Необхідно розрізняти такі поняття, як тип сутності й екземпляр сутності. Поняття тип сутності відноситься до набору однорідних особистостей, предметів, подій чи ідей, які виступають як ціле. Примірник суті відноситься до конкретної речі в наборі. Наприклад, типом сутності може бути МІСТО, а екземпляром -- Москва, Київ і т. д. [1]
Атрибут -- це пойменована характеристика сутності. Його найменування повинне бути унікальним для конкретного типу сутності, але може бути однаковим для різного типу сутностей (наприклад, КОЛІР може бути визначений для багатьох сутностей: СОБАКА, автомобіль, дим і т. д.). Атрибути використовуються для визначення того, яка інформація повинна бути зібрана про сутність. Прикладами атрибутів для сутності АВТОМОБИЛЬ є ТИП, МАРКА, номерний знак, колір і т. д. Тут також існує розходження між типом і екземпляром. Тип атрибута КОЛІР має багато екземплярів чи значень: Червоний, Синій, Банановий і т. д., однак кожному екземпляру сутності привласнюється тільки одне значення атрибута.
Зв'язок -- це асоціювання двох чи більш сутностей. Якби призначенням бази даних було тільки збереження окремих, не пов'язаних між собою даних, то її структура могла б бути дуже простою. Проте одна з основних вимог до організації бази даних -- це забезпечення можливості відшукання одних сутностей за значеннями інших, для чого необхідно встановити між ними певні зв'язки. А так як в реальних базах даних нерідко містяться сотні або навіть тисячі сутностей, то теоретично між ними може бути встановлено більше мільйона зв'язків. Наявність такої безлічі зв'язків і визначає складність інфологічних моделей. [1]
У даній інформаційній системі основними об'єктами є:
· Главы з властивостями: № главы, название главы, краткое содержание, начальная страница, конечная страница;
· Подглавы з властивостями: № главы, название подглавы, начальная страница, конечная страница; типы переменных, которые рассматриваются; функции, которые упоминаются; таблицы; компоненты, которые упоминаются; события, которые упоминаются; иллюстрации-примеры; операторы, которые упоминаются; определения; процедуры, которые упоминаюся;
· Таблицы з властивостями: наименование таблицы, содержание таблицы;
· Типы переменных з властивостями: код переменной, тип переменной, описание;
· Фрагменты кода з властивостями: наименование, фрагмент кода, пример, примечание к коду, описание фрагмента кода;
· Листинг з властивостями: название листинга, содержание листинга, комментарий к листингу;
· Функции властивостями: функція, краткое описание.
2.1.1 Побудова ER-діаграми
ER-модель є однією з самих простих візуальних моделей даних (графічних нотацій). Вона дозволяє визначити структуру в загальних рисах [5]. Це загальний опис структури називається ER-діаграмою або онтологією вибраної предметної області.
На етапі переходу до реалізації даної ER-діаграми у вигляді реальної інформаційної системи або програми, відбувається відображення ER-моделі в більш детальну модель даних реляційної (об'єктної, мережевої, логічної, або ін) бази даних, яка називається фізичною моделлю даних по відношенню до вихідної ER-діаграмі.
Рисунок 2.1.1 - ER-діаграма
Модель Сутність-Зв'язок (ER-модель) (англ. entity-relationship model або entity-relationship diagram) -- це модель даних, що дозволяє описувати концептуальні схеми. Вона надає графічну нотацію, засновану на блоках і з'єднуючих їх лініях, за допомогою яких можна описувати об'єкти і відносини між ними будь-якої іншої моделі даних. У цьому сенсі ER-модель є мета-моделлю даних, тобто є засобом опису моделей даних.
ER-модель зручна при проектуванні інформаційних систем, баз даних, архітектур комп'ютерних програм, і інших систем (далі -- моделей). З її допомогою можна виділити ключові сутності, що присутні в моделі, і позначити зв'язки, які можуть встановлюватися між цими сутностями. Важливо відзначити, що самі зв'язки також є сутностями (виділяються в окремі графічні блоки), що дозволяє встановлювати зв'язки на безлічі самих відносин [1].
Для цього використовуються наступні позначення:
1. Сутність зображається прямокутниками.
2. Атрибути позначаються овалами (або прямокутниками з закругленими кутами).
3. Зв'язки зображаються ромбами.
2.1.2 Нормалізація даних
У базі даних можуть перебувати дані, що повторюються, які призводять до надмірності даних. Надмірність даних є причиною аномалій, які виявляються в некоректному оновленні, видаленні та редагуванні даних, що в свою чергу стає причиною порушення таких властивостей бази даних, як цілісність, несуперечність, логічна і фізична незалежність. Мінімальна надмірність досягається шляхом виключення повторюваних записів. Але іноді повне усунення надмірності недоцільно. [6]
Нормалізація -- це розбиття таблиці на дві або більше, що володіють кращими властивостями при включенні, зміні та видаленні даних. Остаточна мета нормалізації зводиться до отримання такого проекту бази даних, в якому кожен факт з'являється лише в одному місці, тобто виключена надмірність інформації. Це робиться не стільки з метою економії пам'яті, скільки для виключення можливої суперечливості збережених даних. [7]
Процес нормалізації складається з кількох етапів, на кожному з яких визначаються так звані нормальні форми: 1НФ, 2 НФ, 3 НФ, НФБК, 4НФ, 5НФ (форма проекції зв'язків). У більшості проектів третя нормальна форма завершує процес нормалізації.
Таблиця знаходиться у першій нормальній формі (1НФ) тоді і тільки тоді, коли жоден з її рядків не містить у будь-якому своєму полі більше одного значення і жодне з її ключових полів не порожньо.
Таблиця знаходиться в другій нормальній формі (2НФ), якщо вона задовольняє визначенням 1НФ і всі її поля, що не входять до первинного ключа, пов'язані повною функціональною залежністю з первинним ключем.
Таблиця знаходиться в третій нормальній формі (3НФ), якщо вона задовольняє визначенням 2НФ і не одне з її неключових полів не залежить функціонально від будь-якого іншого неключового поля.
Таблиця знаходиться в нормальній формі Бойса-Кодда (НФБК), якщо і тільки якщо будь-яка функціональна залежність між її полями зводиться до повної функціональної залежності від можливого ключа.
Таблиця знаходиться у п'ятій нормальній формі (5НФ) тоді і тільки тоді, коли в кожній її повній декомпозиції всі проекції містять можливий ключ. Таблиця, яка не має жодної повної декомпозиції, також знаходиться в 5НФ. Повною декомпозицією таблиці називають таку сукупність довільного числа її проекцій, підключення яких повністю збігається з вмістом таблиці.
Четверта нормальна форма (4НФ) є окремим випадком 5НФ, коли повна декомпозиція повинна бути з'єднанням рівно двох проекцій. Вельми не просто підібрати реальну таблицю, що може бути надана в 4НФ, але не була б у 5НФ.
Рисунок 2.1.2 - Нормалізована ER-діаграма (3НФ)
2.2 Даталогічне проектування баз даних
Будемо вважати, що проблема логічного проектування реляційної бази даних полягає в обґрунтованому прийнятті рішень про те:
* з яких зв'язків повинна складатися база даних і
* які атрибути мають бути у ці зв'язки.
Зв'язки реляційної бази даних містять як структурну, так і семантичну (змістову) інформацію. Структурна інформація задається схемою зв'язку, а семантична виражається функціональними зв'язками між атрибутами схеми. Угрупування атрибутів повинно бути раціональним та задовольняти наступним вимогам: [8]
* вибрані для зв'язку первинні ключі повинні бути мінімальними;
* обраний склад зв'язків повинен відрізнятися мінімальної надмірністю атрибутів;
* між атрибутами не повинно бути небажаних функціональних залежностей і вони повинні забезпечувати мінімальне дублювання даних;
* не повинно бути труднощів при виконанні операцій включення, видалення та модифікації (аномалії);
* перебудова набору зв'язків при введенні нових типів повинна бути мінімальною.
Таблиця 2.2.1. «Главы»
|
Поле |
Тип даних |
Розмір |
|
|
№ главы |
Числовий |
Довге ціле |
|
|
Название главы |
Текстовий |
21 |
|
|
Краткое содержание |
Поле МЕМО |
||
|
Начальная страница |
Числовий |
Довге ціле |
|
|
Конечная страница |
Числовий |
Довге ціле |
Таблиця 2.2.2. «Листинг»
|
Поле |
Тип даних |
Розмір |
|
|
Код подглавы |
Текстовий |
4 |
|
|
Код листинга |
Числовий |
Довге ціле |
|
|
Название листинга |
Текстовий |
75 |
|
|
Содержание листинга |
Поле МЕМО |
||
|
Комментарий к листингу |
Поле МЕМО |
Таблиця 2.2.3. «Подглавы»
|
Поле |
Тип даних |
Розмір |
|
|
Код подглавы |
Текстовий |
4 |
|
|
№ главы |
Числовий |
Довге ціле |
|
|
Название поглавы |
Текстовий |
45 |
|
|
Начальная страница |
Числовий |
Довге ціле |
|
|
Конечная страница |
Числовий |
Довге ціле |
|
|
Типы переменных, которые рассматриваются |
Текстовий |
43 |
|
|
Функции, которые упоминаются |
Текстовий |
17 |
|
|
Компоненты, которые упоминаются |
Текстовий |
29 |
|
|
События, которые упоминаются |
Текстовий |
19 |
|
|
Иллюстрации-примеры |
Поле об'єкту OLE |
||
|
Операторы, которые упоминаются |
Текстовий |
19 |
|
|
Определения |
Поле МЕМО |
||
|
Процедуры, которые упоминаются |
Текстовий |
6 |
Таблиця 2.2.4. «Таблицы»
|
Поле |
Тип даних |
Розмір |
|
|
Код подглавы |
Текстовий |
4 |
|
|
Наименование таблицы |
Текстовий |
41 |
|
|
Содержание таблицы |
Поле об'єкту OLE |
Таблиця 2.2.5. «Типы переменных»
|
Поле |
Тип даних |
Розмір |
|
|
Код подглавы |
Текстовий |
4 |
|
|
Код переменной |
Числовий |
Довге ціле |
|
|
Тип переменной |
Текстовий |
11 |
|
|
Описание |
Поле МЕМО |
Таблиця 2.2.6. «Фрагменты кода»
|
Поле |
Тип даних |
Розмір |
|
|
Код подглавы |
Текстовий |
4 |
|
|
Счётчик |
Числовий |
Довге ціле |
|
|
Наименование |
Текстовий |
56 |
|
|
Фрагмент кода |
Поле МЕМО |
||
|
Пример |
Поле МЕМО |
||
|
Примечание к коду |
Поле МЕМО |
||
|
Описание фрагмента кода |
Поле МЕМО |
Таблиця 2.2.7. «Функции»
|
Поле |
Тип даних |
Розмір |
|
|
Код подглавы |
Текстовий |
4 |
|
|
№ пп |
Лічильник |
||
|
Функция |
Текстовий |
7 |
|
|
Краткое описание |
Поле МЕМО |
Структура таблиць відноситься до 3 НФ:
1) кожен стовпець таблиці неподільний і в рамках однієї таблиці немає стовпців з однаковими за змістом значеннями.
2) первинні ключі таблиць однозначно визначають запис і не надмірні.
3) значення будь-якого поля не входить у первинний ключ, не залежить від значення іншого поля, що також не входить у первинний ключ.
2.3 Фізичне проектування інформаційних систем
Аналіз сутностей інфологічної моделі, їх атрибутів та зв'язків дозволяє зробити висновок: кожна сутність може бути представлена окремою таблицею, причому всі вони вже знаходяться в третій нормальній формі.
Фізичне проектування -- це визначення особливостей зберігання даних, методів доступу і т. ін. [9]
Перехід від логічного до фізичного опису моделі складається з наступних кроків:
1. Всі прості сутності перетворюються у зв'язки, ім'я сутності стає ім'ям ставлення.
2. Кожен атрибут стає можливим стовпцем з тим же ім'ям. Стовпці, що відповідають необов'язковим атрибутам, можуть містити NULL-значення.
3. Компоненти унікального ідентифікатора сутності перетворюються в первинний ключ відношення.
4. Зв'язки «багато до одного» стають зовнішніми ключами.
5. У таблицях, побудованих на основі асоціацій, зовнішні ключі використовуються для ідентифікації учасників асоціацій, а в таблицях, побудованих на основі характеристик, зовнішні ключі використовуються для ідентифікації сутностей, що описуються цими характеристиками.
6. Вирішення проблеми наявності підтипів.
7. Виконання кроків щодо нормалізації отриманих зв'язків. Наявна модель знаходиться в третій нормальній формі.
8. Вказівка обмежень цілісності проектованої бази даних та короткий опис отриманих таблиць та їх полів.
З огляду на пряму відповідність логічної моделі та фізичної реалізації, остання чітко відображає перше, вносячи деякі уточнення за способом зберігання інформації. Тобто з урахуванням всього вищесказаного про розробку логічної моделі АС і логічної схеми БД отримана фізична модель БД.
2.3.1 СУБД Access
Система управління базами даних (СУБД) -- спеціалізована програма (частіше комплекс програм), що призначена для організації і ведення бази даних. [10]
СУБД Access входить до складу широко розповсюдженого сімейства офісних додатків Microsoft Office. Microsoft Access на сьогоднішній день є одним з найпоширеніших настільних додатків для роботи з базами даних. Це пов'язано з тим, що Access володіє дуже широким діапазоном засобів для введення, аналізу та представлення даних. Ці кошти є не тільки простими і зручними, а й високопродуктивними, що забезпечує високу швидкість розробки додатків. Спочатку Access мала ряд унікальних можливостей, таких як вміння зводити воєдино інформацію з різних джерел (електронних таблиць, текстових файлів, інших баз даних), подання даних в зручному для користувача вигляді за допомогою таблиць, діаграм, звітів, інтеграція з іншими компонентами Microsoft Office. Вдосконалюючись від версії до версії, Access стала інструментом, який може задовольнити потреби самих різних категорій користувачів: від новачка, якому подобається дружній інтерфейс системи, що дозволяє йому впоратися із завданнями, до професійного розробника, який має весь необхідний інструментарій для побудови унікального рішення для конкретного підприємства середнього бізнесу.
2.3.2 Об'єкти Access
Таблиці -- це основні й найнеобхідніші об'єкти будь-якої БД. Саме в таблицях зберігаються всі дані. Реляційна БД може містити цілий набір взаємозв'язаних таблиць.
Запити -- це спеціалізовані структури, що створюються для здійснення обробки бази даних. За допомогою запитів можна упорядкувати дані, виконати їх фільтрацію, об'єднання, відбір або навіть зміну.
Форми -- це об'єкти, що дозволяють вводити в базу нові дані або переглядати вже існуючі у зручній для користувача формі (вигляді, поданні).
Звіти -- ці об'єкти говорять самі за себе. Вони видають дані на принтер або інший пристрій виводу (це може бути і монітор), у зручному та наочному вигляді. Наприклад, у вигляді бланку або рахунку.
Макроси -- це набір макрокоманд. Коли виникає необхідність частого виконання одних і тих же операцій з БД, є можливість згрупувати набір команд в один макрос. Після чого ініціалізацію його виконання закріплюють за певною комбінацією клавіш клавіатури. Простими словами, натискання цієї комбінації при роботі з базою призводить до виконання всієї послідовності дій, що записані у макрос.
Модулі -- це програми, що створені засобами мови Visual Basic. Вони дозволяють доповнити стандартні засоби Access, якщо наявних вже не вистачає для задоволення всіх вимог до роботи СУБД. Програміст може розширити можливості системи, дописавши необхідні модулі та додавши їх у БД. [4]
2.3.3 Створення таблиць
У Microsoft Office Access дані організовуються в таблиці -- сукупності рядків і стовпців, аналогічні паперам бухгалтера або книзі Microsoft Office Excel. Визначення структури бази даних потрібно завжди починати зі створення її таблиць. Таблиці створюються раніше будь-яких інших об'єктів бази даних.
Проста база даних може складатися всього з однієї таблиці. Більшість баз даних включають декілька таблиць. Наприклад, в одній таблиці можуть зберігатися відомості про продукти, у другій -- відомості про замовлення, а в третьому -- відомості про клієнтів.
Усі таблиці бази даних «Теорія та практика прикладного програмування» були створені у режимі конструктора.
Рисунок 2.3.1 - Таблиця «Главы»
Рисунок 2.3.2 - Таблиця «Листинг»
Рисунок 2.3.3 - Таблиця «Подглавы»
Рисунок 2.3.4 - Таблиця «Таблицы»
Рисунок 2.3.5 - Таблиця «Типы переменных»
Рисунок 2.3.6 - Таблиця «Фрагменты кода»
Рисунок 2.3.7 - Таблиця «Функции»
Так як дана база є реляційною, то вона містить не окремі таблиці, а групи взаємопов'язаних таблиць. Для створення зв'язків між таблицями використовувалася команда Схема даних меню Сервіс.
Рисунок 2.3.8 - Схема даних
2.3.4 Створення запитів
Запит (query) -- це засіб вибору необхідної інформації з бази даних. Питання, що сформоване по відношенню до бази даних, і є запит. Застосовуються два типи запитів: за зразком (QBE -- Query by example) і структурована мова запитів (SQL -- Structured Query Language). [7]
QBE -- запит за зразком -- засіб для пошуку необхідної інформації в базі даних. Він формується не на спеціальній мові, а шляхом заповнення бланка запиту у вікні Конструктора запитів.
SQL-запити -- це запити, які складаються (програмістами) з послідовності SQL-інструкцій. Ці інструкції задають, що треба зробити з вхідним набором даних для генерації вихідного набору. Всі запити Access будує на основі SQL-запитів. Щоб побачити їх, необхідно в активному вікні проектування запиту виконати команду Вид / SQL.
Існує кілька типів запитів: на вибірку, на оновлення, на додавання, на видалення, перехресний запит, створення таблиць. Найбільш поширеним є запит на вибірку. Запити на вибірку використовуються для відбору потрібної користувачу інформації, що міститься в таблицях. Вони створюються тільки для пов'язаних таблиць. [9]
Запит «Содержание» виводить інформацію про те, які глави які підглави містять, та про початкову і кінцеву сторінки цих підглав.
Рисунок 2.3.9 - Запит «Содержание» у режимі Конструктора
Рисунок 2.3.10 - Робота запиту «Содержание»
Запит «Общее кол-во страниц в подглаве» дозволяє отримати інформацію про загальну кількість сторінок у підглаві. Для побудови цього використовувався будівник виразів, за допомогою якого було створено поле, що обчислюється, «Общее кол-во страниц: Подглавы![Конечная стр]-Подглавы![Начальная стр]»
Рисунок 2.3.11 - Запит «Общее кол-во страниц в подглаве» у режимі Конструктора
Рисунок 2.3.12 - Робота запиту «Общее кол-во страниц в подглаве»
Запит «Кол-во графической информации» надає відомості про загальну кількість графічної інформації у БД (рисунки та таблиці). Це груповий запит, в якому була використана функція COUNT().
Рисунок 2.3.13 - Запит «Кол-во графической информации» у режимі Конструктора
Рисунок 2.3.14 - Робота запиту «Кол-во графической информации»
Запит «Найти фрагмент кода» є параметричним запитом, що дозволяє відобразити зазначений користувачем фрагменти коду.
Рисунок 2.3.15 - Запит «Найти фрагмент кода» у режимі Конструктора
Рисунок 2.3.16 - Робота запиту «Найти фрагмент кода»
Перехресний запит «Общее кол-во страниц в подглаве» виводить результат розрахунку загальної кількості сторінок у підглаві.
Рисунок 2.3.17 - Перехресний запит «Общее кол-во страниц в подглаве» у режимі Конструктора
Рисунок 2.3.18 - Робота перехресного запиту «Общее кол-во страниц в подглаве»
Запит «Поиск повторений для Подглавы» виконує пошук записів, які повторюються у таблиці «Подглавы». Запит створюється за допомогою Майстра.
Рисунок 2.3.19 - Запит «Поиск повторений для Подглавы» у режимі Конструктора
Рисунок 2.3.20 - Робота запиту «Поиск повторений для Подглавы»
Запит «'Подглавы' без подчиненных в 'Листинг'» дозволяє побачити підглави, що не містять у собі жодного лістингу.
Рисунок 2.3.21- Запит «'Подглавы' без подчиненных в 'Листинг'» у режимі Конструктора
Рисунок 2.3.22 - Робота запиту «'Подглавы' без подчиненных в 'Листинг'»
2.3.5 Створення форм
Access надає можливість вводити дані як безпосередньо в таблицю, так і за допомогою форм. Форма у БД -- це структуроване вікно, яке можна представити так, щоб воно повторювало форму бланка. Форми створюються з набору окремих елементів управління.
Зовнішній вигляд форми вибирається в залежності від того, з якою метою вона створюється. Форми Access дозволяють виконувати завдання, які не можна виконати в режимі таблиці. Форми дозволяють обчислювати значення і виводити на екран результат. Джерелом даних для форми є записи таблиці або запиту.
Всі форми БД «Теорія та практика прикладного програмування» були створені за допомогою Майстра. Відкриття форм здійснюється натисканням відповідних кнопок на кнопковій формі (Рисунок 2.3.23), яка створена за допомогою Диспетчеру кнопкових форм (меню Сервіс--Службові програми--Диспетчер кнопкових форм). При запуску БД кнопкова форма запускається автоматично.
Рисунок 2.3.23 - Кнопкова форма
Форма «Главы» (Рисунок 2.3.24) містить коротку інформацію про главу, початкову та кінцеву сторінку.
Основною формою є форма «Подглавы» (Рисунок 2.3.25), так як вона містить інформацію про вміст підглав посібника (її назву, початкову та кінцеву сторінки, функції, компоненти, події, оператори та процедури, що згадуються, ілюстрації-приклади та визначення; дані про лістинги, таблиці, функції та фрагменти коду, що містяться), а як наслідок -- про вміст глав.
Рисунок 2.3.24 - Форма «Главы»
Рисунок 2.3.25 - Форма «Подглавы»
Форма «Типы переменных» (Рисунок 2.3.26) відкривається натисканням кнопки «Посмотреть» форми «Подглавы» (Рисунок 2.3.25) і містить інформацію про типи змінних, що розглядаються у підглаві.
Рисунок 2.3.26 - Форма «Типы переменных»
Форма «Листинг» (Рисунок 2.3.27) містить дані про лістинги, які приводяться в підглаві; форма «Таблицы» (Рисунок 2.3.28) містить аналогічну інформацію щодо таблиць; форма «Функции» (Рисунок 2.3.29) надає дані про функції, а форма «Фрагменты кода» (Рисунок 2.3.30) -- про фрагменти коду. Всі ці форми відкриваються натисканням відповідних кнопок на формі «Подглавы» (Рисунок 2.3.25).
Рисунок 2.3.27 - Форма «Листинг»
Рисунок 2.3.28 - Форма «Таблицы»
Рисунок 2.3.29 - Форма «Функции»
Рисунок 2.3.30 - Форма «Фрагменты кода»
Форма «Запросы» (Рисунок 2.3.31) містить у собі кнопки виклику запитів, що маються у БД.
Рисунок 2.3.31 - Форма «Запросы»
Форма «Об авторе» (Рисунок 2.3.32) надає свідоцтво про автора.
Рисунок 2.3.32 - Форма «Об авторе»
3. Інструкція користувача
Ласкаво просимо до бази даних «Теорія та практика прикладного програмування»!
База даних «Теорія та практика прикладного програмування» призначена для зберігання довідкової інформації, що міститься у певних главах посібника з прикладного програмування (Культин Н.Б. Основы программирования в Delphi7).
Головна кнопкова форма запускається автоматично, відразу після запуску БД.
Рисунок 3.1 - Інтерфейс кнопкової форми
Після натискання кнопки (1) з'явиться форма «Главы». Ознайомившись зі змістом форми, її можна закрити, натиснувши (6) (Рисунок 3.2).
Рисунок 3.2 - Інтерфейс форми «Главы»
Натискання кнопки (2) (Рисунок 3.1) викличе появу форми «Подглавы».
Рисунок 3.3 - Інтерфейс форми «Подглавы»
Поля (7) відображають зміст записів. Натискання кнопки (8) викличе форму «Типы переменных» (Рисунок 2.3.26). Натискання кнопок (9) викличе форми «Листинг» (Рисунок 2.3.27), «Таблицы» (Рисунок 2.3.28), «Функции» (Рисунок 2.3.29) та форму «Фрагменты кода» (Рисунок 2.3.30) відповідно.
Навігація за записами виконується за допомогою панелі (10).
Кнопка (3) (Рисунок 3.1) відкриває форму «Запросы» (Рисунок 2.3.31), яка містить кнопки, натискання яких використовується для запуску необхідного запиту.
Кнопка (4) викличе форму (Рисунок 2.3.32), що місить свідоцтва про автора БД.
Натискання кнопки (5) призведе до закриття всієї бази даних.
Висновки
У процесі даної курсової роботи була спроектована та реалізована в СУБД MS Access інформаційна система «Теорія та практика прикладного програмування».
У цій базі даних зберігається довідкова інформація, що міститься у певних главах посібника з прикладного програмування (Культин Н.Б. Основы программирования в Delphi 7). База містить запити, що дозволяють здійснювати пошук необхідних даних та відображати статистичну інформацію, як то: інформацію про те, які глави які підглави містять, та про початкову й кінцеву сторінки цих підглав; інформацію про загальну кількість сторінок у підглаві; відомості про загальну кількість графічної інформації у БД (рисунки та таблиці); відображення зазначеного користувачем фрагменту коду; вивод результату розрахунку загальної кількості сторінок у підглаві; вивод результату розрахунку загальної кількості сторінок у підглаві; пошук записів, які повторюються; підглави, що не містять у собі жодного лістингу.
Дана система пройшла всі три етапи проектування. На інфологічному рівні структура бази даних була відображена у вигляді ER-діаграми, яка надалі була приведена до третьої нормальної форми. На даталогічному рівні -- представлена реляційною моделлю. У таблицях був усунений надлишок. Безпосередня робота з СУБД з формування таблиць і їх заповнення на комп'ютері була проведена на стадії фізичного проектування.
Таким чином, було створено 7 таблиць, 7 запитів, 10 форм та 8 макросів. Розмір файлу БД -- 18,5 Мб.
Надалі дану систему можна вдосконалювати, відповідно до потреб користувачів.
Перелік використаних джерел
Кириллов В.В. Основы проектирования реляционных баз данных. Учебное пособие. -- СПб.: ИТМО, 1994. -- 90 с.
ГОСТ 34.003-90. Государственный стандарт Российской Федерации: «Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения». -- М.: ИПК Издательство стандартов, 2002.
Дейт Д. Введение в систему баз данных. -- М., СПб.: BHV -- Санкт-Петербург, 1977. -- 312 с.
http://ru.wikipedia.org/. -- Вільна енциклопедія.
Інформаційні системи і технології /Карпенко С.Г., Попов В.В., Тарнавський Ю.А. та ін. -- К.: МАУП, 2004. -- 192с.
Лук'янова В.В. Комп'ютерний аналіз даних: Посібник. -- К.: Академія, 2003. -- 344с.
Основи інформаційних систем: Навчальний посібник /Ситник В.Ф., Писаревська, Ерьоміна Н.В., Краєва О.С. Ред Ситник В.Ф. -- К.: КНЕУ, 1997. -- 252с.
Оскерко В.С., Пунчик З.В. Практикум по технологиям баз данных: Учебное пособие. -- Минск: БГЭУ, 2004. -- 170с.
Конспект лекций по дисциплине «Информационные системы в ПК»
http://www.lessons-tva.info/. -- Безкоштовне дистанційне навчання інформатиці, телекомунікаціям та основам електронного бізнесу.
Подобные документы
Даталогічне проектування баз даних та концептуальне (інфологічне) проектування (побудова ER-діаграми та нормалізація даних) інформаційної системи. Фізичне проектування інформаційних систем (СУБД Access: об’єкти бази, створення таблиць, запитів та форм).
курсовая работа [3,5 M], добавлен 09.01.2010Характеристика категорій користувачів баз даних. Проектування інформаційної системи: концептуальне (інфологічне), даталогічне та фізичне. Опис бази даних "Каталог мобільних телефонів": принципи створення таблиць, запитів та форм. Інструкція користувача.
курсовая работа [63,2 K], добавлен 14.12.2010Створення і реалізація в СУБД MS Access бази даних "Internet-ресурси з інформаційних технологій". Опис предметної області, інфологічне проектування. Побудова ER-діаграми. Даталогічне і фізичне проектування інформаційних систем. Опис роботи програми.
курсовая работа [8,2 M], добавлен 30.05.2013Етапи проектування ІС, алгоритм і необхідність нормалізації. Загальні відомості про роботу з базами даних, їх супроводження у середовищі MS Access. Методика та особливості проектування інформаційної системи "Теорія та практика прикладного програмування".
курсовая работа [2,2 M], добавлен 22.03.2010Побудова інформаційної системи "Магазин товарів для настільного тенісу" з автоматизації роботи магазину. Концептуальне моделювання бази даних. Обґрунтування вибору СУБД. Логічне проектування бази даних. Схема бази даних. Створення таблиць в конструкторі.
курсовая работа [8,8 M], добавлен 16.12.2015Проектування бази даних: визначення об’єктів, структура таблиць, побудова схеми даних, забезпечення цілісності даних, створення певних відношень між таблицями, створення запитів, побудова форм, оформлення об’єктів. Розробка інструкції користувача.
курсовая работа [1,9 M], добавлен 19.09.2014Специфікація вимог для кожного з двох користувачів. Концептуальне та логічне проектування баз даних. Історія досліджень баз даних (програмного забезпечення). Система упрваління базами даних. Фази проектування баз даних: концептуальна, логічна, фізична.
дипломная работа [105,8 K], добавлен 20.02.2010Систематизація знань як основна функція бази даних. Логічне та фізичне проектування бази даних. Створення таблиць у базі даних, визначення основних зв'язків. Інструментальні засоби проектування та створення програмного забезпечення для обробки даних.
курсовая работа [1,4 M], добавлен 29.04.2010Методика та основні етапи проектування інформаційної системи "Меблевий салон", опис необхідних для цього даних і джерела їх отримання. Побудова ER-діаграми та порядок її нормалізації. Методи створення таблиць та форм, можливості їх змін, редагування.
курсовая работа [2,1 M], добавлен 08.12.2009Визначення мети створення бази даних магазину та таблиць, які вона повинна містити. Розгляд видів полів та ключів таблиць. Створення запитів, форм, звітів, макросів та модулів. Вибір системи управління базами даних. Реалізація моделі у Microsoft Access.
курсовая работа [3,8 M], добавлен 20.07.2014
