Производительность БД

Количество процессоров и их быстродействие, количество и быстродействие дисков, объём оперативной памяти; всё это оказывает очень существенное влияние на уровень производительности. Не малую роль в общую производительность вносит и операционная система (ОС). Очевидно, что параллельно с процессами сервера баз данных будут выполняться процессы ОС и других, одновременно функционирующих на этом сервере программ. Также, на производительность могут повлиять файлы страничного обмена, их количество и местоположение. Использование RAID технологии также может в ту или иную сторону сказаться на общей производительности. Разумеется, нельзя исключать из систем, участвующих в оценке общей производительности, и сетевую среду, быстродействие сетевых соединений которой, а также её утилизация или уровень коллизий влияют на полосу пропускания сети, а следовательно, и на скорость передачи данных и запросов между клиентом и сервером.

22. Методологія фізичного проектування БД

Физическое проектирование базы даиных представляет собой процесс подготовки описания реализации этой базы во внешней памяти. В этом проекте должны быть описаны основные отношения, файловые структуры и методы доступа, которые будут использоваться для эффективного доступа к данным, наряду с соответствующими ограничениями целостности и мерами защиты. Проектировщик должен приступать к созданию основных отношений только после полного ознакомления со всеми возможностями выбранной целевой СУБД. •

Первый этап физического проектирования базы данных состоит в преобразовании глобальной логической модели данных в форму, которая может быть реализована в среде целевой реляционной СУБД.

Следующий этап предусматривает выбор файловых структур и методов доступа, которые будут применяться для хранения основных отношений базы данных. Для этого требуется провести анализ транзакций, выполняемых в базе данных, на основе результатов этого анализа определить наиболее подходящие файловые структуры, выбрать индексы и оценить потребность в дисковом пространстве для реализации этих проектных решений. Индексно-последовательные (ISAM) файлы представляют собой более гибкую структуру, чем хешированные файлы. Они эффективны при выборке данных по заданному значению ключа, по шаблону с символами подстановки, по ключу, определенному в виде диапазона значений, или по части ключа. Однако индекс файлов ISAM является неизменным и формируется непосредственно при создании самого файла. В результате производительность выборки данных из файла ISAM уменьшается по мере внесения изменений в его данные. Обновление данных файла вызывает также нарушение правильной последовательности ключей, поэтому выборка данных с учетом последовательности значений ключа доступа со временем замедляется. Последние две проблемы решаются при использовании файлов со структурой усовершенствованного сбалансированного дерева (В+-Тгее), имеющих динамически формируемый индекс. Однако в отличие от файлов со структурой В+-Тгее, файлы ISAM благодаря неизменности своего индекса могут успешно использоваться для организации параллельного доступа к этому индексу.

23. Архітектура та принципи проектування інтерфейсу користувача для застосувань БД

При проектировании пользовательского интерфейса следует в самом начале принять решение об общей структуре интерфейса системы – об архитектуре пользовательского интерфейса. Основной принцип: выбор архитектуры интерфейса должен быть обусловлен рабочими процессами, которые поддерживает разрабатываемая система, а не структурой данных. Нужно создавать такую структуру интерфейса что-бы максимально помочь пользователю в его работе.

Пользовательский интерфейс приложений базы данных является одним из важнейших компонентов системы. Интерфейс должен быть удобным и обеспечивать все функциональные возможности, предусмотренные в спецификациях требований пользователей.
При проектировании пользовательского интерфейса рекомендуется использовать следующие основные элементы и их характеристики:
-содержательное название;
-ясные и понятные инструкции;
-логически обоснованные группировки и последовательности полей;
-визуально привлекаемый вид окна или поля отчета;
-легко узнаваемые имена полей;
-согласованную терминологию и сокращения;
-согласованное использование цветов;
-визуальное выделение пространства и границ полей ввода данных;
-удобные средства перемещения курсора;
-средства исправления отдельных ошибочных символов и целых полей;
-средства вывода сообщений об ошибках при вводе недопустимых значений;
-особое выделение необязательных для ввода полей;
-средства вывода пояснительных сообщений с описанием полей;
-средства вывода сообщения об окончании заполнения формы.
Цель создания эргономичного интерфейса состоит в том, чтобы отобразить информацию настолько эффективно насколько это возможно для человеческого восприятия и структурировать отображение на дисплее таким образом, чтобы привлечь внимание к наиболее важным единицам информации. Основная же цель состоит в том, чтобы минимизировать общую информацию на экране и представить только то, что является необходимым для пользователя.

