Первая страница
Наша команда
Контакты
О нас

    Головна сторінка



Конспект лекцій зміст модуль №1 «Основні поняття систем баз даних. Реляційна модель даних» 2

Конспект лекцій зміст модуль №1 «Основні поняття систем баз даних. Реляційна модель даних» 2




Сторінка7/7
Дата конвертації18.05.2017
Розмір0.69 Mb.
1   2   3   4   5   6   7

2.3 Створення бази даних і управління базою даних. Розробка додатка користувача


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

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

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

Логічна структура БД визначає:

таблиці та їх імена;

імена полів, названих атрибутами кожної таблиці;

характеристики полів, а також тип даних;

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

зв’язки між таблицями.

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

Під час розроблення таблиці і зв’язків часто виникають логічні суперечності. Процес нормалізації таблиць (відношень) допомагає уникнути цих суперечностей. Нормалізація відношень – це процес зміни таблиць, ключів, полів і зв’язків, в результаті яких створюється структура БД без суперечностей. Нормалізація досягається шляхом перевірки відповідності таблиць ряду умов, які визначаються в трьох рівнях нормалізації: першій, другій та третій нормальних формах (існують також і інші рівні). Нормалізація відношень дозволяє істотно скоротити обсяг збереженої інформації. Принцип нормалізації відношень – це основний принцип, покладений в основу методології створення концептуальної моделі реляційних даних. У СКБД MS SQL Server реалізовано реляційну модель даних.

У процесі фізичного створення БД в MS SQL Server створюється структура збереження даних, що містить хоча б один файл даних і один файл журналу транзакцій. У файли БД записується інформація про основні її об’єкти – таблиці, індекси тощо, а в журнал транзакцій – інформація про процес роботи з транзакціями (контроль цілісності, стан БД до і після виконання транзакції і т. ін.). БД у MS SQL Server зберігається у файлах різних типів, які автоматично створюються під час створення БД. Кожна БД використовує не менше двох файлів. Можна виділити три типи файлів БД:

основний файл даних – відправна точка БД. У кожній БД є тільки один основний файл даних з розширенням .mdf;

додаткові файли даних – необов’язкові файли, в яких можна зберігати всі дані й об’єкти, що не ввійшли в основний файл даних. У БД може бути декілька таких файлів, їх розширення .ndf;

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

Розширення назви файлу (англ. filename extension; також розширення імені файлу або просто розширення файлу) - послідовність символів, що додаються до назви файлу і призначені для ідентифікації типу (формату) файлу.
ldf.

Ведення журналу транзакцій в MS SQL Server обов’язкове, його не можна відключити. Всі зміни даних проводяться через журнал транзакцій.

Фізичне створення БД – це процес завдання імені БД, визначення розмірів та розміщення файлів БД. Нова БД – це копія системної БД model. Будь-які параметри БД model копіюються в нову БД. У MS SQL Server відомості про кожну БД зберігаються в системніому поданні sys.databases системної БД master. БД створюється за допомогою MS SQL Server Management Studio або оператором Transact-SQL CREATE DATABASE з параметрами. Створюючи БД можна задавати деякі параметри:

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

FILENAME – задає фізичне ім’я і шлях до файлу;

SIZE – вказує розмір файлу в мегабайтах (Мбайт). параметр SIZE задає мінімальний розмір файлу. Файл може збільшуватися, але не можна стиснути його так, щоб його об’єм став менше заданого мінімального розміру;

MAXSIZE – вказує максимальний розмір файлу в мегабайтах. Якщо розмір не вказано, файл буде збільшуватися до повного заповнення диску;

FILEGROWTH – задає крок приросту розміру файлу. Якщо треба збільшити розмір файлу, MS SQL Server збільшує його на значення, задане параметром FILEGROWTH.

Після створення логічної структури БД і самої БД можна приступити до створення в СКБД MS SQL Server об’єктів. Створюючи таблицю, необхідно вказати її ім’я, ім’я полів та їх типи даних. Імена полів мають бути унікальними в межах таблиці, але в різних таблицях однієї БД можливе використання однакових імен полів. Таблиці БД створюються за допомогою MS SQL Server Management Studio або оператором Transact-SQL CREATE TABLE. Доповнення таблиці полем виконується операторами ALTER TABLE та ADD.

