Подякувати Студентському архіву довільною сумою
Admin
26.02.2023 12:38
Дякуємо, що користуєтесь нашим архівом!
ОРГАНІЗАЦІЯ БАЗ ДАНИХ ТА ЗНАНЬ
Інформація про навчальний заклад
ВУЗ:
Національний університет Львівська політехніка
Інститут:
Інститут комп’ютерних наук та інформаційних технологій
Факультет:
Не вказано
Кафедра:
Програмного забезпечення
Інформація про роботу
Рік:
2007
Тип роботи:
Конспект лекцій
Предмет:
Організація баз даних і знань
Частина тексту файла (без зображень, графіків і формул):
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
НАЦІОНАЛЬНИЙ УНІВЕРСИТЕТ “ЛЬВІВСЬКА ПОЛІТЕХНІКА”
Н.Я. Павич
ОРГАНІЗАЦІЯ БАЗ ДАНИХ ТА ЗНАНЬ
КОНСПЕКТ ЛЕКЦІЙ
для студентів Інституту комп’ютерних наук та інформаційних технологій
Затверджено
на засіданні кафедри програмного забезпечення
Протокол № 3 від 18.10.2007
Львів – 2007
Павич Н.Я. Організація баз даних та знань: Конспект лекцій для студентів Інституту комп’ютерних наук та інформаційних технологій. – Львів: Видавництво Національного університету “Львівська політехніка”, 2007. – 98с.
Викладено основи сучасної теорії баз даних. Докладно розглянуто реляційну модель даних. Велику увагу приділено мові SQL. На практичних прикладах описано основні конструкції мови, а також різні типи запитів. Розглянуто операції над наборами записів, з’єднання таблиць, модифікація даних, транзакції, курсори. Матеріал супроводжується контрольними запитаннями та задачами для індивідуального виконання. Матеріал лекцій сформований для студентів напрямку "Комп’ютерні науки" або "Програмна інженерія" і обмежений обсягом, виділеним згідно робочої програми предмету, – 30 академічними годинами.
Відповідальний за випуск Федасюк Д.В., д.т.н., проф.
Рецензенти Мельник Р.А., д.т.н., проф.
Жежнич П.І., к.т.н., доц.
ЗМІСТ
ВСТУП.........................................................................................................................6
Лекція 1. РОЛЬ І МІСЦЕ БАЗ ДАНИХ В ІНФОРМАЦІЙНИХ СИСТЕМАХ.
ТИПОВА ОРГАНІЗАЦІЯ СУБД...........................................................7
1.1. Файлові системи.....................................................................................7
1.2. Системи з базами даних.........................................................................9
1.3. Розподіл обов’язків в системах з базами даних.................................10
1.4. Функції СУБД.......................................................................................11
Контрольні питання до лекції 1.......................................................................12
Лекція 2. АРХІТЕКТУРА ОРГАНІЗАЦІЇ БАЗИ ДАНИХ.
МОВИ БАЗ ДАНИХ............................................................................12
2.1. Трирівнева архітектура організації бази даних.................................12
2.2. Схема бази даних..................................................................................14
2.3. Незалежність від даних........................................................................14
2.4. Мови баз даних ....................................................................................15
Контрольні питання до лекції 2.......................................................................16
Лекція 3. МОДЕЛІ ДАНИХ. РЕЛЯЦІЙНА МОДЕЛЬ ДАНИХ.......................17
Об’єктні моделі даних..........................................................................17
Моделі даних на основі записів..........................................................18
Фізичні моделі даних...........................................................................19
Основні поняття реляційної моделі даних.........................................19
Реляційні ключі.....................................................................................21
Реляційна цілісність.............................................................................22
Контрольні питання до лекції 3.......................................................................22
Лекція 4. ДЕЯКІ АСПЕКТИ ПРОЕКТУВАННЯ РЕЛЯЦІЙНИХ
БАЗ ДАНИХ..........................................................................................23
4.1. Надлишковість даних та аномалії.......................................................23
4.2. Функціональні залежності...................................................................23
4.3. Процес нормалізації.............................................................................24
4.4. Нефункціональні залежності...............................................................27
Контрольні питання до лекції 4.......................................................................29
Лекція 5. ЗНАЙОМСТВО З МОВОЮ SQL........................................................29
Загальний огляд....................................................................................29
Типи даних в SQL.................................................................................30
Перетворення типів..............................................................................34
SQL-операції.........................................................................................34
Контрольні питання до лекції 5.......................................................................35
Лекція 6. ФОРМУВАННЯ SQL-ЗАПИТУ..........................................................35
Типові бази даних.................................................................................35
Створення запиту..................................................................................36
Усунення надлишковості вибраних даних.........................................37
Уточнення запиту за допомогою предикатів.....................................38
Контрольні питання до лекції 6.......................................................................43
Лекція 7. ОБРОБКА ДАНИХ ТА ОБЧИСЛЕННЯ У ЗАПИТАХ.....................44
7.1. Фрази GROUP BY та HAVING...........................................................44
7.2. Фраза ODER BY...................................................................................44
7.3. Використання агрегатних функцій.....................................................45
7.4. Функції обробки значень.....................................................................48
7.5. Умовні переходи з оператором CASE................................................50
Контрольні питання до лекції 7.......................................................................51
Лекція 8. ВИКОРИСТАННЯ ПІДЗАПИТІВ.....................................................52
Прості підзапити...................................................................................53
Використання кванторів загальності та існування у підзапитах.....53
Використання агрегатних функцій у підзапитах...............................53
Зв’язані (корельовані) підзапити.........................................................55
Контрольні питання до лекції 8.......................................................................57
Лекція 9. Використання ТЕОРЕТИКО-МНОЖИННИХ
ОПЕРАЦІЙ В SQL...............................................................................58
Об’єднання наборів записів.................................................................58
Перетин наборів записів......................................................................59
Віднімання наборів записів.................................................................60
Контрольні питання до лекції 9.......................................................................61
Лекція 10. ОПЕРАЦІЇ З’ЄДНАННЯ ТАБЛИЦЬ..................................................61
Внутрішнє з’єднання (INNER JOIN)................................................62
З’єднання таблиці з собою...................................................................63
Перехресне з’єднання (CROSS JOIN)...............................................64
Зовнішні з’єднання...............................................................................65
Повне з’єднання (FULL JOIN)...........................................................66
Об’єднане з’єднання (UNION JOIN)..................................................66
Контрольні питання до лекції 10.....................................................................67
Лекція 11. ЗАСОБИ МАНІПУЛЮВАННЯ ДАНИМИ. ОПЕРАЦІЇ
НАД СХЕМОЮ БАЗИ ДАНИХ..........................................................68
Команди модифікації даних................................................................68
Створення та модифікація таблиць.....................................................70
Обмеження на значення даних............................................................71
Обмеження первинних ключів............................................................73
Встановлення значень за замовчуванням...........................................73
Модифікація структури таблиці..........................................................73
Видалення таблиці................................................................................74
Контрольні питання до лекції 11.....................................................................74
Лекція 12. ВІРТУАЛЬНІ ТАБЛИЦІ ТА ІНДЕКСИ.............................................75
12.1. Використання віртуальних таблиць.......................................................75
12.2. Використання індексів............................................................................77
Контрольні питання до лекції 12.....................................................................79
Лекція 13. ТРАНЗАКЦІЇ. ТРИГЕРИ.....................................................................80
Поняття транзакції................................................................................80
Початок і завершення транзакції........................................................80
Параметри транзакції...........................................................................81
Рівні ізоляції транзакцій.......................................................................82
Субтранзакції........................................................................................83
Тригери..................................................................................................84
Контрольні питання до лекції 13.....................................................................85
Лекція 14. КУРСОРИ ТА ВИКОРИСТАННЯ SQL У
ПРИКЛАДНИХ ПРОГРАМАХ...........................................................86
Оголошення курсору............................................................................86
Відкриття та закриття курсору............................................................88
Робота з окремими записами...............................................................89
SQL у прикладних програмах..............................................................91
Розширення SQL...................................................................................92
Контрольні питання до лекції 14.....................................................................92
Лекція 15. КЕРУВАННЯ ПРАВАМИ ДОСТУПУ В SQL..................................92
15.1. Створення користувачів.......................................................................93
15.2. Надання повноважень..........................................................................94
15.3. Відміна повноважень...........................................................................95
Контрольні питання до лекції 15.....................................................................96
СПИСОК ВИКОРИСТАНОЇ ТА РЕКОМЕНДОВАНОЇ ЛІТЕРАТУРИ.............96
ДОДАТОК 1. База даних "Операції купівлі-продажу"........................................97
ДОДАТОК 2. Схема бази даних "Операції купівлі-продажу"............................98
ВСТУП
На сьогоднішній день бази даних є невід’ємною частиною більшості інформаційних систем. В даній області стрімко розвиваються нові технології, платформи реалізації і середовища розробки прикладних програм баз даних.
Тим не менше залишається класична частина і загальноприйняті підходи до процесу організації, проектування, розробки та ведення баз даних.
У конспекті лекцій коротко викладено основи сучасної теорії баз даних. Докладно розглянуто реляційну модель даних, яка являється основою практично усіх комерційних систем управління базами даних і найбільш поширена на даний час. Велику увагу приділено мові SQL, оскільки SQL являється стандартною базовою мовою при роботі з базами даних. У конспекті лекцій на практичних прикладах описано основні конструкції мови ANSI SQL, а також різні типи запитів без прив’язки до конкретної СУБД. Зокрема розглянуто операції над наборами записів, використання підзапитів, з’єднання таблиць, модифікація даних, транзакції, курсори та керування правами доступу. Для достатньо повного вивчення даного матеріалу автор скеровує студентів до рекомендованої літератури.
Конспект лекцій містить теоретичні відомості з 15 лекцій, контрольні запитання та типові практичні задачі для самоперевірки до кожної лекції. Поданий автором теоретичний матеріал пропонується згідно навчальних планів викладати протягом 30 академічних годин для студентів базового напрямку "Комп’ютерні науки" або "Програмна інженерія" і відповідних аналогічних напрямків та спеціальностей.
Лекція 1
РОЛЬ І МІСЦЕ БАЗ ДАНИХ В ІНФОРМАЦІЙНИХ СИСТЕМАХ.
ТИПОВА ОРГАНІЗАЦІЯ СУБД
Необхідною умовою успішного функціювання різних організацій та підприємств є наявність розвинутої інформаційної системи, яка реалізовує автоматизований збір та обробку даних. В широкому значенні інформаційна система є програмним комплексом, функції якого полягають в підтримці надійного зберігання інформації в пам'яті комп’ютера, виконанні певних перетворень інформації або обчислень, наданні користувачам зручного інтерфейсу. Об’єми інформації, з якими доводиться мати справу таким системам, достатньо великі, а сама інформація має складну структуру. Класичними прикладами інформаційних систем є банківські системи, системи резервування авіаційних або залізничних квитків, місць в готелях і т.д.
1.1. Файлові системи
Попередницями баз даних були файлові системи. Вони були першою спробою комп’ютеризувати ручні картотеки.
З погляду прикладної програми файл – це іменована область зовнішньої пам'яті, в яку можна записувати і з якої можна читати дані. Правила іменування файлів, спосіб доступу до даних, що зберігаються у файлі, і структура цих даних залежать від конкретної системи управління файлами і, можливо, від типу файлу. Система управління файлами бере на себе розподіл зовнішньої пам'яті, відображення імен файлів на відповідні адреси в зовнішній пам'яті і забезпечення доступу до даних.
Розглянемо можливі області використання файлових систем. Перш за все, звичайно, файли застосовуються для зберігання текстових даних: документів, текстів програм і т.д. Такі файли звичайно утворюються і модифікуються за допомогою різних текстових редакторів.
Файли з текстами програм використовуються як вхідні тексти компіляторів, які у свою чергу формують файли, що містять об'єктні модулі. З погляду файлової системи, об'єктні файли також володіють дуже простою структурою – послідовність записів або байтів. Система програмування накладає на цю структуру складнішу і специфічну для цієї системи структуру об'єктного модуля. Зауважимо, що логічна структура об'єктного модуля невідома файловій системі, ця структура підтримується програмами системи програмування.
Аналогічно йде справа з файлами, сформованими редакторами зв'язків. Логічна структура таких файлів залишається відомою тільки редактору зв'язків і програмі операційної системи.
Приблизно така ж ситуація з файлами, що містять графічну і звукову інформацію.
Одним словом, файлові системи звичайно забезпечують зберігання слабо структурованої інформації, залишаючи подальшу структуризацію прикладним програмам. В перерахованих вище випадках використовування файлів це навіть добре, тому що при розробці будь-якої нової прикладної системи спираючись на прості, стандартні і порівняно дешеві засоби файлової системи можна реалізувати ті структури зберігання, які найбільш природно відповідають специфіці даної прикладної області.
Одним словом, файлові системи звичайно забезпечують зберігання слабо структурованої інформації, залишаючи подальшу структуризацію прикладним програмам. В перерахованих вище випадках використовування файлів це навіть добре, тому що при розробці будь-якої нової прикладної системи спираючись на прості, стандартні і порівняно дешеві засоби файлової системи можна реалізувати ті структури зберігання, які найбільш природно відповідають специфіці даної прикладної області.
Проте зовсім інша ситуація для інформаційних систем. Ці системи головним чином орієнтовані на зберігання, вибір і модифікацію постійно існуючої інформації. Структура інформації часом дуже складна, і хоча структури даних різні в різних інформаційних системах, між ними часто буває багато спільного.
На початковому етапі використання обчислювальної техніки для керування інформацією проблеми структуризації даних розв'язувалися індивідуально для кожної інформаційної системи. Проводилися необхідні надбудови над файловими системами (бібліотеки програм), подібно тому, як це робиться в компіляторах, редакторах і т.д. Але оскільки інформаційні системи вимагають складних структур даних, ці додаткові засоби керування даними були істотною частиною інформаційних систем і практично повторювалися від однієї системи до іншої.
Звідси можна перечислити обмеження, які притаманні файловим системам:
розділення та ізоляція даних – дані ізольовані в окремих файлах і доступ до них утруднений;
дублювання даних – цього не можна уникнути у файловій системі;
залежність від даних – фізична структура і спосіб збереження даних жорстко зафіксовані в коді програми, а отже, змінити існуючу структуру даних достатньо складно;
несумісність форматів файлів – оскільки структура файлу визначається кодом програми, вона також залежить від мови програмування.
Перераховані обмеження файлових систем є наслідком двох факторів:
визначення даних міститься всередині прикладних програм, а не зберігається окремо і незалежно від них;
крім прикладних програм не передбачається ніяких інших засобів доступу до даних і їх обробка.
Для підвищення ефективності роботи необхідно було використовувати новий підхід.
1.2. Системи з базами даних
Сучасною формою інформаційних систем є банки даних. Банк даних – це система певним чином організованих даних – баз даних, – програмних, технічних, мовних, організаційно методичних засобів, які призначені для забезпечення централізованого накопичення і багатокористувацького використання даних. Банки даних мають наступні складові:
обчислювальну систему;
систему управління базами даних (СУБД);
одну або декілька баз даних;
набір прикладних програм баз даних.
База даних – це сукупність логічно зв’язаних даних (і опис цих даних), яка відображає стан об’єктів та їх зв’язків в певній предметній області. База даних – це єдине велике сховище даних, яке один раз визначається, а потім використовується одночасно багатьма користувачами.
В підході з використанням баз даних, структура даних відділена від прикладних програм і зберігається в базі даних. Додавання нових структур даних або зміна існуючих ніяк не вплине на програми, при умові, що вони не залежать безпосередньо від компонент, які змінюються.
Інформація в базі даних повинна бути несуперечливою, ненадлишковою, цілісною. Ключовим поняттям баз даних є поняття узгодженості даних. Вимога підтримки узгодженості даних в декількох файлах не дозволяє обійтися лише бібліотекою функцій: така система повинна мати деякі власні дані (метадані) і навіть знання, що визначають цілісність даних.
Система управління базами даних – СУБД – це сукупність мовних та програмних засобів, які призначені для створення, підтримки та сумісного використання баз даних багатьма користувачами.
Програми, за допомогою яких користувачі працюють з базою даних, називаються прикладними програмами баз даних. Як правило, з однією базою даних може працювати декілька прикладних програм. Вони можуть працювати паралельно і незалежно одна від одної. І саме СУБД повинна забезпечити їх роботу так, щоб кожна прикладна програма виконувалась коректно, але й враховувала усі зміни, які вносяться у базу даних різними прикладними програмами.
1.3. Розподіл обов’язків в системах з базами даних
Серед користувачів СУБД можна виділити чотири групи.
Адміністратори даних та адміністратори баз даних.
Адміністратор даних, або АД (Data Administrator – DA), відповідає за управління даними, включаючи планування бази даних, розробку та ведення стандартів, бізнес-правил та ділових процедур. А також за концептуальне та логічне проектування бази даних. АД консультує і дає свої рекомендації керівництву вищої ланки.
Адміністратор бази даних, або АБД (Database Administrator – DBA), відповідає за фізичну реалізацію бази даних, включаючи фізичне проектування та втілення проекту, за безпеку та цілісність даних, за супровід операційної системи, а також за забезпечення максимальної продуктивності програм та користувачів.
В порівнянні з АД, обов’язки АБД мають більш технічний характер. Він повинен знати конкретну СУБД і системне оточення.
Розробники баз даних. В проектуванні великих баз даних беруть участь розробники логічної бази даних та розробники фізичної бази даних.
Розробник логічної бази даних займається ідентифікацією даних (тобто сутностями та атрибутами), зв’язками між даними і встановлює обмеження на дані, що зберігаються. Робота розробника логічної бази даних ділиться на два етапи:
концептуальне проектування бази даних, яке не залежить від таких деталей її втілення, як конкретна СУБД, програми, мови програмування;
логічне проектування бази даних, яке проводиться з врахуванням вибраної моделі даних: реляційної, мережевої, ієрархічної або об’єктно-орієнтовної.
Розробник фізичної бази даних отримує готову логічну модель даних і займається фізичною реалізацією, в тому числі:
перетворенням логічної моделі даних в набір таблиць та обмежень цілісності даних;
вибором конкретних структур збереження та методів доступу до даних;
проектуванням будь-яких необхідних мір захисту даних.
Якщо концептуальне і логічне проектування бази даних відповідає на питання „що?”, то фізичне проектування відповідає на питання „як?”.
Прикладні програмісти.
Відразу після створення бази даних приступають до створення програм, які надають користувачам необхідні їм функціональні можливості. Таку роботу виконують прикладні програмісти. Переважно прикладні програмісти працюють на основі специфікацій, створених системними аналітиками.
Користувачі-клієнти.
База даних проектується, створюється та ведеться для того, щоб обслуговувати інформаційні потреби користувачів-клієнтів. Їх можна класифікувати за способом користування системою.
Наївні користувачі переважно і не підозрюють про існування СУБД. Вони звертаються до бази даних за допомогою спеціальних програм, які дозволяють спростити їхні операції. Такі користувачі ініціюють виконання операцій бази даних, вводячи найпростіші команди або вибираючи команди меню. Таким користувачам не потрібно знати про базу даних або СУБД.
Досвідчені користувачі знаходяться з іншої сторони спектра. Вони знайомі зі структурою бази даних і можливостями СУБД. Для виконання необхідних операцій вони можуть використовувати таку мову запитів високого рівня, як SQL. А деякі досвідчені користувачі можуть навіть створювати власні прикладні програми.
1.4. Функції СУБД
Розглянемо типи функцій, які повинна забезпечувати типова СУБД.
Збереження, вибір та оновлення даних. Це фундаментальна функція СУБД.
Каталог, доступний кінцевим користувачам.
Підтримка транзакцій. Транзакція – це набір дій, які виконуються певним користувачем або прикладною програмою з метою доступу або зміни вмістимого бази даних.
Сервіс керування паралельністю, який гарантує коректне оновлення бази даних при паралельному виконанні операцій оновлення декількома користувачами..
Сервіс відновлення бази даних на випадок якого-небудь пошкодження.
Сервіс контролю за доступом до даних, який гарантує доступ до бази лише санкціонованих користувачів.
Підтримка обміну даними. СУБД повинна інтегруватись з різними існуючими менеджерами обміну даними.
Служба підтримки цілісності даних, яка контролює за тим, щоб дані та їх зміни відповідали заданим правилам. Цілісність бази даних означає коректність і несуперечливість даних.
Служба підтримки незалежності програм від даних.
Додаткові служби, утиліти, які допомагають АБД в адмініструванні бази даних:
утиліти імпортування та утиліти експортування бази даних;
засоби моніторингу, які слідкують за функціонуванням та використанням бази даних;
програми статистичного аналізу, які дозволяють оцінити продуктивність системи;
інструменти збору сміття та перерозподілу пам’яті.
Контрольні питання до лекції 1
Що таке „інформаційна система”.
Що таке файлові системи.
Перечисліть обмеження, притаманні файловим системам.
Що таке банк даних.
Що таке база даних.
Що таке СУБД ?
Назвіть різні групи користувачів СУБД.
Які обов’язки в адміністратора даних та адміністратора бази даних ?
В чому полягає робота розробника баз даних ?
Яку роботу виконують прикладні програмісти ?
Як можна класифікувати користувачів-клієнтів ?
Які основні функції повинна виконувати СУБД ?
Лекція 2
АРХІТЕКТУРА ОРГАНІЗАЦІЇ БАЗИ ДАНИХ. МОВИ БАЗ ДАНИХ
2.1. Трирівнева архітектура організації бази даних
Говорячи про термін "архітектура БД", мається на увазі архітектуру інформаційного забезпечення.
Архітектура БД уперше була специфікована дослідницькою групою ANSI/ X3/ SPARC Study Group on Data Base Management Systems (ANSI – American National Standard Institute (Національний Інститут Стандартизації США), X3 – його комітет обчислювальної техніки й обробки інформації, SPARC – Standards Planning and Requirements Committee (Комітет планування стандартів і норм)). Дослідницькою групою було докладено чимало зусиль для визначення загальної архітектури системи баз даних. Запропонована цією групою архітектура стала класичною та є актуальною донині.
Основною ідеєю специфікації ANSI-SPARC є виділення трьох архітектурних рівнів бази даних, а саме: зовнішнього, концептуального та внутрішнього, як показано на рис.1.
Мета трирівневої архітектури полягає у відокремленні користувацького представлення бази даних від її фізичного представлення.
Рис. 1. Трирівнева архітектура ANSI-SPARC.
Рівень, на якому користувачі сприймають дані, називається зовнішнім рівнем (external level). Даний рівень описує ту частину бази даних, яка відноситься до кожного користувача. Зовнішній рівень складається з декількох різних зовнішніх представлень бази даних. Зовнішнє представлення містить
тільки ті сутності, атрибути та зв’язки „реального світу”, які представляють певний інтерес користувачу. Інші сутності, атрибути та зв’язки, які йому не потрібні, теж можуть бути представлені в базі даних, але користувач може і не підозрювати про їх існування. Крім того, різні представлення можуть по-різному відображати одні і ті ж дані.
Проміжним рівнем в архітектурі ANSI-SPARC є концептуальний рівень (conceptual level). Даний рівень містить логічну структуру всієї бази даних. На концептуальному рівні представляються наступні компоненти:
усі сутності, їх атрибути і зв’язки;
обмеження, які накладаються на дані;
семантична інформація про дані;
інформація про міри безпеки та підтримки цілісності даних.
Концептуальний рівень підтримує кожне зовнішнє представлення. Даний рівень об’єднує дані, які використовуються усіма прикладними програмами, що працюють з базою даних. Однак концептуальний рівень не містить ніякий відомостей про методи збереження даних.
Внутрішній рівень (internal level) описує фізичну реалізацію бази даних. Його ще називають фізичним рівнем – це саме дані, структурно розміщені на зовнішніх носіях інформації. На внутрішньому рівні міститься наступна інформація:
розподіл дискового простору для збереження даних та індексів;
відомості про розміщення записів;
відомості про стиснення даних та методи їх шифрування.
2.2. Схема бази даних
Важливо відрізняти опис бази даних і саму базу даних. Описом бази даних являється схема бази даних. Схема створюється в процесі проектування бази даних, причому передбачається, що вона змінюється досить рідко. Однак інформація, що міститься в базі даних, може змінюватись часто.
Існує три типи схем бази даних, які визначаються відповідно з рівнями трирівневої архітектури. На найвищому рівні є декілька зовнішніх схем або підсхем, які відповідають різним представленням даних. На концептуальному рівні опис бази даних називають концептуальною схемою. Вона описує всі елементи даних та зв’язки між ними. Для кожної бази даних існує тільки одна концептуальна схема. На найнижчому рівні знаходиться внутрішня схема. Вона містить визначення записів, методи опису полів даних, відомості про індекси. Для кожної бази даних існує тільки одна внутрішня схема.
Сукупність інформації, що зберігається в базі даних в будь-який певний момент часу, називається станом бази даних. Таким чином, одній і тій же схемі бази даних може відповідати кілька її різних станів. Схема бази даних деколи називається змістом бази даних, а її стан – деталізацією.
2.3. Незалежність від даних
Основним призначенням трирівневої архітектури є забезпечення незалежності від даних. Це означає, що зміни на нижніх рівнях ніяк не вплинуть на верхні рівні. Розрізняють два типи незалежності від даних: логічну і фізичну.
Логічна незалежність від даних означає повну захищеність зовнішніх схем від змін, що вносяться в концептуальну схему. Такі зміни концептуальної схеми, як додавання або видалення нових сутностей, атрибутів або зв’язків, повинні здійснюватись без внесення змін в існуючі зовнішні схеми або переписуванні прикладних програм. Очевидно, що користувачі, для яких ці зміни призначались, повинні знати про них. Але важливо, щоб інші користувачі не підозрювали про це.
Фізична незалежність від даних означає захищеність концептуальної схеми від змін, що вносяться у внутрішню схему. Такі зміни внутрішньої схема, як використання різних файлових систем або структур зберігання, різних пристроїв зберігання, модифікація індексів, повинні здійснюватись без необхідності внесення змін в концептуальну або зовнішню схеми. Користувач може помітити зміни лише в загальній продуктивності системи.
Архітектура ANSI-SPARC не підтримується у повному обсязі жодною з сучасних СУБД, особливо, якщо це стосується концептуального рівня. У більшості наявних систем концептуальна схема насправді є простим об’єднанням усіх окремих зовнішніх схем, доповненим засобами гарантування безпеки даних і правилами забезпечення цілісності. Зовнішні схеми підтримуються за допомогою так званих віртуальних таблиць. Щодо внутрішнього рівня, то він, як правило, підтримується різноманітними механізмами опису структур зберігання даних і методів доступу до них.
Мови баз даних
Внутрішня мова СУБД для роботи з даними складається з двох частин: мови визначення даних (DDL – Data Definition Language) і мови управління даними (DML – Data Manipulation Language). Мова DDL використовується для визначення схеми бази даних, а мова DML – для читання і оновлення даних, які зберігаються в базі.
Мова визначення даних – DDL .
Мова DDL – це описова мова, яка дозволяє АБД або користувачу описати і поіменувати сутності, необхідні для роботи деякої прикладної програми, а також зв’язки, наявні між різними сутностями. Мова DDL використовується як для визначення нової схеми, так і для модифікації вже існуючої. Дану мову неможна використовувати для управління даними.
Результатом компіляції DDL-операторів є набір таблиць, що зберігається в особливих файлах, які називаються системним каталогом. В системному каталозі інтегровано метадані – тобто дані, які описують об’єкти бази даних, а також дозволяють спростити спосіб доступу до них та їх управління. Метадані включають визначення записів, елементів даних, а також інші об’єкти, які представляють інтерес для користувачів або необхідні для роботи СУБД. Перед доступом до реальних даних СУБД звертається до системного каталогу.
Мови управління даними DML.
Мова DML – це мова, яка містить набір операторів для підтримки основних операцій маніпулювання даними, що зберігаються в базі.
До операцій управління даними відносяться:
вставка в базу даних нових відомостей;
модифікація відомостей, що зберігаються в базі даних;
вибір відомостей, що зберігаються в базі даних;
видалення відомостей з бази даних.
Мови DML відрізняються базовими конструкціями витягання даних. Розрізняють два типи мов DML: процедурна та непроцедурна. Основні відмінності між ними полягає в тому, що процедурні мови вказують на те, як можна отримати результат оператора мови DML. Тоді як непроцедурні мови описують те, який результат буде отримано. Як правило, в процедурних мовах кожен запис розглядається окремо, а непроцедурні мови оперують цілими наборами записів.
Процедурна мова DML – це мова яка дозволяє повідомити системі про те, які дані потрібні, і точно вказати, як їх можна витягнути. За допомогою процедурної мови DML користувач, а точніше – програміст, вказує на те, які дані йому потрібні і як їх можна отримати. Переважно така процедурна мова DML дозволяє витягнути запис, обробити його і, в залежності від отриманих результатів, витягнути наступний запис, який буде аналогічно оброблятись. Подібний процес вилучення (витягання) даних продовжується до тих пір, поки не будуть витягнені всі потрібні дані. Мови DML мережевих та ієрархічних СУБД переважно є процедурними.
Непроцедурна мова DML – мова, яка дозволяє вказати лише те, які дані потрібні, а не те, як їх треба вилучати. Непроцедурні мови DML дозволяють визначити весь набір потрібних даних з допомогою одного оператора вилучення або оновлення. Користувач вказує, які дані йому потрібні без визначення способу їх отримання. СУБД транслює вираз на мові DML в процедуру (або набір процедур), яка забезпечує маніпулювання набором записів. Даний підхід звільняє користувача від необхідності знати деталі внутрішньої реалізації структур даних та особливості алгоритмів. Непроцедурні мови часто також називають декларативними мовами.
Реляційні СУБД переважно включають підтримку непроцедурних мов управління даними – найчастіше це мова структурованих запитів SQL (Structured Query Language) або мова запитів за примірником QBE (Query-by-Example). Непроцедурні мови простіше зрозуміти і використовувати, ніж процедурні мови DML, оскільки користувачем виконується менша частина роботи, а СУБД – більша.
Контрольні питання до лекції 2
Що таке трирівнева архітектура ANSI-SPARC ? Яке її основне призначення ? Поясніть абревіатуру ANSI/ X3/ SPARC.
Опишіть зовнішній рівень трирівневої архітектури бази даних.
Опишіть концептуальний рівень трирівневої архітектури бази даних.
Опишіть внутрішній рівень трирівневої архітектури бази даних.
Що таке схема бази даних ?
Опишіть три типи схем бази даних.
Що означає логічна незалежність від даних ?
Що означає фізична незалежність від даних ?
Як підтримується архітектура ANSI-SPARC сучасними СУБД ?
Якими засобами СУБД дозволяє визначати базу даних ?
Якими засобами СУБД дозволяє маніпулювати даними ?
Що таке DDL ?
Що таке DML ?
Які особливості процедурних мов DML ?
Які особливості непроцедурних мов DML ?
Основні відмінності процедурних та непроцедурних мов DML.
Лекція 3
МОДЕЛІ ДАНИХ. РЕЛЯЦІЙНА МОДЕЛЬ ДАНИХ
Одними з основних в концепції баз даних є узагальнені поняття „дані” та „модель даних”. Поняття „дані” в концепції баз даних – це набір конкретних значень, параметрів, які характеризують об’єкт, умову, ситуацію або інші фактори.
Модель даних – це представлення „реальних” об’єктів, подій та існуючих між ними зв’язків. Це деяка абстракція, яка застосовується до певних даних, і в якій акцент робиться на найважливіших аспектах, а всі другорядні властивості ігноруються.
Таким чином, модель даних – інтегрований набір понять для опису даних, зв’язків між ними та обмежень, які накладаються на дані, в деякій інформаційній системі.
Відповідно до архітектури ANSI-SPARC можна ідентифікувати наступні три зв’язані моделі даних:
зовнішню модель даних, яка відображає представлення користувачів кожного типу; її деколи називають предметною областю;
концептуальну модель даних, яка відображає логічне (або узагальнене) представлення даних, що не залежить від типу вибраної СУБД;
внутрішню модель даних, яка відображає концептуальну схему певним способом, стосовно вибраної СУБД.
Моделі даних ділять на три категорії: об’єктні (object-based) моделі даних, моделі даних на основі записів (record-based) і фізичні моделі даних. Перші дві використовуються для опису даних на концептуальному та зовнішньому рівнях, а остання – на внутрішньому рівні. Розглянемо кожну з них.
3.1. Об’єктні моделі даних
При побудові об’єктних моделей даних використовуються такі поняття як сутності, атрибути і зв’язки. Перечислимо загальні типи об’єктних моделей даних:
модель типу „сутність-зв’язок”, або ER–модель (Entity-Relationship model);
семантична модель;
функціональна модель;
об’єктно-орієнтована модель.
На даний час ER–модель стала одним з основних методів концептуального проектування баз даних.
В об’єктно-орієнтованій моделі окремі записи бази даних представляються у вигляді об’єктів. Дана модель розширяє визначення сутності з метою включення в нього не тільки атрибутів, які описують стан об’єкта, а й дій, які з ним пов’язані, тобто його поведінку. В такому випадку говорять, що об’єкт інкапсулює стан та поведінку.
3.2. Моделі даних на основі записів
В моделі на основі записів база даних складається з декількох записів фіксованого формату, які можуть мати різні типи. Кожен тип запису визначає фіксовану кількість полів, кожне з яких має фіксовану довжину.
Існує три основних типи логічних моделей даних на основі записів: ієрархічна модель даних (hierarchical data model), мережева модель даних (network data model) та реляційна модель даних (relational data model).
В ієрархічній моделі дані представляються у вигляді деревовидної (ієрархічної) структури. Така структура даних визначається ієрархічною впорядкованістю своїх компонент (або вузлів), тобто кожен вузол має не більше одного "батька" – старшого за ієрархією вузла. Подібна організація даних є зручною для роботи з ієрархічно впорядкованою інформацією. Однак, не всі предметні області мають чітко виражену ієрархічну структуру, і при оперуванні складними логічними зв’язками ієрархічна модель стає дуже громіздкою.
Мережева модель даних є розширенням ієрархічної моделі і призначена для адекватного моделювання зв’язків між сутностями типу "багато-до-багатьох". Тут дані організовуються у вигляді довільного графа. На відміну від ієрархічної моделі, зв’язки тут моделюються наборами, які реалізуються за допомогою вказівників. Недоліком мережевої моделі є жорсткість структури і складність її організації, в порівнянні з ієрархічною моделлю.
Уникнути складності ієрархічної та мережевої моделей вдалося в реляційній моделі даних, що у певному розумінні була поверненням до файлових систем. Єдина вимога в реляційній моделі даних – це щоб база даних з точки зору користувача виглядала як набір таблиць, зв’язаних між собою. Однак це відноситься тільки до логічної структури бази даних, тобто до зовнішнього та концептуального рівня архітектури ANSI-SPARC. Дана вимога не відноситься до фізичної структури бази даних, яка може бути реалізована за допомогою різних структур зберігання. Порівняно з ієрархічною та мережевою структурами рівень мови маніпулювання структурою, яка може бути проінтерпретована як звичайна таблиця, значно вищий. Це дало змогу більш глибоко і всебічно вирішити багато проблем, пов’язаних з базами даних, а саме: вибірка даних, їх незалежність, цілісність та захист.
3.3. Фізичні моделі даних
Фізична модель даних оперує категоріями, які відносяться до організації зовнішньої пам’яті та структур зберігання даних. На даний час в якості фізичних моделей даних використовуються різні методи розміщення даних, що базуються на файлових структурах: це організація файлів прямого та послідовного доступу, індексних файлів, інвертованих файлів, файлів, які використовують різні методи хешування, взаємозв’язаних файлів. Крім того, сучасні СУБД використовують сторінкову організацію даних. Фізичні моделі, що базуються на сторінковій організації є найбільш перспективними.
3.4. Основні поняття реляційної моделі даних.
Вперше реляційна модель була запропонована Е. Коддом в 1970 році. Комерційні системи на основі реляційної моделі даних почали з’являтись наприкінці 70-х – початку 80-х років минулого сторіччя. Перевагами реляційної моделі даних є простота, гнучкість структури, зручність реалізації на комп’ютері, на...
07.04.2012 12:04-
Ділись своїми роботами та отримуй миттєві бонуси!
0%
Оголошення від адміністратора