Количество информации, отображаемой на экране, называется экранной плотностью. Исследования показали, что, чем меньше экранная плотность, тем отображаемая информация наиболее доступна и понятна для пользователя и наоборот, если экранная плотность большая, это может вызвать затруднения в усвоении информации и ее ясном понимании. Однако опытные пользователи могут предпочитать интерфейсы с большой экранной плотностью. Информация на экране может быть сгруппирована и упорядочена в значимые части. Это может быть достигнуто с использованием кадров (фреймов), методов типа цветового кодирования, рамок, негативного изображения или других методов для привлечения внимания.

24. Недоліки реляційної моделі даних. Маніфест СКБД третього покоління

Недостатки реляционной модели:

§ далеко не всегда предметная область может быть представлена в виде "таблиц";

§ в результате логического проектирования появляется множество "таблиц". Это приводит к трудности понимания структуры данных;

§ БД занимает относительно много внешней памяти;

§ относительно низкая скорость доступа к данным.

В манифесте, опубликованном комитетом CADF, предлагаются следующиефункции, которые должна поддерживать любая СУБД третьего поколения.

1. Наличие развитой системы типов.

2. Поддержка механизма наследования.

3. Поддержка функций, включая процедуры и методы базы данных, а также механизма инкапсуляции.

4. Уникальные идентификаторы для записей должны присваиваться средствами СУБД только в том случае, когда нельзя использовать определяемые пользователем первичные ключи.

5. Правила (триггеры и ограничения) станут важнейшим компонентом будущих систем. Они не должны быть связаны с какой-то конкретной функцией или коллекцией.

6. Очень важно, чтобы все программные способы доступа к базе данных осуществлялись с помощью непроцедурного языка высокого уровня.

7. Должны существовать по меньшей мере два способа определения коллекций: один на основе перечисления элементов коллекции, а другой — с использованием языка запросов для определения принадлежности элемента к коллекции

8. Важным является наличие обновляемых представлений.

9. Средства измерения производительности не должны иметь никакого отношения к моделям данных и не должны в них присутствовать.

10. СУБД третьего поколения должны быть доступны из многих языков высокого уровня

11. Желательно, чтобы во многих языках программирования высокого уровня поддерживались конструкции, обеспечивающие доступ к перманентным данным. Эта поддержка должна обеспечиваться на основе применения каждой отдельной СУБД с помощью дополнительных средств компилятора и сложной системы поддержки выполнения программ

12. Плохо ли это или хорошо, но язык SQL должен оставаться "межгалактическим языком работы с данными".

13. Запросы и ответы на них должны составлять самый нижний уровень взаимодействия клиента и сервера

25. Стандарт ODMG. Система управління об’єктними даними. Архітектура та основні компоненти об’єктної моделі даних

Он состоит из объектной модели, языка определения объектов, эквивалентного языка DLL в обычной СУБД, и языка объектных запросов с SQL-подобным синтаксисом.

Объектная модель(ОМ) – является переносимой абстрактной моделью данных, предназначенной для взаимодействия с OMG-совместимыми объектно-ориентированными системами. Инициатор запроса(запрашивающий) посылает запрос объектным службам брокера объектных запросов (ORB-брокеру), который следит за всеми объектами в системе и типами предоставляемых им сервисов. ORB-брокер пересылает сообщение провайдеру, который реагирует на это сообщение и через ORB-брокер передает ответ запрашиваемому.

ORB-брокер является программной шиной, которая позволяет запрашивающим объектам выполнять запросы к провайдерам сервисов и получать их ответы и запросы.

Объектные службы (сервисы) предоставляют основные функции для реализации базовых функциональных возможностей объектно-ориентированной среды: коллекции(обеспечивают универсальный способ создания и манипулирования основными типами коллекций); параллельность(включает менеджера блокировки, позволяющего координировать доступ к общим ресурсам со стороны многих клиентов); жизненный цикл(предлагает операции для создания, копирования, перемещения и удаления групп связных объектов); запрос и т.д.

Архитектура CORBA определяет архитектуру сред, использующих ORB-брокеры. Она является основой любого OMG-совместимого компонента, определяя составные части ORB-брокера и связанных с ним структур.

Основные модельные понятия: объект и литерал, они могут быть разбиты на типы, все объекты заданного типа демонстрируют общее поведение и состояние; поведением называется набор операций, которые могут быть выполнены объектом или над ним; состояние определяется значениями, которые имеются у набора свойств объекта. Свойство может быть либо атрибутом объекта, либо связью между двумя или несколькими объектами. Объекты хранятся в базе данных.

