конспект лекцій (ТСПП). Конспект лекцій з дисципліни 07 технологія створення програмних продуктів напряму 050101 Компютерні науки
 Скачать 14.87 Mb.
|
5.4. Архітектура баз даних. Реляційні особливості SQL ServerЯк ми вже з'ясували, дані Microsoft SQL Server 7.0 зберігаються в базах даних (мал. 1.33), які організовані в логічні компоненти, видимі користувачеві. Фізична реалізація бази даних є два або більше файлів на диску. Така фізична організація баз даних істотно відрізняється від вживаної в SQL Server 6.x, де передусім необхідно було створити пристрій (device) - саме воно зіставлялося з файлом на диску, на якому можна було створювати декілька баз даних. Проте з точки зору клієнтського застосування ситуація мало змінилася, оскільки фізична реалізація бази даних, в основному, цікавить тільки адміністратора.  У SQL Server є декілька зумовлених баз даних. Передусім, це чотири системні бази даних : master, model, tempdb і msdb. Крім того, можуть бути визначені призначені для користувача бази даних (мал. 1.34) ./ Примітка При підключенні до SQL Server з'єднання асоціюється з конкретною базою даних на сервері, яка називається поточною базою даних. Перемикатися між базами даних з клієнтського застосування можна за допомогою інструкції Transact - SQL USE ім'я_бази_даних, або використовуючи функції API, які змінюють зміст поточної бази даних. SQL Server 7.0 дозволяє від'єднувати базу даних від сервера і приєднувати її до іншого сервера або знову до того ж самому. Незалежно від того, є база даних системною або призначеною для користувача, усі вони підкоряються певним правилам. Розглянемо їх коротко. Реляційні особливості SQL Server Основною характеристикою бази даних SQL Server є те, що вона має реляційну структуру. Для того, щоб реалізувати доступ до даних за допомогою SQL Sewer, необхідно розуміти особливості реляційної бази даних, оскільки не можна побудувати правильний запит до реляційної бази даних, не знаючи її базових характеристик. Доктор Е. Ф. Кодд (Е. F. Codd) розробив модель реляційної бази даних в 1970 році як зручніший засіб зберігання, вибірки і маніпулювання даними в порівнянні з ієрархічними і мережевими базами даних, які створювали певні труднощі при проектуванні і розробці, - іноді було дуже складно написати відповідний запит для доступу до даних. У статті, опублікованій в журналі "ComputerWord, доктор Кодд сформулював дванадцять правив, яким повинна відповідати дійсно реляційна база даних (вони є напівофіційним визначенням поняття реляційна база даних) : Правило інформації. Уся інформація в базі даних має бути представлена виключно на логічному рівні і тільки одним способом - у вигляді значень, що містяться в таблицях. Примітка Це неформальне визначення реляційної бази даних. Правило гарантованого доступу. Логічний доступ до усіх і кожному компоненту (атомарному значенню) в реляційних базах даних повинен забезпечуватися шляхом використання комбінації імені таблиці, первинного ключа і імені стовпця. Примітка Правило вказує на роль первинних ключів при пошуку інформації в базі даних : ім'я таблиці дозволяє знайти необхідну таблицю, ім'я стовпця дозволяє знайти необхідний стовпець, а первинний ключ - шуканий елемент даних. Правило підтримки недійсних значень. У справжній реляційній базі даних має бути реалізована підтримка недійсних значень, які відрізняються від рядка символів нульової довжини, рядки пропусків і від нуля або будь-якого іншого числа і використовуються для представлення відсутності даних, незалежно від їх типу. Примітка Відсутні дані мають бути представлені за допомогою спеціальних недійсних значень (NULL). Правило динамічного каталогу, заснованого на реляційній моделі. Опис бази даних на логічному рівні має бути представлений в тому ж виді, що і основні дані, щоб користувачі, що мають відповідні права, могли працювати за допомогою тієї ж реляційної мови, яку вони застосовують для роботи з основними даними. Примітка База даних повинна містити набір системних таблиць, що описують структуру самої бази даних. Правило вичерпного подъязыка даних. Реляційна система може підтримувати різні мови і режими взаємодії з користувачем (наприклад, режим питань-відповідей). Проте повинна існувати принаймні одна мова, оператори якої можна представити у вигляді рядків символів відповідно до деякого чітко певного синтаксису і який повною мірою підтримує наступні елементи :
Система управління базами даних повинна використовувати мову реляційної бази даних, наприклад, SQL. Правило оновлення представлень. Усі представлення, які теоретично можна відновити, мають бути доступні для оновлення. Примітка Представлення - віртуальні таблиці, повинні показувати різним користувачам різні фрагменти структури бази даних. Правило додавання, оновлення і видалення. Можливість працювати з відношенням (таблицею) як з одним операндом повинна існувати не лише при читанні даних, але і при додаванні, оновленні і видаленні даних. Примітка Правило акцентує увагу на тому, що бази даних за своєю природою мають бути орієнтовані на роботу з множинами, а не тільки з окремими рядками. Правило незалежності фізичних даних. Прикладні програми і утиліти для роботи з даними повинні на фізичному рівні залишатися незайманими при будь-яких змінах способів зберігання даних або методів доступу до них. Примітка Конкретні чини реалізації зберігання і доступу до даних, використовувані в системі управління базами даних, не повинні впливати на можливість користувача працювати з базою даних. Правило незалежності логічних даних. Прикладні програми і утиліти для роботи з даними повинні на логічному рівні залишатися незайманими при внесенні в базові таблиці будь-яких змін, які теоретично дозволяють зберегти незайманими що містяться в цих таблицях дані. Правило незалежності умов цілісності. Повинна існувати можливість визначати умови цілісності, специфічні для конкретної реляційної бази даних, на подъязыке реляційної бази даних і зберігати їх в каталозі, а не в прикладній програмі. Примітка Мова бази даних повинна підтримувати деякі обмежувальні умови, що накладаються на дані, що вводяться, і на дії, які можуть бути виконані з даними. Правило незалежності поширення. Реляційна система управління базами даних не повинна залежати від потреб конкретного клієнта. Примітка Мова бази даних повинна забезпечувати можливість роботи з розподіленими даними, розташованими на різних комп'ютерних системах. Правило єдиності. Якщо в реляційній системі є низькорівнева мова (оброблювальний за один раз один запис), то має бути відсутньою можливість його використання для того, щоб обійти правила і умови цілісності, виражені на реляційній мові високого рівня. Примітка Не повинно бути інших можливостей для роботи з базою даних окрім мови бази даних, оскільки це може порушити її цілісність. У реляційній моделі бази ланных Кодда звернення до даних відбувається так, як ніби вони збережені в двовимірній таблиці. Реальне фізичне місце розташування даних, що має велике значення з точки зору часу, необхідного для обробки інформації, не впливає на синтаксис, використовуваний при зверненні до даних. Модель двовимірної таблиці дозволяє звертатися до даних як до рядків і стовпців таблиці. З цієї причини дані сприймаються набагато легше. Це пов'язано з тим, що в щоденному житті вам часто зустрічаються подібні таблиці з тими, що зберігаються в них даними. Розклади потягів, літаків є таблицями. Наприклад, ви можете створити типову робочу таблицю (мал. 1.35). Рядки таблиці в реляційній моделі Кодда не впорядковані. У реляційній моделі, використовуваній в SQL Server, таблиці бази даних також не упорядковуються, якщо створити для таблиці спецыальный кластерний індекс. Після того, як для таблиці створений індекс такого твань, рядки зберігаються впорядкованими по одному або двох стовпцях, які вибрані при созданиии індексу.
Мал. 1.35. Приклад звичайної таблиці з розкладом авіарейсів Слід зауважити, що інструкції для доступу до рядків таблиці не залежать від впорядкованості цих рядків. Якщо вам необхідно, щоб рядки таблиці були лічені і відображені в певному порядку, інструкція для прочитування рядків повинна задати цей порядок. Інакше запит прочитує рядки так, як вони зберігаються. Реляційна модель вимагає, щоб кожен рядок був унікально визначений, принаймні, одним стовпцем таблиці - унікальним ключем (unique key). Виконання цієї вимоги дозволяє діставати доступ до кожного рядка і змінювати її незалежно від інших рядків таблиці. Мова запитів (query language), вживана для доступу до рядків таблиці, використовує дані тільки конкретного рядка, тим самим маючи можливість відокремити один рядок від іншої. SQL Server не вимагає, щоб рядки таблиці були унікальні. Ви можете створити дві або декілька рядків, до яких не можна звернутися окремо. Хоча досить складно знайти застосування для рядків, що повторюються, можливо, деяким користувачам такі рядки були б зручні для роботи з певними застосуваннями. Якщо ви хочете запобігти повторенням, до таблиці можуть бути додані певні умови на значення Примітка Якщо немає абсолютної упевненості в тому, що рядки, що повторюються, вам дуже потрібні, слід забезпечити унікальність рядків таблиці. У відсутність засобів підтримки унікальності мабуть випадкове додавання одній або рядків, що більше повторюються, в таблицю. І слід мати на увазі, що після додавання рядків, що повторюються, видалити або змінити їх дуже непросто. Література
Лекція № 6 |