Ім'я файлу: бази даних.docx
Розширення: docx
Розмір: 208кб.
Дата: 21.03.2021

«Інститут інноваційної освіти

Київського національного університету будівництва і архітектури»
Кафедра будівництва та інформаційних технологій
Контрольна РОБОТа

з дисципліни «Бази даних»

на теми:

1. Моделі організації даних.

2. Поняття нормалізації. Перша, друга та третя нормальні форми.

3. MS Access.Створення таблиць. Типи поділів та їхні властивості.

Зміст


Вступ 3

1. Моделі організації даних. 4

2.Поняття нормалізації. Перша, друга та третя нормальні форми. 7

3.2. Перша нормальна форма 8

3.3. Друга нормальна форма 11

3.4. Третя нормальна форма 14

3. MS Access.Створення таблиць. Типи поділів та їхні властивості. 16

Висновки 20

Список використаних джерел 22




Вступ


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

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

1. Моделі організації даних.


Моделі організації даних

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

  • припустимою організацією даних;

  • обмеженнями цілісності;

• безліччю припустимих операцій.

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

Ієрархічна модель

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



Рис1. Схема ієрархічної моделі даних

Типовим представником сімейства баз даних, заснованих на ієрархічній моделі, є Information Management System (IMS) фірми IBM, перша версія якої з'явилася в 1968 р.

Мережева модель

Концепція мережевоїмоделіданих пов'язана з ім'ям Ч. Бахмана. Мережевий підхід до організації даних є розширенням ієрархічного. В ієрархічних структурах запис-нащадок повинна мати в точності одного предка; у мережевій структурі даних нащадок може мати будь-яке число предків (рис. 2).



Рис.2. Схема мережевої моделі даних

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

Прикладом системи керування даними з мережною організацією є Integrated Database Management System (IDMS) компанії Cullinet Software Inc., розроблена в середині 70-х років. Вона призначена для використання на «більших» обчислювальних машинах. Архітектура системи заснована на пропозиціях Data Base Task Group (DBTG), Conference on Data Systems Languages (CODASYL), організації, відповідальної за визначення стандартів мови програмування Кобол.

Серед достоїнств систем керування даними, заснованих на ієрархічній або мережній моделях, можуть бути названі: їхня компактність й, як правило, висока швидкодія, а серед недоліків - не універсальність, високий ступінь залежності від конкретних даних.
Реляційна модель даних

Концепції реляційної моделі вперше були сформульовані в роботах американського вченого Едгара Кодда і ґрунтується на понятті відношення (relation). Звідки відбувається її друга назва — модель Кодда.



Мал. 3. Схема реляційної моделі даних

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

2.Поняття нормалізації. Перша, друга та третя нормальні форми.


З одного боку, процес проектування структури БД є творчим, неоднозначним, з іншого боку, його вузлові моменти можуть бути формалізовані [4 – 7, 10, 12]. У процесі розробки логічна модель даних постійно тестується й перевіряється на відповідність вимогам користувачів. Коректність логічної моделі даних забезпечується процедурою нормалізації.

Процедура нормалізації БД полягає в усуванні надмірності даних та виявленні функціональних залежностей. Усунення надмірності даних гарантує компактність наборів даних за рахунок уникнення їх зайвого дублювання та унеможливлює виникнення аномалій вставки, вилучення й оновлення кортежів після фізичної реалізації БД. Функціональна залежністьпов'язує атрибути в одному відношенні з єдиним значенням в іншому. Функціональну залежність для відношень А та B прийнято позначати як AB. Це поняття підводить “на один крок” до спорідненої концепції об'єднання відношень зв'язками типу один до одного (1:1) або один до багатьох (1:М).

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

Існують такі рівні нормалізації: перша нормальна форма (1НФ), 2НФ3НФ, нормальна форма Бойса-Кодда (БКНФ), 4НФ5НФ. Але дотепер жодна з реляційних СКБД не надає належної підтримки усім п'яти нормальним формам. Це відбувається через жорсткі вимоги до продуктивності. Суть справи полягає в тому, що в повністю нормалізованій БД для виконання запиту треба з'єднати настільки багато таблиць, що продуктивність такої системи не зможе задовольнити користувачів. Тому на практиці використовують лише перші три рівня нормалізації – 1НФ2НФЗНФ.