Кожне відношення має ключі. Ключ  це комбінація полів, яка ідентифікує логічний запис (кортеж) таблиці. Один з ключів беруть за первинний. Первинний ключ однозначно ідентифікує кортеж. Якщо всі значення в одному полі таблиці подані в полі другої, зазвичай говорять: перше поле посилається на друге. Наприклад, поле KOD_POST (атрибут “код постачальника”) таблиці TOVAR (дод. А) посилається на поле KOD_POST таблиці POSTAV, тобто кожний кортеж з інформацією про постачальника має поле KOD_POST, що вказує на товар, який зберігається у файлі TOVAR. Графічне подання зв’язків між таблицями БД nf_optovik наведено в додатку А.

Якщо одне поле в таблиці посилається на інше в другій таблиці, то перше поле називають зовнішнім ключем (FOREIGN KEY), а поле, на яке воно посилається, – батьківським ключем (PRIMARY KEY). Таким чином, поле KOD_POST таблиці POSTAV є батьківським ключем, а поле KOD_POST таблиці TOVAR – зовнішнім ключем. Імена зовнішнього і батьківського ключів не обов’язково мають бути однаковими, а зовнішній ключ – не обов’язково складатися з одного поля. Подібно до первинного ключа, зовнішній ключ може мати будь-яку кількість полів, які всі разом оброблюються як єдине ціле. Зовнішній ключ і батьківський ключ обов’язково повинні мати однакову кількість полів, однаковий тип поля і розмір кожного поля, а у разі використання декількох полів – мати однаковий порядок.

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

Мова Transact-SQL автоматично підтримує довідкову цілісність даних за допомогою обмеження FOREIGN KEY. Це обмеження визначає значення, які можна вводити в БД так, щоб зовнішній та батьківський ключі відповідали принципу довідкової цілісності. Одна з дій цього обмеження – відкидання значень для полів, позначених як зовнішній ключ, яких немає в батьківському ключі.

Підтримка довідкової цілісності потребує обмежень і на значення, які можуть бути в полях, заявлених як зовнішній і батьківський ключі. Це означає, зокрема, що батьківський ключ має бути унікальним і не мати NULL значень, тобто всі поля, які використовуються як батьківські ключі, повинні мати обмеження PRIMARY KEY або UNIQUE і NOT NULL.

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

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

При створенні таблиці в її визначенні може бути зазначено одне обмеження PRIMARY KEY. Якщо таблиця вже існує, обмеження PRIMARY KEY може бути додано лише в тому випадку, якщо для таблиці ще не визначено жодного такого обмеження. У таблиці може бути тільки одне обмеження PRIMARY KEY. Якщо обмеження PRIMARY KEY вже існує, його можна змінити або видалити.

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

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

Створюючи індекс, треба брати до уваги два фактори: характер даних і особливості запитів. MS SQL Server не переглядає всі сторінки даних таблиці, а використовує індекси для посилання на конкретну інформацію на одній зі сторінок даних. Індекси прискорюють пошук даних; прискорюють запити, що виконують з’єднання таблиць, а також сортування та групування; забезпечують унікальність записів, якщо таку унікальність визначено для створення індексу; для створення і підтримки індексів використовується сортування за зростанням; в індекси найдоцільніше включати поля, що забезпечують високий ступінь відбору, тобто ті з них, які переважно містять унікальні дані.

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

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

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

Для створення індексів таблиці БД SQL–сервера можна скористатись створенням індексу за допомогою SQL-команди CREATE INDEX. Якщо в операторі немає ключового слова UNIQUE, в індексі будуть допустимі ідентичні значення; якщо немає CLUSTERED – буде створено некластерний індекс.

Для полегшення адміністрування БД і наочного подання структур таблиць та зв’язків між ними в MS SQL Server існує об’єкт Diagrams, який є графічним відображенням логічної моделі бази даних. Діаграми не можливо створювати засобами Transact-SQL.

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

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

Програ́мний проду́кт (англ. programming product) - це: програмний засіб, програмне забезпечення, які призначені для постачання користувачеві (покупцеві, замовникові). програма, яку може запускати, тестувати, виправляти та змінювати будь-яка людина.
Класифікувати засоби розробки можна з різних позицій, наприклад, виходячи з підтримуваної ними мови програмування, або працездатності створених прикладних програм на тій або іншій платформі, або наявності в них тих або інших бібліотек і візуальних засобів. Практично будь-який засіб розробки, що претендує на універсальність, можна змусити працювати з будь-якою БД: досить підтримки застосування в цьому засобі розробки сторонніх бібліотек і наявності в цій базі даних набору клієнтських інтерфейсів  Application Programming Interface (API) для платформи, на якій повинні функціонувати створені прикладні програми.
Прикладни́й програ́мний інтерфе́йс (інтерфейс програмування застосунків, інтерфейс прикладного програмування) (англ. Application Programming Interface, API) - набір визначень взаємодії різнотипного програмного забезпечення.
Однак далеко не будь-яка пара продуктів "засіб розробки плюс СКБД" приваблива за трудовитратами, які позв'язані зі створенням подібних прикладних програм. Можна написати повноцінну прикладну програму за допомогою мови С та відповідних бібліотек, але витрати не будуть виправданими, тому що вже існують потужні засоби, орієнтовані на створення прикладних програм саме для роботи з БД.