26. Особливості архітектури ООСКБД: способи доступу до об’єктів у зовнішній пам’яті, варіанти архітектури «клієнт-сервер», управління методами в ООСКБД

Рис. 2.1. Одноуровневая модель хранения данных в ООСУБД

Объектно-ориентированная СУБД (ООСУБД)

1. ООСУБД находит на внешнем устройстве хранения страницу, содержащую требуемый объект, используя его OID или индекс, если это необходимо. Затем ООСУБД считывает из внешнего устройства хранения требуемую страницу и копирует ее в кэш страниц приложения, находящийся в пределах памяти, отведенной приложению.

2. ООСУБД может затем выполнить несколько различных преобразований.

3. Приложение осуществляет непосредственный доступ к объекту и обновляет его по мере необходимости.

4. Когда приложению потребуется сделать внесенные изменения перманентными или просто выгрузить на время страницу из кэша на диск, то перед копированием страницы на внешнее устройство хранения ООСУБД должна выполнить обратные преобразования, аналогичные описанным выше.

Архитектура клиент/сервер: 1. Сервер объектов (в этом подходе предпринимается попытка распределить обработку между двумя компонентами. Обычно серверный процесс отвечает за управление хранилищем, блокировки, вывод данных на вторичные устройства хранения, регистрацию клиентов, процедуры восстановления, поддержку безопасности и обеспечение целостности, оптимизацию запросов и выполнение хранимых процедур. Клиент отвечает за управление транзакциями и взаимодействие с языком программирования); 2. Сервер страниц (в этом подходе большая часть функций БД выполняется клиентом, сервер отвечает за доступ к вторичным устройствам хранения и предоставление страниц по требованию клиента); 3. Сервер БД (в этом подходе большая часть функций БД выполняется сервером, клиент просто передает запросы серверу, получает результаты и передает их приложению).

Хранение и выполнение методов: для управления методами могут использоваться два подхода: хранение методов во внешних файлах и хранение методов в БД. Первый подход аналогичен библиотекам функций или интерфейсам прикладного программирования в традиционных СУБД. При использовании второго подхода методы хранятся в БД и динамически связываются с приложением во время выполнения программы. Второй подход обладает несколькими преимуществами.

27. Переваги і недоліки ООСКБД. Порівняння об’єктного і семантичного підходів до моделювання даних

Преимущества:

1. Улучшение возможности моделирования (позволяет более точно моделировать реальный мир. Объект может хранить все связи, которыми он связан с другими объектами); 2. Расширяемость (в ООСУБД допускается создание новых абстрактных типов данных на основе существующих типов); 3. Устранение проблемы несоответствия (простой интерфейс между языком манипулирования данными и языком программирования позволяет устранить проблему их несоответствия); 4. Более выразительный язык запросов (определен декларативный язык запросов, построенный на обьектно-ориентированной форме языка SQL); 5. Поддержка эволюции схемы (строгая связь между данными и приложениями в ООСУБД делает эволюцию схемы более гибкой); 6. Поддержка долговременных транзакций (спорно); 7. Применимость для сложных специализированных приложений баз данных; 8. Повышенная производительность.

Недостатки:

1. Отсутствие универсальной модели данных; 2. Недостаточность опыта эксплуатации; 3. Отсутствие стандартов; 4. Влияние оптимизации запросов на инкапсуляцию (для оптимизации запросов и организации эффективного доступа к БД необходимо обладать знаниями об особенностях реализации); 5. Влияние блокировки на уровне объекта на производительность(во многих СУБД блокировка используется как основа построения протокола управления параллельностью. Однако применение блокировки на уровне объекта может вызвать проблемы с блокировкой в отношении иерархии наследования, а также оказать существенное влияние на общую производительность системы); 6. Сложность; 7. Отсутствие поддержки представлений; 8. Недостаточность средств обеспечения безопасности.

Сравнение обьектного и логического моделирования БД: основное отличие заключается в инкапсуляции данных и поведении в объекте, тогда как в EER-модели хранится только информация о состоянии без каких-либо сведений о поведении. Таким образом, логическое моделирование данных не включает понятия «сообщение» и соответственно понятия «инкапсуляция».

28. Розширена реляційна модель даних і об’єктно-реляційні СКБД

Во всех моделях используются одинаковые базовые реляционные таблицы и язык запросов, включено понятие объекта, а в некоторых дополнительно реализована возможность сохранения методов (или процедур, или триггеров) таким же способом, что и базе данных.

Чаще всего используется термин Объектно-реляционная СУБД или ОРСУБД. Разработка стандартов в этой сфере построена на расширении стандарта языка SQL.