- •Історія розвитку сбд.
- •Традиційні файлові системи. Переваги і недоліки.
- •Системи з використанням баз даних. Компоненти сбд. Переваги і недоліки.
- •5_ Системи керування базами даних. Компоненти. Функції.
- •Компоненты сбд
- •1. Зберігання, вилучення і обновлення даних
- •2. Каталог, який доступний кінцевим користувачам
- •3. Управління транзакціями
- •6_ Поняття бд. Об’єкти і зв’язки. Властивості.
- •Розподіл обов’язків в сбд. Ад і абд.
- •7_ Архітектура сбд ansi/sparc. Три рівні. Відображення. Трехуровневая архитектура ansi-sparc
- •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. Запит на вибірку. Агрегатні функції
- •Історія розвитку
3.5 Концептуальный уровень
Здесь данные представлены такими, какие они есть на самом деле. Концептуальное представление состоит из множества экземпляров каждого типа концептуальной записи. Она вовсе не обязана совпадать с внешней или хранимой записью. Концептуальное представление задается концептуальной схемой, которая включает определения типов концептуальных записей. Для определения концептуальной схемы используется специальный ЯОД, не содержащий средств определения структур хранения и методов доступа к данным. Определения концептуального языка относятся только к содержанию информации. Если это обеспечено, то внешние схемы, определяемые на основе концептуальной схемы, заведомо не будут меняться при изменении хранимых схем.
Итак, концептуальное представление – это представление всего содержимого БД, а концептуальная схема – определение этого представления.
Однако, она содержит не только определения типов записей. В концептуальную схему включаются определения средств безопасности, правила обеспечения целостности и т.п. Более того, в нее следует включать и описания того, как используются данные на предприятии. Это обеспечит возможность реорганизации процессов управления с целью повышения эффективности предприятия. Однако, реально этого (пока) нет.
Важнейшее свойство концептуальной схемы – стабильность. Она отражает общие информационные потребности бизнеса и может измениться только в связи с радикальным изменением этих потребностей.
3.6 Внутренний уровень
Внутреннее представление состоит из множества экземпляров каждого типа внутренней (хранимой) записи. Это представление так же как и внешнее и концептуальное не связано с физическим уровнем, т.е. с блоками, цилиндрами, дорожками и т.д. Оно описывается внутренней схемой, которая определяет типы хранимых записей, способы представления хранимых полей, физическую последовательность хранения записей, существующие индексы и т.д. Внутренняя схема описывается с помощью внутреннего ЯОД, отличающегося как от ЯОД подъязыка данных внешнего представления, так и от концептуального ЯОД. Всё, что ниже этого уровня – уровень ОС.
Единица доступа к данным для СУБД – хранимая запись. СУБД получает доступ к данным через посредство ОС.
3.7 Отображения
Отображения определяют соответствия между представлениями верхнего и нижнего уровней. Отображение концептуальный « внутренний ставит в соответствие концептуальным полям и записям хранимые. Это соответствие является взаимно однозначным. При изменении структур хранения изменяется отображение концептуальный « внутренний так, чтобы концептуальная схема осталась неизменной. Аналогично отображение внешний « концептуальный ставит в соответствие концептуальным полям и записям внешние. Отображения реализуются посредством статей словаря данных системы и специальных модулей СУБД, обеспечивающих преобразования данных.
3.8 Доступ к данным в трехуровневой архитектуре
Реализация изложенной архитектурной концепции вовсе не обязательно явно включает все три уровня. Однако, в любой реализации ПП получают доступ к хранимым данным только через посредство СУБД. Для примера рассмотрим схему алгоритма выполнения операции чтения данных прикладной программой [9] (см. рис. 4.3).
|
Рис. 3.5 Доступ к данным в СБД
Шаг 1. ПП обращается к СУБД с запросом на чтение записи внешней модели.
Шаг 2. СУБД, используя схемы ВМД и КМД и описание отображения внешний – концептуальный, определяет, какие записи КМД необходимы для формирования требуемой записи ВМД.
Шаг 3. СУБД, используя схемы КМД и ВНМД и описание отображения концептуальный – внутренний, определяет, какие записи внутренней модели необходимы для формирования затребованных записей КМД и совокупность физических записей, которые должны быть для этого считаны с физического носителя.
Шаг 4. СУБД выдает ОС запрос на считывание в свои буферы необходимых записей физической базы данных (ФБД).
Шаг 5. ОС считывает затребованные записи и помещает их в системные буферы СУБД.
Шаг 6. На основании имеющихся схем моделей и описаний отображений СУБД формирует в своем буфере затребованную внешнюю запись.
Шаг 7. СУБД пересылает сформированную внешнюю запись в рабочую область (РО) ПП.
Шаг 8. СУБД передает в ПП сообщение о результатах выполнения запроса.
Процедура записи данных из ПП в ФБД выполняется аналогично.
