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

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

ЗМІСТ

ВСТУП

1 ОПИС ПРЕДМЕТНОЇ ОБЛАСТІ

2 ПРОЕКТУВАННЯ ІНФОРМАЦІЙНОЇ СИСТЕМИ

3 ДАТАЛОГІЧНЕ ПРОЕКТУВАННЯ БАЗ ДАНИХ

4 ФІЗИЧНЕ ПРОЕКТУВАННЯ ІНФОРМАЦІЙНИХ СИСТЕМ

4.1 MS Access

4.2 Створення об'єктів бази даних

4.3 Запити до бази даних

4.4 Форми бази даних

5 ІНСТРУКЦІЯ КОРИСТУВАЧА

ВИСНОВКИ

ПЕРЕЛІК ВИКОРИСТАНИХ ДЖЕРЕЛ

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

База даних — це організована структура, призначена для зберігання інформації. Дані та інформація — поняття взаємопов'язані, але не тотожні. Сьогодні більшість систем управління базами даних (СКБД) дозволяють розміщувати у своїх структурах не лише дані, але і методи (тобто програмний код), за допомогою яких відбувається взаємодія зі споживачем або з іншими програмно-апаратними комплексами. З поняттям бази даних тісно пов’язане поняття системи управління базою даних (СКБД). Це комплекс програмних засобів, призначених для створення структури нової бази, наповнення її вмістом, редагування вмісту і візуалізації інформації. Під візуалізацією інформації бази розуміється відбір відображуваних даних відповідно до заданого критерію, їхнє упорядкування, оформлення і наступна видача на пристрій виводу або передача по каналах зв’язку. 1]

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

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

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

1 ОПИС ПРЕДМЕТНОЇ ОБЛАСТІ

Основне завдання даного курсового проекту — зберігання, обробка та пошук інформації про можливості використання ресурсів мережі Internet.

База даних «База даних Internet — ресурсів психологічних тестів» призначена для зберігання, обробки та пошуку інформації про психологічні тести які розташовані в Інтернеті. Головним конструктором баз даних є адміністратор. Адміністратор здійснює роботу з супроводу баз даних у комп’ютерних системах. До його основних обов’язків належить забезпечення збереження інформації, коректування БД за завданнями користувачів, визначення ефективності баз даних, консультування користувачів.

Користувач — це особа, яка користується інформацією, що міститься у базах даних. Зокрема, Користувач автоматизованої системи — особа, яка бере участь у функціонуванні автоматизованої системи або використовує результати її функціонування.

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

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

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

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

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

Повний етап проектування бази даних складається з трьох частин:

1. Інфологічного (концептуального) проектування.

2. Даталогічного (логічного) проектування.

3. Фізичного проектування.

Рисунок 1.1 — Модель предметної області ІС «Internet-ресурси з психологічних тестів»

2 ПРОЕКТУВАННЯ ІНФОРМАЦІЙНОЇ СИСТЕМИ

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

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

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

· коректність схеми БД, тобто адекватне відображення модельованої ПО;

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

· ІЛМ має бути описана мовою, зрозумілою проектувальникам БД, програмістам, адміністратору і майбутнім користувачам АБ.

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

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

2.1 Логічне проектування БД. ER-діаграми Процес проектування даних можна умовно розділити на два етапи: логічне моделювання і фізичне проектування. Результатом першого з них є так звана логічна (або концептуальна) модель даних, що виражається зазвичай діаграмою «сутність-зв'язок» або ER (Entity-Relationship) діаграмою, яка представлена в одній зі стандартних нотацій, прийнятих для відображення подібних діаграм. Результатом другого етапу є готова база даних або DDL-скрипт для її створення.

Логічна модель даних описує факти і об'єкти, що підлягають реєстрації в майбутній базі даних. Основними компонентами такої моделі є сутності, їх атрибути та зв’язки між ними. Як правило, фізичним аналогом сутності в майбутній базі даних є таблиця, а фізичним аналогом атрибута — поле цієї таблиці. З логічної точки зору сутність являє собою сукупність однотипних об'єктів або фактів, які називаються екземплярами цієї сутності. Фізичним аналогом примірника зазвичай є запис в таблиці бази даних. Як і записи в таблиці реляційної СУБД, екземпляри сутності повинні бути унікальними, тобто повний набір значень їх атрибутів не повинен дублюватися. І так само, як і поля в таблиці, атрибути можуть бути ключовими і неключових. На етапі логічного проектування для кожного атрибута зазвичай визначається приблизний тип даних (строковий, числовий, BLOB та ін.) Конкретизація відбувається на етапі фізичного проектування, так як різні СУБД підтримують різні типи даних і обмеження на їх довжину або точність.