Засоби розробки з розвитими візуальними інструментами найбільше часто застосовується при створенні клієнтських прикладних програм. До найбільш популярних продуктів подібного класу варто віднести Microsoft Visual Studio, Borland Delphi, Sybase PowerBuilder і Borland C Builder.

Останнім часом дуже популярним стало створення Web-прикладних програм. При написанні таких модулів можуть використовуватись інтерпретовані середовища розробки ­– мови Perl і Java.

Інтегроване середовище розробки (ІСР, англ. Integrated development environment або англ. IDE) - комплексне програмне рішення для розробки програмного забезпечення. Зазвичай, складається з редактора початкового коду, інструментів для автоматизації складання та відлагодження програм.
Мова Perl пристосована для обробки великих текстів і дозволяє здійснювати доступ до різних БД. Це обумовлене насамперед тим, що Perl надає розроблювачам прості і зручні засоби обробки довільних текстів і взаємодії з БД і технологією Web. Java-технологія створена з метою використання на різних платформах, має всі вище згадані можливості і найбільш стандартні засоби для легшої адаптації під конкретне середовище.

Відзначимо також, що, крім перерахованих вище "універсальних" засобів створення як прикладних програм в архітектурі клієнт-сервер, так і бізнес-об'єктів для розподілених систем, на ринку засобів розробки є і спеціалізовані засоби, призначені саме для створення бізнес-об'єктів (як правило, Web-прикладних програм).

Технологія аналітичної обробки даних OLAP та багатовимірні сховища даних.

Ефективне управління крупним і середнім бізнесом сьогодні неможливе без застосування новітніх інформаційних технологій, зокрема без систем підтримки прийняття рішень (СППР). СППР – це системи, які призначені для аналізу ділової інформації. Подібні системи створюються на основі таких теорій , як дослідження операцій, теорія поведінки, наукова теорія управління, а також методів статистичної обробки і дозволяють вирішувати наступні класи задач [6].

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


Аналітичні – обчислення заданих показників та статистичних характеристик бізнес-діяльності на основі інформації із БД.

Візуалізація даних – наочне графічне і табличне представлення інформації.

Здобуття знань (data mining) – визначення взаємозв’язків та взаємозалежностей бізнес-процесів на основі існуючої інформації. Наприклад, перевірка статистичних гіпотез. Шляхом аналізу економічних та фінансових показників діяльності компаній, які потім збанкрутіли, банк може виявити деякі стереотипи, які можна буде урахувати при оцінці показника ризику кредитування.

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

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

Оптимізаційні – засновані на інтеграції імітаційних, управлінських, оптимізаційних та статистичних методів моделювання та прогнозування.
Складна́ систе́ма - система, поняття, що широко використовується в сучасній науковій літературі і вказує на специфічні особливості об'єктів дослідження практично в усіх розділах природничих та гуманітарних наук.
Математи́чна моде́ль - система математичних співвідношень, які описують досліджуваний процес або явище. Математична модель має важливе значення для таких наук, як: економіка, екологія, соціологія, фізика, хімія, механіка, інформатика, біологія та ін.
Стати́стика - наука, що вивчає методи кількісного охоплення і дослідження масових, зокрема суспільних, явищ і процесів. А також власне кількісний облік масових явищ. Зокрема, облік у будь-якій галузі господарства, суспільного життя, що здійснюється методами цієї науки, а також дані цього обліку.
Задачі даного класу дозволяють вибрати з множини можливих управлінь ті з них, які забезпечують найефективніше (з точки зору заданого критерію) просування до поставленої мети.

СППР засновані на пов’язаних між собою технологіях: сховища даних (data warehouse), магазини даних (data mart), банки оперативних даних (operational data store), оперативна аналітична обробка OLAP.

