Відношення "один до багатьох" означає ситуацію, коли рядок однієї таблиці відповідає декільком рядкам іншої таблиці. Це найпоширеніший тип відносин. На діаграмах він виражається записом 1:N.

    Нарешті, при відношенні "багато–до-багатьох" рядки першої таблиці можуть бути пов'язані з довільним числом рядків у другій таблиці. Таке відношення записується як N:M.

2.2 Системи керування базами даних

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

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

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

    Схема призначена для контролю цілісності даних. Якщо, приміром, оголошено, що поле містить ціле значення, то СКБД відмовиться  записувати в нього числа із плаваючою  комою або рядки. Відносини між записами теж чітко контролюються, і неузгоджені дані не допускаються. Операції можна групувати в транзакції, виконувані за принципом "все або нічого".

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

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

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

2.3 Системи керування файлами

 

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

    Системи керування файлами не можна класифікувати  як СКБД, тому що звичайно вони є частиною операційної систем і нічого не знають про внутрішній зміст файлів. Це знання закладене в прикладних програмах, що працюють із файлами. Як приклад можна привести таблицю користувачів UNIX, що зберігається у файлі /etc/passwd. Програми, що звертаються до цього файлу, знають, що в його першому полі перебуває ім'я користувача, що кінчається двокрапкою. Якщо додатку потрібно відредагувати цю інформацію, він повинний безпосередньо відкрити файл і подбати про правильне форматування полів.

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

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

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

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

2.4 Реляційні бази даних

 

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

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

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

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

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

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

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

    Реляційна база даних створюється й потім управляється за допомогою спеціальних засобів — реляційних систем керування базами даних (РСУБД).  

    Історично РБД діляться на [8]:

    РБД (РСУБД), створені для дуже більших (більше 1 Гбайт) баз даних архітектури  « клієнт-сервер». Перші розробки виконані для більших комп'ютерів IBM, у яких використовується мова SQL;

    РБД (РСУБД), створені спеціально для ПК, типу dbase, у яких архітектура така, що база й користувач перебувають на одному комп'ютері.

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

2.5 Висновки

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

 

3. ПРОГРАМНЕ ЗАБЕЗПЕЧЕННЯ ПРОЕКТНИХ РОБІТ.  
МОВА СТРУКТУРОВАНИХ ЗАПИТІВ SQL

3.1 Вставка, поновлення та вилучення даних за допомогою SQL

 

    Після створення схеми бази даних за допомогою команди SQL CREATE TABLE нові таблиці є порожніми, тобто не містять записів. Це перевіряється за допомогою наступного запиту.

SELECT COUNT(*) FROM таблиця

    Для новоствореної таблиці цей запит  поверне один рядок та один стовпчик із значенням 0 (кількість записів  таблиці дорівнює 0).

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

• INSERT – вставка.
• UPDATE – поновлення.
• DELETE – вилучення.

    Запит на вставку даних в таблицю  має наступну структуру.

INSERT INTO таблиця [(поле,…)]

{SELECT-запит | список_значень_полів};

    Вставка може відбуватися двома способами:

• На основі SELECT-запиту.
• На основі конкретних значень.

    Якщо  вставка в таблицю відбувається на основі SELECT-запиту, то кількість та типи виразів SELECT-запиту повинні відповідати кількості та типу полів, перерахованих в дужках після назви таблиці.

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

список_значень_полів ::=

VALUES список_значень

список_значень ::=

({вираз | NULL},…)

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

    Якщо  після назви таблиці не перераховувати поля, то вставка здійснюється в  усі поля таблиці в тому порядку, в якому вони були перераховані в команді CREATE TABLE.

    Слід  пам’ятати, що вставка не-NULL-значень повинна здійснюватися в усі обов’язкові поля.

    Запит на поновлення даних має наступний  вигляд.

UPDATE таблиця

SET {поле = {вираз | NULL}},…

[WHERE предикат];

    Запит UPDATE задає полям таблиці нові значення, що подаються у вигляді виразу або значення NULL, у всіх записах, які задовольняють предикату. Якщо частина WHERE відсутня, то поновлюються усі записи з таблиці.

    Вираз може будуватися на основі існуючих значень поля.

… SET поле = поле+1,…Дозволяється також присвоювати значення одних полів іншим. 
… SET поле_A = поле_B+1,…

    В одному операторі UPDATE можна вносити зміни в поле лише один раз.

    Запит на вилучення даних має наступну структуру.

DELETE FROM таблиця

[WHERE предикат];

    Запит DELETE FROM вилучає з таблиці усі записи, які задовольняють предикату. Якщо частина WHERE відсутня, то вилучаються усі записи з таблиці.

    Розглянемо  спроектовану за допомогою ER-діаграми схему бази даних (рис. 3.1).