Міністерство освіти і науки України
Львівський національний університет імені Івана Франка
Факультет електроніки
Кафедра
оптоелектроніки та інформаційних технологій
КУРСОВА РОБОТА
на
тему: "Створення бази даних оптичних лазерів"
Львів
2014
Зміст
Вступ
Розділ 1. База даних
.1 Бази даних та їх типи
.2 Вимоги до пам’яті, яка потрібна для збереження БД
.3 Моделі Даних
.4 12 правил Кодда
.5 Нормалізація баз даних
.6 Систем керування базами даних(СКБД)
Розділ 2. Лазерна технологія
.1 Принцип дії лазерів
.2 Основні властивості лазерного променя
.3 Монохроматичність лазерного випромінювання його потуність
.4 Гігантські імпульси
Розділ 3. Застосування лазерів
.1 Застосування лазерного променя в промисловості і техніці
.2 Застосуваня лазерів у медицині
.3 Характеристики типів лазерів
.4 Голографія
Висновок
Список використаних джерел
Додаток
Написання програми на мові C # в середовищі Microsoft Visual Studio, за допомогою якої можна внести і редагувати інформацію в базі даних
Мета даної курсової роботи: продемонструвати програму яка заносить інформацію в базу даних, етап створення програми мовою програмування C #.
У даній курсовій роботі проаналізовано такі аспекти:
мову програмування C #
базу даних Microsoft Access
"Microsoft Access" (повна назва Microsoft Office Access) - система управління базами даних від компанії Майкрософт, програма, що входить до складу пакету офісних програм Microsoft Office. Має широкий спектр функцій, включаючи зв'язані запити, сортування по різних полях, зв'язок із зовнішніми таблицями і базами даних. Завдяки вбудованій мові VBA, в самому Access можна писати підпрограми, що працюють з базами даних.
Версії
Access 2.0 для Windows (Office 4.3), 1995 Access 7 для
Windows 95 (Office 95), 1997 Access 97 (Office 97), 1999 Access 2000 (Office
2000), 2001 Access 2002 (Office XP), 2003 Access 2003 (із комплекта програм
Microsoft Office 2003), 2007 Microsoft Office Access 2007 (із комплекта програм
Microsoft Office 2007), 2010 Microsoft Office Access 2010 (із комплекта програм
Microsoft Office 2010).
База даних (скорочено - БД) - впорядкований набір логічно взаємопов'язаних даних, що використовуються спільно та призначені для задоволення інформаційних потреб користувачів. У технічному розумінні включно й система керування БД.
Головне завдання БД - гарантоване збереження значних обсягів інформації (так звані записи даних) та надання доступу до неї користувачеві або ж прикладній програмі. Таким чином, БД складається з двох частин: збереженої інформації та системи керування нею.
З метою забезпечення ефективності доступу записи даних організовують як множину фактів (елемент даних).
Історія розвитку
-ті рр. розроблення перших БД. CODASYL - мережева модель даних та одночасно незалежне розроблення ієрархічної БД фірмою North American Rockwell, яка пізніше взята за основу IMS - власної розробки IBM.
-ті рр. наукове обґрунтування Едгаром Ф. Коддом основ реляційної моделі, котра на початку зацікавила лише наукові кола. Уперше цю модель було використано у БД Ingres (Берклі) та System R (IBM), що були лише дослідними прототипами, анонсованими протягом 1976 року.
-ті рр. поява перших комерційних версій реляційних БД Oracle та DB2. Реляційні БД починають успішно витісняти мережеві та ієрархічні. Дослідження децентралізованих (розподілених) систем БД, проте вони не відіграють особливої ролі на ринку БД.
-ті рр. увага науковців спрямовується на об'єктно-орієнтовані БД, які знайшли застосування в першу чергу в тих галузях, де використовуються комплексні дані: інженерні, мультимедійні БД.
-ні рр. головним нововведенням є підтримка та застосування XML у БД. Розробники комерційних БД, які панували на ринку у 1990-их рр., отримують все більшу конкуренцію з боку руху відкритого програмного забезпечення. Реакцією на це стає поява безкоштовних версій комерційних БД.
Структуровані та неструктуровані БД
Структуровані БД використовують структури даних, тобто структурований опис типу фактів за допомогою схеми даних, більш відомої як модель даних. Модель даних описує об'єкти та взаємовідношення між ними. Існує декілька моделей (чи типів) баз даних, основні: плоска, ієрархічна, мережна та реляційна. Приблизно з 2000 року більше половини БД використовують реляційну модель.
До неструктурованих БД належать повнотекстові бази даних, які містять неструктуровані тексти статей чи книг у формі, що дозволяє здійснювати швидкий пошук.
Характеристика БД
Часто зустрічається характеристика БД на основі певних параметрів або необхідних вимог, наприклад:
· значна кількість даних;
· незалежність даних;
· відкритий доступ до даних;
· підтримка транзакцій з гарантією відповідних властивостей;
· гарантована відсутність збоїв;
· одночасна робота з багатьма користувачами.
З подальшим розвитком БД змінюються й ці вимоги та додаються нові, тому одностайності щодо повноти цієї характеристики немає.
Схема баз даних (англ. database schema) - це структура системи баз даних описана формальною мовою, яка підтримується системою управління баз даних (СУБД) і відноситься до організації даних для створення плану побудови бази даних з розподілом на таблиці. Формально схема баз даних представляє собою набір формул (правил), які називаються обмеженнями цілісності. Обмеження цілісності забезпечують сумісність між всіма частинами схеми. Всі обмеження виражаються однією мовою.
Поняття схеми бази даних відіграє ту ж роль, що і поняття теорії в численні предикатів. Модель цієї "теорії" точно відповідає базі даних, яку можна побачити в будь-який момент часу як Математичний об'єкт|математичний об'єкт. Таким чином, схема може містити формули, що представляють обмежені цілісності спеціально для додатків і обмеження спеціально для типу бази даних, які виражені на одній мові баз даних. В реляційній базі даних, схема визначає таблиці, поля, відношення, індекси, пакети, процедури, функції, черги, тригери, типи даних, послідовності, матеріалізовані уявлення, синоніми, посилання баз даних, каталоги, Java, XML-схеми та інші елементи.
Схеми, як правило, зберігається в словнику даних. Хоча схема визначена в тексті мови бази даних, цей термін часто використовується для графічного позначення структури бази даних. Іншими словами, схема - це структура бази даних яка визначає об'єкти в базі даних.
В системі баз даних Oracle, термін "схема" має дещо інший відтінок. Для інтерпретації в базі даних Oracle використовується термін схема об'єкта.
У зв’язку з розвитком інформаційних ресурсів, появою нових інформаційних та інформаційно-пошукових систем з’явилась необхідність зберігати та опрацьовувати великі набори даних. Ефективна обробка даних ставить перед розробниками програмного забезпечення ряд задач: як організувати інформацію в пам’яті комп’ютерів, які операції по її обробці є найбільш зручними та потрібними. Розвиток методів розв’язання таких задач привів у 60-х роках ХХ століття до появи поняття бази даних, яке є одним із центральних в інформатиці.
Під базою даних (БД) розуміють сукупність взаємозв’язаних та спеціальним чином організованих даних деякої предметної області, які зберігаються на зовнішніх носіях інформації і доступ до яких мають різні користувачі для розв’язання своїх задач. БД є інформаційною моделлю зовнішнього світу. У ній зберігаються відомості про об’єкти, їх властивості та характеристики.
Суттєві ознаки БД:
· Сукупність повідомлень чи даних;
· Повідомлення мають одинакову структуру і відносяться до однієї галузі;
· Дані організовано спеціальним чином;
Форма -це об’єкт бази даних, призначений для введення та відображення інформації. Форма містить поля, у які користувач може вводити дані або їх редагувати.
Загальноприйнято, що дані до баз даних вводяться за допомогою форм, а зберігаються у вигляді таблиць.
• мати прямий (а не послідовний) доступ до даних, як цього вимагають сучасні методи обробки даних.
За способом подання інформації із предметної області БД поділяють на фактографічні та документальні. У БД фактографічного типу фіксуються дані про події, явища, процеси, а також їх характеристики. У БД документального типу зберігаються набори документів, які містять інформацію про стан деякої предметної області. Перед створенням БД вибирають модель подання даних в ній, яку ще називають її типом.
Модель даних - це система правил, згідно з якими створюють структури даних, здійснюють доступ до даних та змінюють їх.
На даний час найбільш широко використовуються ієрархічна, мережева та реляційна моделі даних (відповідно типи БД).
В ієрархічній БД відношення між різними типами записів мають деревоподібну структуру. Елементи такого дерева відношень називають вузлами. На найвищому рівні ієрархії є вузол, який не підпорядковується жодному іншому, він називається коренем дерева. Кожний інший вузол підпорядковується тільки одному вище стоящому.
Найбільшого розповсюдження набула реляційна модель, основним способом подання даних в якій є двомірна таблиця. Зв’язки між записами різних типів тут організовуються через спільні поля. Кожний файл даних в такій моделі містить дані, які можна подати у вигляді таблиці, колонки якої відповідають окремим полям, а рядки - записам. Кожна колонка таблиці має ім’я і містить однорідні дані (однакового типу). Перевагою таких БД є наглядність і зрозумілість організації даних, швидкість пошуку потрібних даних. У БД реляційного типу зручно здійснювати сортування даних, вибірку даних, що задовольняють певним умовам. До реляційних БД можна звести ієрархічні та мережеві БД. Протягом останніх років стали досліджуватись постреляційні моделі, найбільш перспективною з яких вважається об’єктно-орієнтована модель даних. Утім вона значною мірою відтворює ідеологію ієрархічної моделі, її розвиток відбувається повільно, тож на ринку СКБД, скоріш за все, ще тривалий час домінуватимуть реляційні системи.
12 правил Кодда - набір 13 правил (пронумерованих від нуля до дванадцяти) запропонованих Едгаром Коддом, спроектовані для визначення того чи є СКБД реляційною. Іноді їх жартома називають "Дванадцять наказів Кодда". Кодд створив ці правила як частину своєї кампанії запобігання розмиванню його бачення реляційності оскільки продавці систем керування базами даних на початку 1980х просто видавали свої старі продукти за реляційні розробки. Насправді, правила настільки суворі, що всі популярні так звані "реляційні" СКБД не відповідають багатьом критеріям. Особливо складні 6, 9, 10, 11 і 12 правила.
. Фундаментальне правило (Foundation Rule)
Реляційна СУБД має бути здатною повністю керувати базою даних, використовуючи зв'язки між даними
. Інформаційне правило (Information Rule)
Інформація має бути представлена у вигляді даних, що зберігаються в осередках. Дані, що зберігаються у комірках, мають бути атомарними. Порядок рядків у реляційній таблиці не повинен впливати на зміст даних
. Правило гарантованого доступу (Guaranteed Access Rule)
Доступ до даних має бути вільним від двозначності. До кожного елементу даних має бути гарантований доступ за допомогою комбінації імені таблиці, первинного ключа рядку й імені стовпця.
. Систематична обробка Null-значень (Systematic Treatment of Null Values)
Невідомі значення NULL, відмінні від будь-якого відомого значення, мають підтримуватись для всіх типів даних при виконанні будь-яких операцій. Наприклад, для числових даних невідомі значення не повинні розглядатись як нулі, а для символьних даних - як порожні рядки.
. Правило доступу до системного каталогу на основі реляційної моделі (Dynamic On-line Catalog Based on the Relational Model)
Словник даних має зберігатись у формі реляційних таблиць, і СУБД повинна підтримувати доступ до нього за допомогою стандартних мовних засобів, тих самих, що використовуються для роботи з реляційними таблицями, які містять дані користувача.
. Правило повноти підмови маніпулювання даними (Comprehensive Data Sublanguage Rule)
Система управління реляційними базами даних має підтримувати хоча б одну реляційну мову, яка
а) має лінійний синтаксис,
б) може використовуватись інтерактивно і в прикладних програмах,
в) підтримує операції визначення даних, визначення уявлень, маніпулювання даними (інтерактивні та програмні), обмежувачі цілісності, управління доступом та операції управління транзакціями (begin, commit і rollback).
. Правило модифікації поглядів (View Updating Rule)
Кожне подання має підтримувати усі операції маніпулювання даними, які підтримують реляційні таблиці: операції вибірки, вставки, модифікації і видалення даних.
. Правило високорівневих операцій модифікації даних (High-level Insert, Update, and Delete)
Операції вставки, модифікації і видалення даних мають підтримуватись не тільки щодо одного рядку реляційної таблиці, але й щодо будь-якої безлічі рядків.
. Правило фізичної незалежності даних (Physical Data Independence)
Додатки не повинні залежати від використовуваних способів зберігання даних на носіях, від апаратного забезпечення комп'ютерів, на яких знаходиться реляційна база даних.
. Правило логічної незалежності даних (Logical Data Independence)
Представлення даних в додатку не повинно залежати від структури реляційних таблиць. Якщо в процесі нормалізації одна реляційна таблиця розділяється на дві, подання має забезпечити об'єднання цих даних, щоб зміна структури реляційних таблиць не позначалась на роботі додатків.
. Правило незалежності контролю цілісності (Integrity Independence)
Вся інформація, необхідна для підтримки цілісності, має бути у словнику даних. Мова для роботи з даними має виконувати перевірку вхідних даних і автоматично підтримувати цілісність даних.
. Правило незалежності від розміщення (Distribution Independence)
База даних може бути розподіленою, може перебувати на кількох комп'ютерах, і це не повинно впливати на додатки. Перенесення бази даних на інший комп'ютер не повинне впливати на додатки.
. Правило узгодженості мовних рівнів (The Nonsubversion Rule)
Якщо використовується низькорівнева мова доступу до даних, вона не повинна ігнорувати правила безпеки і правила цілісності, які підтримуються мовою більш високого рівня.
Нормалізація схеми бази даних - покроковий процес розбиття одного відношення (на практиці: таблиці) відповідно до алгоритму нормалізації на декілька відношень на базі функціональних залежеостей.
Нормальна форма - властивість відношення в реляційної моделі даних, що характеризує його з точки зору надмірності, яка потенційно може призвести до логічно помилкових результатів вибірки або зміни даних. Нормальна форма визначається як сукупність вимог, яким має задовольняти відношення. Таким чином, схема реляційної бази даних переходить у першу, другу, третю і так далі нормальні форми. Якщо відношення відповідає критеріям нормальної форми n, та всіх попередніх нормальних форм, тоді вважається, що це відношення знаходиться у нормальній формі рівня n.
Перша нормальна форма (1НФ, 1NF) утворює ґрунт для структурованої схеми баз даних: Кожна таблиця повинна мати основний ключ: мінімальний набір колонок, які ідентифікують запис. Уникнення повторень груп (категорії даних, що можуть зустрічатись різну кількість разів в різних записах) правильно визначаючи не-ключові атрибути. Атомарність: кожен атрибут повинен мати лише одне значення, а не множину значень.
Друга нормальна форма (2НФ, 2NF) вимагає, аби дані, що зберігаються в таблицях із композитним ключем не залежали лише від частини ключа: Схема бази даних повинна відповідати вимогам першої нормальної форми. Дані, що повторно з'являються в декількох рядках виносяться в окремі таблиці.
Третя нормальна форма (3НФ, 3NF) вимагає, аби дані в таблиці залежали винятково від основного ключа: Схема бази даних повинна відповідати всім вимогам другої нормальної форми. Будь-яке поле, що залежить від основного ключа та від будь-якого іншого поля, має виноситись в окрему таблицю.
Нормальна форма Бойса - Кодда. Відношення знаходиться в НФБК, тоді і лише тоді коли детермінант кожної функціональної залежності є потенційним ключем. Якщо це правило не виконується, тоді щоб привести вказане відношення до НФБК його слід розділити на два відношення шляхом двох операцій проекції на кожну функціональну залежність детермінант, якої не є потенційним ключем. Проекція без атрибутів залежної частини такої функціональної залежності; Проекція на всі атрибути цієї функціональної залежності. Визначення НФБК не потребує жодних умов попередніх нормальних форм. Якщо проводити нормалізацію послідовно, то в переважній більшості випадків при досягненні 3НФ автоматично будуть задовольнятися вимоги НФБК. 3НФ не збігається з НФБК лише тоді, коли одночасно виконуються такі 3 умови: Відношення має 2 або більше потенційних ключів. Ці потенційні ключі складені (містять більш ніж один атрибут). Ці потенційні ключі перекриваються, тобто мають щонайменше один спільний атрибут.