3.2. Перша нормальна форма


Відношення буде зведено допершої нормальної форми(1НФ) тоді й тільки тоді, коли всі його атрибути містять тільки неподільні (атомарні) значення й у ньому відсутні групи атрибутів з однаковими за змістом значеннями, які повторюються у межах одного кортежу.

Неподільність значення атрибута говорить про те, що його не можна розбити на більш дрібні частини. Наприклад, якщо у атрибуті «Прізвище, ім'я, по батькові» міститься прізвище, ім'я та по батькові читача, вимога неподільності не виконується (рис. 3.1, а). Тут необхідно виділити в окремі атрибути ім'я та по батькові. У результаті вийде три атрибути відношення «Читачі»: «Прізвище», «Ім'я» і «По батькові» (рис. 3.1, б).



Рис. 3.1. Можливі специфікації ненормалізованого відношення «ЧИТАЧІ»

На більш дрібні частини можна розбити атрибути: «Місце народження» («Країна», «Адміністративне утворення», «Населений пункт»); «Місце видачі паспорта» («Країна», «Адміністративне утворення», «Населений пункт»); «Місце основної роботи» («Тип підприємства», «Назва підприємства»), «Місце проживання» («Країна», «Адміністративне утворення», «Населений пункт», «Житловий масив / Проспект / Вулиця / Провулок», «Будинок», «Корпус», «Квартира»), рис. 3.1, б.

Для контакту читач може визначити один, декілька або жодного номеру телефону. Таким чином у загальному випадку інформація у атрибуті «Номер телефону» може бути розділена на декілька частин, кожна з яких є окремим телефонним номером (рис. 3.1, а). На перший погляд, цю проблему можна вирішити так само, як і для прізвища, імені та по батькові, виділивши для найпоширеніших типів телефонів окремі атрибути (рис. 3.1, б). Однак у цьому випадку ми зіткнемося з групою атрибутів, що мають однакові за змістом значення в межах одного кортежу, наприклад: «Домашній телефон», «Робочій телефон», «Мобільний телефон».

Щоб відношення «ЧИТАЧІ» (рис. 3.1, б) відповідало 1НФ, треба вилучити з нього групу атрибутів з номерами телефонів, які повторюються в межах одного кортежу, в інше відношення разом з копією ключового атрибута «№ квитка читача» (рис. 3.2). Причому, для подання номера й типу телефона виділимо окремі атрибути. Це дозволяє: по-перше, урахувати не тільки три зазначені типи телефона, але й додати нові і по-друге, зазначити для кожного читача тільки ті типи телефонів, які в нього є, і по-третє, можна указувати для будь-якого читача кілька однотипних телефонів або не указувати жодного номера телефону.



Рис. 3.2. Приклад відношення «ЧИТАЧІ», яке зведено до форми 1НФ

3.3. Друга нормальна форма


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

Відношення «ЧИТАЧІ» (рис. 3.2) не зведено до форми 2НФ. У ньому кожен кортеж однозначно ідентифікується такими атрибутами: «№ квитка читача», «Серія паспорта» і «№ паспорта». Сукупність цих атрибутів є суперключем цього відношення. Він складається з двох потенційних ключів, кожен з яких окремо може ідентифікувати кортежі відношення. Із двох потенційних ключів за первинний вибирається той, довжина якого мінімальна. Наявність обох потенційних ключів обумовлена вимогами користувачів.

Звести відношення «ЧИТАЧІ» до 2НФ можна, якщо винести в окреме відношення атрибути 2 – 22, які стосуються паспортних даних, і копію первинного ключа «№ квитка читача» (рис. 3.3). Однак у результаті ми одержимо відношення «ПАСПОРТНІ ДАНІ», яке має такий самий суперключ, як і відношення «ЧИТАЧІ» до його зведення до 2НФ. У нашому випадку подальша нормалізація відношення «ПАСПОРТНІ ДАНІ» неможлива.



Рис. 3.3. Приклад відношень «ТЕЛЕФОНИ» і «ЧИТАЧІ», що зведені до 2НФ

