- •Історія розвитку сбд.
- •Традиційні файлові системи. Переваги і недоліки.
- •Системи з використанням баз даних. Компоненти сбд. Переваги і недоліки.
- •5_ Системи керування базами даних. Компоненти. Функції.
- •Компоненты сбд
- •1. Зберігання, вилучення і обновлення даних
- •2. Каталог, який доступний кінцевим користувачам
- •3. Управління транзакціями
- •Розподіл обов’язків в сбд. Ад і абд.
- •7_ Архітектура сбд ansi/sparc. Три рівні. Відображення. Трехуровневая архитектура ansi-sparc
- •6_ Поняття бд. Об’єкти і зв’язки. Властивості.
- •3.5 Концептуальный уровень
- •3.6 Внутренний уровень
- •3.7 Отображения
- •3.8 Доступ к данным в трехуровневой архитектуре
- •12_ Архітектура сбд ansi/sparc. Мови баз даних. Ddl. Dml. 4gl.
- •Языки баз данных.
- •Процедурний
- •Непроцедурний
- •13_ Архітектура клієнт-сервер. Розподілена обробка. Архитектура многопользовательских субд
- •Субд в архитектуре "клиент-сервер" Лекция 19. Архитектура "клиент-сервер"
- •19.1. Открытые системы
- •19.2. Клиенты и серверы локальных сетей
- •19.3. Системная архитектура "клиент-сервер"
- •19.4. Серверы баз данных
- •19.4.1. Принципы взаимодействия между клиентскими и серверными частями
- •19.4.2. Преимущества протоколов удаленного вызова процедур
- •19.4.3. Типичное разделение функций между клиентами и серверами
- •19.4.4. Требования к аппаратным возможностям и базовому программному обеспечению клиентов и серверов
- •14_ Ранні підходи в реалізації бд. Бд на інвертованих списках. Ієрархічні та мереживі бд. Модель инвертированных списков
- •Реляційна бд. Властивості реляційних бд.
- •Реляційна модель. Домени. Оператори.
- •2. Реляционная модель данных
- •2.1. Понятие модели данных
- •Реляційна модель. Відношення. Типи відношень.
- •Реляційна модель. Класифікація обмежень цілісності.
- •Реляційна модель. Потенційні ключі.
- •Реляційне числення. Числення доменів. (самостійно)
- •5.2.3. Реляционное исчисление доменов
- •Мова sql. Запит на оновлення. Використання співвіднесених запитів в запитах на оновлення.
- •Мова sql. Запит на знищення. Використання підзапитів в запитах на знищення.
- •Мова sql. Запит на додавання. Додавання результатів запиту.
- •Мова sql. Об’єднання таблиць. Використання пропозиції union.
- •Мова sql. Використання пропозицій any, all, some.
- •Мова sql. Використання пропозиції exists.
- •Мова sql. Співвіднесений запит на вибірку.
- •Мова sql. Запит на вибірку із підзапитом.
- •Мова sql. Запит на вибірку до кількох таблиць. З’єднання таблиць. Типи з’єднань.
- •Мова sql. Запит на вибірку. Агрегатні функції
- •Історія розвитку
1. Зберігання, вилучення і обновлення даних
Фундаментальна функція СУБД. Спосіб реалізації цієї ф-ції в СУБД повинен дозволяти скрывать від кінцевого користувача внутрішні деталі фізичної реалізації системи.
2. Каталог, який доступний кінцевим користувачам
Системний каталог, з даними о схемах, користувачах і додатках, доступний як користувачам так и функціям СУБД. Він єхранилищем інформації, яка описує дані в БД. В основному в каталозі зберігаються наступні свідения:
- імена, типи і розміри елементів даних;
- імена зв'язків;
- обмеження, які накладаються на дані, для підтримки цілісності;
- імена санкцеонированных користувачів, яким предоставлено право доступу до даних;
- зовнішня, концептуальна і внутрішня схеми і відображення між ними;
- статичні дані.
3. Управління транзакціями
Транзакція - це послідовність операцій над БД, даних СУБД як єдине ціле. Або транзакція успішно виконується, і СУБД фіксує (COMMIT) зміни БД, проведені цією транзакцією, в зовнішній пам'яті, або жодна з цих змін ніяк не відображається на стані БД. Поняття транзакції необхідне для підтримки логічної цілісності БД. Якщо пригадати наш приклад інформаційної системи з файлами СПІВРОБІТНИКИ і ВІДДІЛИ, то єдиним способом не порушити цілісність БД при виконанні операції прийому на роботу нового співробітника є об'єднання елементарних операцій над файлами СПІВРОБІТНИКИ і ВІДДІЛИ в одну транзакцію. Таким чином, підтримка механізму транзакцій є обов'язковою умовою навіть розрахованих на одного користувача СУБД (якщо, звичайно, така система заслуговує назви СУБД). Але поняття транзакції набагато більш важливе в розрахованих на багато користувачів СУБД.
Та властивість, що кожна транзакція починається при цілісному стані БД і залишає цей стан цілісним після свого завершення, робить дуже зручним використовування поняття транзакції як одиниці активності користувача по відношенню до БД. При відповідному управлінні транзакціями, що паралельно виконуються, з боку СУБД кожний з користувачів може у принципі відчувати себе єдиним користувачем СУБД (насправді, це уявлення, що дещо ідеалізується, оскільки в деяких випадках користувачі розрахованих на багато користувачів СУБД можуть відчути присутність своїх колег).
З управлінням транзакціями в розрахованій на багато користувачів СУБД зв'язані важливі поняття сериализации транзакцій і сериального плану виконання суміші транзакцій. Під сериализаций транзакцій, що паралельно виконуються, розуміється такий порядок планування їх роботи, при якому сумарний ефект суміші транзакцій еквівалентний ефекту їх деякого послідовного виконання. Серіальний план виконання суміші транзакцій - це такий план, який приводить до сериализации транзакцій. Зрозуміло, що якщо вдається добитися дійсно сериального виконання суміші транзакцій, то для кожного користувача, за ініціативою якого утворена транзакція, присутність інших транзакцій буде непомітна (якщо не рахувати деякого уповільнення роботи в порівнянні з розрахованим на одного користувача режимом).
Існує декілька базових алгоритмів сериализации транзакцій. В централізованих СУБД найбільш поширені алгоритми, засновані на захопленнях синхронізацій об'єктів БД. При використовуванні будь-якого алгоритму сериализации можливі ситуації конфліктів між двома або більш транзакціями по доступу до об'єктів БД. В цьому випадку для підтримки сериализации необхідно виконати відкіт (ліквідовувати всі зміни, вироблені в БД) однієї або більш транзакцій. Це один з випадків, коли користувач розрахованої на багато користувачів СУБД може реально (і достатньо неприємно) відчути присутність в системі транзакцій інших користувачів.
Сервисы керування паралельністю
Паралельний доступ можна легко забезпечити, якщо всі користувачі виконують тільки читання. СУБД повинна гарантувати, що при одночасному доступі до БД багатьох користувачів конфліктів не виникає.
Сервіси востановленния
СУБД повинна надавати засоби востановленния БД на випадок якого небудь її повреждения або разрушения.
Сервисы контролю доступу до даних
СУБД повинна мати механізм, який гарантує можливість доступу до БД тільки санкционированных користувачів.
Підтримка обміну даними
СУБД повинна володіти способностью до інтеграції з комунікаційним ПЗ.
Службы підтримки цілісності даних
СУБД повинна володіти інструментами контролю за тим, щоб дані і їхні зміни відповідали заданими правилами.
Службы підтримки незалежності від даних
СУБД повинна володіти інструментами підтримки незалежності програм від фактичної структури БД.
Допоміжні Службы
СУБД повинна надавати деякий набір допоміжних служб. Допоміжні утиліти призначені для надавання допомоги АБД в ефективному адмініструванні БД. Одні утиліти працюють на зовнішню му рівні, створені самими АБД, інші на фунционирують на внутрішньому рівні системи і тому повинні приставлені самими розробниками СУБД.
Приклади допоміжних утиліт:
у-ти імпортування, для завантаження БД із плоских файлів. У-ти експортування – завантаження БД в плоскі диски.
Засоби моніторингу, для спостерігання характеристики функціонування і використання БД.
Програми статичного аналізу, дозволяють оцінити производительнность або степінь використання БД.
Інструменти реорганизации індексів, презначені для перебудови індексів і обробки випадків їх переповнення.
Інструменти сборки мусора і перерозподіл пам'яті для фізичного устранения удаленных записів з запоминаючих пристроїв.