OLAP-система повинна базуватися на спеціальній БД – сховищі даних. В залежності від задач сховище даних може бути реалізоване як на основі багатовимірної бази, так і на основі реляційної. Дані, які зберігаються в базах з реляційною моделлю, зовні представлені у вигляді таблиць, які складаються із рядків та стовпчиків. Такі структури даних найкращим чином забезпечують оперативну обробку інформації, яка постійно надходить (On-Line Transaction Processing, OLTP), але в меншому ступені пристосовані на побудові на їхній основі СППР. OLTP системи орієнтовані на прикладні програми, які виконують за відносно короткий проміжок часу велику кількість транзакцій, пов’язаних з додаванням, та поновлень достатньо невеликих об’ємів інформації, яка розміщена по різним взаємозв’язаним таблицям. В типовій ситуації, наприклад, потрібно поновити усі дані, пов’язані з конкретним замовником. Кожна таблиця містить ідентифікаційний номер замовника, який використовується для встановлення зв’язків між різними таблицями. Такий простий зв’язок між записами дозволяє при додаванні чи зміні даних модифікувати за одну транзакцію відносно невелику кількість записів.

В багатовимірній моделі дані представлені у вигляді багатовимірного куба, у якого виміри відповідають вісям куба, а змінні – індивідуальним коміркам куба. Наприклад, якщо аналізувати об’єм продажу по товарам в залежності від регіону і часу, то в такому випадку треба розглядати модель багатовимірної БД з трьома вимірами (товар, регіон, місяць) та одним показником об’ємом продажу (рис.2.3).



Рис. 2.3 Багатовимірна модель представлення даних.
Багатовимірна модель дозволяє робити плоскі зрізи куба даних та повертати його потрібною гранню будь-яким зручним способом. Використовуючи багатовимірну модель, аналітик може легко отримати представлення даних у відповідності до власних інтересів.

Як реляційні моделі з рядків та стовпчиків, так і багатовимірні моделі кубів, є логічним представленням інформації. Насправді дані на диску зберігаються у вигляді деякої впорядкованої структури, яка відображається в логічну модель тільки при запитах користувача. Тому система оперативного аналізу може бути побудована і на основі реляційної бази. Цей напрямок розвитку програмне забезпечення отримало назву Relational OLAP (ROLAP). Типовий представник – Oracle Discoverer.

На відміну від ROLAP оперативний аналіз даних, який реалізується на основі багатовимірних БД, отримав назву Multidimensional OLAP (MOLAP). Перевага використання багатовимірних БД – їх потужність. Час виконання OLAP-операцій в багатовимірних базах даних може на декілька порядків перевищувати відповідний показник для реляційних БД.

Об’єктно-орієнтовані БД

Великий інтерес викликають результати досліджень, отримані за останній час в галузі об’єктно-орієнтованих систем БД або скорочено – об’єктних систем. Деякі автори вважають їх серйозним конкурентом реляційним системам.

Об’єктні системи беруть свій початок від об’єктно-орієнтованих мов програмування. Основна ідея, яка поєднує ці дві області, полягає в тому, щоб відгородити користувача від конструкцій, пов’язаних з апаратним забезпеченням, таким як біти або байти (а може записи і поля).

Апара́тне забезпе́чення (англ. hardware; сленг. залі́зо) - комплекс технічних засобів, який включає електронний пристрій і, зокрема, ЕОМ: зовнішні пристрої, термінали, абонентські пункти тощо, які необхідні для функціонування тієї чи іншої системи; фізична частина ЕОМ.
Замість цього користувач має справу з об’єктами і операціями над цими об’єктами, які більше відповідають своїм аналогам в реальному часі.
Реальний час - режим роботи автоматизованої системи обробки інформації і керування, при якому враховуються обмеження на часові характеристики функціювання.
Наприклад, використовуючи спеціальні терміни, можливо уявляти відділ, як “кортеж ОТД“ з набором відповідних “кортежів РАБ”, тобто співробітників, які мають “значення зовнішніх ключів”, які “посилаються” на “значення первинного ключа” в “кортежі ОТД”. В новій технології користувач буде мати справу з об’єктом відділу, який вміщує відповідну множину об’єктів співробітників. Інакше кажучи, фундаментальна ідея об’єктного підходу – підвищення рівня абстракції.



В загальній та класичній постановці об’єктно-орієнтований підхід базується на концепціях: об’єкта та ідентифікатора об’єкта, атрибутів і методів, класів, ієрархії та наслідування класів. При такому наборі базових понять об’єктно-орієнтований підхід дуже близький до язиків програмування з абстрактними чи довільними типами даних. З іншого боку, об’єктно-орієнтований підхід дуже близький до семантичного моделювання. Фундаментальні абстракції, які лежать в основі семантичних моделей, неявно використовують і в об’єктно-орієнтованому підході.
1   2   3   4   5   6   7



  • Application Programming Interface