У відношенні «ТЕЛЕФОНИ» (рис. 3.3) на перший погляд здається, якщо в опис логічної моделі додати номер телефону читача, включаючи код країни, оператора або населеного пункту, то потенційним буде ключ, у складі якого всього один атрибут – «№ телефона». Однак у двох різних читачів може бути однаковий однаковим номер його домашнього або робочого телефона. Отже, однозначно, ідентифікувати кортежі можливо за складеним суперключем, до якого входять атрибути «№ квитка читача» та «№ телефону». Ми бачимо, що суперключ не є надлишковим. Його зміст збігається з первинним ключем. Виходить, що відношення «ТЕЛЕФОНИ» презентовано у другій нормальній формі.

3.4. Третя нормальна форма


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

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

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

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

Розглянемо простий приклад з обліку товару на складі. Здається логічним, щоб у відношення з оперативною інформацією про товар на складі входили у число інших такі атрибути: «Кількість товару», «Ціна за одиницю товару» та «Загальна вартість товару». Вони не є ключовими. Для одержання значення атрибута «Загальна вартості товару» необхідно перемножити між собою значення, що перебувають у атрибутах: «Кількість товару» та «Ціна за одиницю товару», тобто значення атрибута «Загальної вартості товару» залежить від величин двох атрибутів, що не входять до складу первинного ключа. Це суперечить визначенню 3НФ. Щоб дане відношення відповідало третій нормальній формі з нього треба вилучити атрибут «Загальна вартість товару».

Відзначимо, що відношення «ТЕЛЕФОНИ» і «ЧИТАЧІ» (рис. 3.3) відповідають третій нормальній формі. Це випливає з того, що вони зведені до другої нормальної форми й у них немає транзитивних залежностей.

Нижче наведений варіант визначення 3НФ, яка називається нормальною формою Бойса-Кодда (Воусе – Codd) – БКНФ, де встановлюються більш суворі вимоги.

Відношення X буде зведено до нормальної форми Бойса-Кодда тоді, коли в кожній нетривіальній функціональній залежності В→А В є суперключем.

3. MS Access.Створення таблиць. Типи поділів та їхні властивості.


Створення шляхом введення даних

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

У відкритому основному вікні MSA, ми бачимо вікно нашої бази даних «Порожня база даних 1», в меню «Об'єкти» вибираємо пункт «Таблиці», а зі списку, що з'явився у вікні, пункт «Створення таблиці шляхом введення даних» з'явилася порожня таблиця, за замовчуванням містить десять полів і що має назву «Таблиця1».

Тепер нам потрібно ввести в таблицю потрібні дані, нехай це буде таблиця типу «Ім'я Посада», тоді потрібні дані це імена і відповідні їм посади. При введенні даних ми обов'язково повинні враховувати правила введення, наприклад: тип даних в одному полі (стовпці) у всіх записах повинен бути однаковим.