Моделювання даних Однією з основних частин інформаційного забезпечення є інформаційна база, яка представляє собою сукупність даних, за допомогою яких задовольняються інформаційні потреби управлінських процесів і вирішуваних завдань. Розробка БД виконується за допомогою моделювання даних. Мета моделювання даних полягає в забезпеченні розробника ІС концептуальною схемою бази даних у формі однієї моделі або кількох локальних моделей, які відносно легко можуть бути відображені в будь-яку систему баз даних. Найбільш поширеним засобом моделювання даних є діаграми «сутність-зв'язок» (ERD). За допомогою ERD здійснюється деталізація накопичувачів даних DFD — діаграми, а також документуються інформаційні аспекти бізнес-системи, включаючи ідентифікацію об'єктів, важливих для предметної області (сутностей), властивостей цих об'єктів (атрибутів) та їх зв’язків з іншими об'єктами (відносин).

Рисунок 2.1 — Ненормалізована ER-діаграма

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

· виключити дублювання інформації в таблицях.

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

· зменшити вплив структурних змін бази даних на роботу додатків, що забезпечують користувачам доступ до даних.

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

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

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

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

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

Рисунок 2.2 — Нормалізована ER-діаграма (3НФ)

3. ДАТАЛОГІЧНЕ ПРОЕКТУВАННЯ БАЗ ДАНИХ Другим етапом проектування баз даних є даталогічне проектування. На даному етапі необхідно об'єкти і зв’язки між ними перетворити в логічну модель даних — модель, побудовану по законах логіки. Існують декілька моделей даних. Серед них виділяють реляційну, ієрархічну і мережеву.

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

Таблиця 1 — Створимо таблицю універсального відношення

Таблиця 2 — «Сайти».

Таблиця 3 — «Тести»

Таблиця 4 — «Категорії»

Таблиця 5 — «Автор»

Таблиця 6 — «Зв'язок»

Структура таблиць відноситься до 3 NF:

· кожен стовпець таблиці неподільний і в рамках однієї таблиці немає стовпців з однаковими по сенсу значеннями;

· первинні ключі таблиць однозначно визначають запис і ненадмірні;

· значення будь-якого поля не входить в первинний ключ, не залежить від значення іншого поля що також не входить в первинний ключ.

4 ФІЗИЧНЕ ПРОЕКТУВАННЯ ІНФОРМАЦІЙНИХ СИСТЕМ

4.1 MS Access

Access — потужна програма Windows. Оскільки обидва ці продукту — дітища компанії Miсrosoft, вони прекрасно взаємодіють між собою. Система доступу працює під управлінням ОС Windows, так що при роботі з нею користувачеві доступні всі переваги Windows. Можна вирізати, копіювати і вставляти дані з усіх програм Windows, в доступі і навпаки; можна створити проект форми в доступі і вставити його в конструктор форм. Працюючи в середовищі Miсrosoft Office, користувач отримує в своє розпорядження повністю сумісні між собою і доступу Word, Excel і PowerPoint.

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

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

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

4.2 Створення об'єктів бази даних

Будь-який об'єкт бази даних може створюватися двома способами:

· З використанням Конструктора — спеціального елемента керування, що дозволяє створювати об'єкти бази даних вручну;

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

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

Для роботи Майстра необхідно запустити програму Miсrosoft Access. Запустити програму можна трьома способами:

· За допомогою кнопки Пуск ОС Windows;

· За допомогою кнопки доступу на робочому столі Windows;

· Через програму Провідник Windows;

· Використовуючи панель режимів і інструментів.

Рисунок 4.1 -Таблиця «Сайти»

Рисунок 4.2 -Таблиця «Тести»

Рисунок 4.3 — Таблиця «Проміжна таблиця»

Рисунок 4.4 -Таблиця «Категорії»

Рисунок 4.5 -Таблиця «Автор»

Рисунок 4.6- Схема даних

4.3 Запити до бази даних

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

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

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

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

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

