Розробка інфологічної моделі і створення структури реляційної бази даних

МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ

ХЕРСОНСЬКИЙ ДЕРЖАВНИЙ ТЕХНІЧНИЙ УНІВЕРСИТЕТ

КАФЕДРА ІНФОРМАТИКИ І КОМП'ЮТЕРНИХ ТЕХНОЛОГІЙ

МЕТОДИЧНІ ВКАЗІВКИ

до проведення лабораторних робіт

на тему «Обробка даних за допомогою системи керування

базами даних ACCESS»

Заняття №3 «Розробка інфологічної моделі і створення структури

реляційної бази даних»

з дисципліни «______________________»

Херсон 2004

    Методичні вказівки до проведення лабораторних робіт «Обробка даних за допомогою системи керування базами даних ACCESS” з дисципліни_____________________________________________ для студентів усіх спеціальностей. Заняття №3 – «Розробка інфологічної моделі і створення структури реляціоної бази даних» / М. О. Дурман, С. В. Вишемирська, О. Є. Огнєва.-Херсон, ХДТУ, 2004

    Рецензент: _____________________________

ЗАТВЕРДЖЕНО на засіданні кафедри І и КТ

протокол №____ від ________________________

Зав.кафедрою___________Ф.Б.Рогальський

       Відповідальний за випуск

       Ф.Б.Рогальський, к.т.н., доцент,

       завідувач кафедрою Інформатики і комп'ютерних технологій   

ТЕОРЕТИЧНІ ВІДОМОСТІ

Розробка інфологічної моделі і створення структури реляційної бази даних

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

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

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

Можна відзначити наступні достоїнства і недоліки плоских файлів і реляційних баз даних.

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

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

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

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

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

 ,

де F(x) – це вид зв'язку А с В; G(x) – це вид зв'язку В с А.

Зв'язки можуть бути одиничними (U – унарными) і множинними N.

1. Відношення «один-до-одного»    (1:1).

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

2. Відношення «один-до-багатьох» (1:N).

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

3. Відношення «багато-до-одного»     (N:1).

Такий зв'язок прямо протилежний зв'язки «один-до-багатьох». У цьому випадку багато дітей можуть мати одних батьків.

3. Відношення «багато-до-багатьох»    (N:М).

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

Найбільш розповсюдженими є зв'язки «один-до-багатьох» і «один-до-одного».

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

КЛІЄНТИ		ПІДПИСКА				РОЗРАХУНКИ З КЛІЄНТАМИ
номер контракту	1             1	номер контракту	1			черговий номер
прізвище		пакет підписки	М		М	номер контракту
ім'я		взаєморозра-хунки		СКЛАД ПАКЕТІВ		залишок на рахунку
по батькові			1	пакет підписки		надійшло на рахунок
адреса				ОРТ		дата надходжень
телефон				НТВ		підстава зарахування
електронна пошта				КРТ		списання з рахунка
						дата списання
						підстава списання

Мал. 1. Схема зв'язків між таблицями