Що б будь-якому користувачеві було зрозуміло які дані куди вводити, ми перейменуємо поля. Для перейменування поля робимо клік правою кнопкою миші на назві поля і в випадаючому меню вибираємо пункт «Перейменувати стовпець», виділилося назву стовпця і ми переписуємо його на необхідну нам (в даному разі буде «Ім'я» та «Посада »).

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

З'являється вікно в якому ми можемо ввести ім'я під яким буде збережена таблиця (введемо назву «Ім'я Посада»), підтверджуємо натисканням кнопки «OK».

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

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

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

Можу зауважити, що Введення даних у таблицю MSA мало чим відрізняється від введення в таблицю Excel. Для переходу між полями ви можете використовувати клавішу «Таb», а дані, введені в поточний рядок, зберігаються при переході до наступного рядка.

Створення за допомогою майстра таблиць

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

У відкритому основному вікні MSA, ми бачимо вікно нашої бази даних «Порожня база даних 2», в меню «Об'єкти» вибираємо пункт «Таблиці», а зі списку, що з'явився у вікні, пункт «Створення таблиці за допомогою майстра».

Відкрилося вікно майстра створення таблиць в якому, за допомогою інструкцій, ми можемо вибрати категорію, зразок таблиці і потрібні зразки полів за допомогою стрілок (виберемо категорію «Ділові», зразок таблиці «Працівники» і поля за аналогом з таблицею створеної в попередньому розділі, т . е. «Ім'я» та «Посада»), підтверджуємо вибір натисненням кнопки «Далі».

У наступному вікні вводимо ім'я таблиці (вводимо «Ім'я Посада») і спосіб визначення ключового поля (залишаємо за замовчуванням тобто автоматичне визначення) підтверджуємо натисканням кнопки «Далі». У наступному вікні пропонується вибрати дії після створення таблиці (залишаємо значення за замовчуванням «Ввести дані безпосередньо в таблицю) і натискаємо кнопку« Готово ».

Відкрилася готова таблиця, практично повний аналог тієї, яку ми створили у попередньому розділі, виняток становить ключове поле «Код_Імя

Посада », яке цього разу ми дозволили MSA створити автоматично. Закриваємо таблицю (натисненням кнопки «Закрити» у верхньому правому куті вікна), закриваємо MSA.

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

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

Розмір поля. Ця властивість задає максимальний розмір даних, для яких призначене поле.

Формат поля. Можна задати формат подання даних для вивода на екран або принтер. Наприклад, для дат у такий спосіб: 2/21/94 або Понеділок, Лютий 21,2010.

Число десяткових знаків. Установлює число знаків після крапки (коми). Наприклад, 2.99.

Маска введення. Задається для типів даних Текстовий і Дата/Час. Маску можна побачити на екрані при уведенні даних у поле.

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

Умова на значення. Можна задати вираз, що при уведенні або редагуванні значення поля завжди повинне бути істинним. Наприклад, < 100 означає, що значення поля повинне бути менше 100.

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

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

Індексоване поле. Встановлює додатковий індекс.

Висновки


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

Її розвиток йде за такими основними напрямками:

  • • розробка об'єктно-орієнтованих СУБД і розширення масштабів застосування об'єктно-орієнтованих БД;

  • • створення мереж баз даних, у тому числі корпоративних, intranet - з використанням принципів побудови Internet;

  • • вдосконалення режиму клієнт-сервер і мережевий зв'язку серверів;

  • • побудова сховищ даних;

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

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

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

  • • визначення моделей даних для нових типів (наприклад, просторових, темпоральних, графічних) та їх інтеграція з традиційними системами баз даних;

  • • масштабування баз даних за розміром (до петабайт), просторовому розміщенню (розподілені) і різноманіттю (неоднорідні);

  • • автоматичне виявлення тенденцій даних, структур та аномалій (добування даних, аналіз даних);

  • • інтеграція (комбінування) даних з декількох джерел;

  • • створення сценаріїв і управління потоком робіт (процесом) і даними в організаціях;

  • • автоматизація проектування та адміністрування базами даних.


Список використаних джерел


1. Методичні вказівки до виконання курсової роботи по дисципліни ″Організація баз даних і баз знань″. / Укладач В.О. Нелюбов. – Ужгород: Видавничий центр ЗакДУ, 2012. – 58 с.

2. Система управління базами даних Access. Навчальний посібник з курсу «Організація баз даних і баз знань»/ Укладач В.О. Нелюбов. – Ужгород: Редакційно-видавничій відділ ЗакДУ, 2011. – 62 с.

3. Лабораторний практикум з курсу «організація баз даних і баз знань». Розділ «керування застосунками баз даних»/ укладач В.О. Нелюбов. – Ужгород: видавничий центр ЗакДУ, 2009. – 51 с.

4. Методичні вказівки до лабораторних робіт з курсу «Організація баз даних і баз знань». Розділ «Мова запитів SQL»/ Укладач В.О. Нелюбов. – Ужгород: Видавничий центр ЗакДУ, 2010. – 28 с.

5. Методичні вказівки до лабораторних робіт з курсу ″Організація баз даних і баз знань″. Розділ ″Мова запитів QBE″/ Укладач В.О. Нелюбов. – Ужгород: Видавничий центр ЗакДУ, 2010. – 28 с.

6. Лекції з курсу ″Організація баз даних і баз знань″ в електронному вигляді / Укладач В.О. Нелюбов.

7. Нелюбов В. О., Ващук О. М. Презентація навчальних і наукових матеріалів: Електронний навчальний посібник. - Ужгород: ЗакДУ, 2011.- 156 с.: іл.
скачати

© Усі права захищені
написати до нас