Рисунок 4.7 — Параметричний запит «Пошук сайтів по діапазону років розробки» у режимі конструктора Рисунок 4.8- Запит «Тесты без указанного автора» у режимі конструктора Рисунок 4.9 — Запит на пошук у базі даних тестів по введенню слова Рисунок 4.10 — Перехресний запит «Тести на різних сайтах» у режимі конструктора

4.4 Форми бази даних

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

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

Створення форми за допомогою автоформи. Створення форми в режимі Автоформи забезпечує автоматичну форму розробки документа. Автоформи — це повністю автоматизовані засоби розробки документа. Існує три види автоформ — в стовпець, стрічкові та табличні.

Рисунок 4.13- Кнопочна форма На рисунку 4.13 зображено кнопочку яка створена за допомогою Диспетчеру кнопкових форм (меню Сервіс-Службові програми-Диспетчер кнопкових форм)

Рисунок 4.14- Головна форма «Сайти які містять цифрові відеокамери»

Рисунок 4.15- Форма «Тести»

Для перегляду інформації яка стосується тестів використовується підлегла форма «Тести» (Рисунок 4.15)

Форма на якій запити якій представлені у базі даних Рисунок 4.16 — Форма «Запити»

Форма «Об авторі» містить коротки відомості про автора проекту.

Рисунок 4.17- Форма «Об Авторі»

5 ІНСТРУКЦІЯ КОРИСТУВАЧА База даних «Психологічні тести» призначена для зберігання інформації про тести та про сайти на яких містяться психологічні тести"

Головна кнопкова форма запускається автоматично, відразу після запуску Б.Д.

Рисунок 4.18- Головна кнопочна форма Після натискання кнопки (1) з’явиться головна форма «Сайти які містять Психологічні тести». На Цій формі буде міститись інформація про сайти та показані тести які розташовані на сайтах.

Рисунок 4.19- Головна форма «Сайти які психологічні тести»

Після натискання на кнопку (2) виводиться форма на якій є кнопки по натисканню на які виводяться запити до бази даних Рисунок 4.20-Форма «Запити»

Кнопка (3) потрібна для перегляду інформації про автора проекту Рисунок 4.21 — Форма «Об Авторі»

Натискання кнопки (4) призведе до закриття всієї бази даних.

ВИСНОВКИ У процесі даної курсової роботи була спроектована та реалізована в СУБД MS Access інформаційна система «База даних Internetресурсів тестів з психології»

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

На етапі опису предметної області був зроблений аналіз даних згідно з темою, та побудована модель предметної області.

На етапі інфологічного проектування база даних була відображена у вигляді ER-діаграми, яка надалі була приведена до третьої нормальної форми.

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

На стадії фізичного проектування за допомогою СКБД MS Access були створені та заповнені таблиці, реалізовані запити та необхідні форми.

Таким чином, було створено 5 таблиць, 5 запитів, 11 форм. Розмір файлу БД — 89 000 Кб.

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

ПЕРЕЛІК ВИКОРИСТАНИХ ДЖЕРЕЛ

1. Microsoft Access 2007: Теорія баз данных; Таблицы и запросы; Формы и отчеты и др.: Лучший самоучитель. / [Глушаков С. В. Сурядный А. С., Шумилов М.]. Изд. 2-е, перераб. — М.: АСТ Москва., 2008. — 448 с.

2. Гурвиц Г. А. Microsoft Access 2007. Разработка приложений на реальном примере. — СПб.: БХВ-Петербург, 2007. — 672 c.

3. Самоучитель Microsoft Access 2000. / [Бекаревич Ю., Пушкина Н.] - СПб.: БХВ — Санкт-Петербург, 2007. — 480 с.

4. Вейскас Д. Эффективная работа с Microsoft Access 2000. С. — Петербург: «Питер Пресс», 1996. — 856 с.

5. Дженнингс Р. Использование Microsoft Office Access 2003. — М.: Издательский дом «Вильямс», 2006. — 1312 с.

6. Інформаційні системи і технології / [Карпенко С.Г., Попов В. В., Тарнавський Ю. А. та ін.] - К.: МАУП, 2004. — 192с.

7. Кириллов В. В. Основы проектирования реляционных баз данных. Учебное пособие. — СПб.: ИТМО, 1994. — 90 с.