Физическая организация данных

• Название: Физическая организация данных
• Дата: 23.02.2018
• Размер: 487.44 Kb.
• Имя файла: db.docx
• Тип: Документы; #37060
• страница: 10 из 16

Если оптимизатор плохо оптимизирует операцию "или" (OR), то можно заменять её операцией UNION при наличии индексов. Убедиться в "плохой оптимизации" можно так: выполнить запрос по условию (field=X) и запрос с условием ((field=X) OR (field=Y)) на большой таблице. Если второй запрос выполняется намного дольше, чем первый, то OR не оптимизируется. Например, список "Пациенты палат №3 и пациенты, больные гриппом" в отсутствие индексов можно сформулировать так:

SELECT * FROM Patients WHERE room=3 OR diagnose LIKE 'грипп%' ;

а если индексы есть, то таким:

SELECT * FROM Patients WHERE room=3 UNION ALL SELECT * FROM Patients WHERE diagnose LIKE ' грипп%';

8. 
   Условие "не равно" ('<>') также подавляет использование индекса. Поэтому, если значения индексированного столбца распределены неравномерно, следует заменять его комбинацией условий '<' OR '>' и, с учетом предыдущего правила, реализовывать это с помощью UNION.
   

Например, список сотрудников всех отделов (10% от общего числа), кроме сотрудников центрального офиса (отдел №3) будет выглядеть так:

SELECT * FROM Emp WHERE deptNo<3 UNION ALL SELECT * FROM Emp WHERE deptNo>3;

9. 
   9. Некоторые оптимизаторы будут использовать индексное сканирование, если запрос содержит раздел ORDER BY с указанием индексированного столбца. Для выполнения следующего запроса будет использован индекс на столбце tabNo, даже если этот столбец не используется в условиях раздела WHERE:
   

SELECT * FROM emp WHERE depNo<3 ORDER BY tabNo;

10. 
    Условие <выражение1> op <выражение2>, где op - операция, также не позволяют использовать индекс. Из выражений надо по возможности вынести в левую часть поле, по которому есть индекс. Например, условие (salary*0.87>30000) лучше записать так: salary>30000/0.87.
    

При настройке команд SQL важно помнить, что, настраивая одну из них, можно оказать влияние (и не всегда позитивное) на другие команды. Поэтому во время настройки необходимо периодически осуществлять регрессионное тестирование, т.е. повторный запуск уже протестированных команд для оценки времени их выполнения.

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

"Сложная система, спроектированная наспех, никогда не работа-ет, и исправить её, чтобы заставить работать, невозможно".

Законы Мерфи. 16-й закон системантики

6. 
   ЭЛЕМЕНТЫ ПРОЕКТИРОВАНИЯ БАЗ ДАННЫХ
   

Проектирование базы данных (БД) - одна из наиболее сложных и ответственных задач, связанных с созданием автоматизированных информационных систем (АИС).

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

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

1. 
   Требования к проекту базы данных
   

Основные требования, которым должен удовлетворять проект БД:

1. 
   Корректность схемы БД.
   

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

2. 
   Обеспечение ограничений на ресурсы вычислительной системы.
   

В первую очередь имеются в виду ограничения на объёмы внешней и оперативной памяти, которые потребуются для функционирования БД.

3. 
   Эффективность функционирования.
   

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

4. 
   Защита данных.
   

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

5. 
   Гибкость
   

Под этим подразумевается возможность развития и адаптации БД к изменениям предметной области и/или требований пользователей.

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

6. 
   Простота и удобство эксплуатации.
   

Под этим подразумевается соблюдение привычного для пользователя алгоритма работы с данными. От этого не в последнюю очередь зависит количество ошибок пользователя.

Удовлетворение первых 4-х требований обязательно для принятия проекта.

2. 
   Этапы проектирования базы данных
   

В создании автоматизированной информационной системы, вклю-чающей базу

данных, можно выделить три этапа:

1. 
   Предпроектная подготовка.
   
2. 
   Проектирование БД.
   
3. 
   Реализация (создание БД и ППО).
   

Проектирование начинается обычно с планирования, что позволяет:

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

Работа по созданию БД начинается с подбора кадров. Требуется определить, какие специалисты необходимы для выполнения этой работы. В общем случае это должны быть следующие категории:

• 
  Аналитики. Это специалисты исследуемой предметной области, которые в идеале должны быть знакомы с основами создания баз данных. В их задачу входит постановка задачи проектирования: анализ ПО, выявление бизнес-процессов и бизнес-правил, определение требований к БД.
  
• 
  Пользователи. Наличие этой категории работников особенно важно тогда, когда проект БД создаётся в развитие существующей информационной системы, т.к. в этом случае есть определённый опыт работы (традиции, привычки и вместе с тем пожелания). Всё это желательно учитывать для того, чтобы обеспечить преемственность и не вызвать негативного отношения к системе, например, из-за непривычного интерфейса.
  
• 
  Проектировщики. Это сотрудники, которые будут заниматься собственно разработкой проекта БД.
  
• 
  Администраторы. В том случае, если система небольшая, администратор БД может быть один. Если же система большая и территориально распределенная, то помимо АБД потребуется ещё администратор системы, и, возможно, не один. АБД должен появиться не тогда, когда система уже спроектирована, а на этапе проектирования БД. Это необходимо хотя бы потому, что при проектировании для отладки и тестирования обязательно создаётся рабочий прототип БД, и желательно, чтобы за общее обеспечение функционирования этого прототипа отвечал отдельный специалист.
  
• 
  Разработчики программного обеспечения. Любая БД требует помимо СУБД создания некоторого прикладного программного обеспечения (ППО). Если сложность этого ППО невелика, то обычно его созданием занимаются сами проектировщики. В противном случае, необходимо набрать программистов (или выделить из имеющихся), которые будут этим заниматься.
  

При определении потребности в кадрах может возникнуть ситуация, когда уже на этом этапе станет очевидна невозможность подбора нужного количества специалистов определённого профиля и квалификации. Тогда это может привести к пересмотру объёма задач, стоящих перед базой данных.

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

Перечислим более подробно задачи, решение которых должно предшествовать созданию проекта БД.

1. 
   Предварительный анализ ПО.
   

Включает в себя сбор документов, характеризующих ПО, укрупнённое описание ПО (не детализированное) и общую постановку задачи.

В процессе анализа и проектирования желательно ранжировать планируемые функции системы по степени важности. Один из возможных вариантов классификации - MoSCoW-анализ (терминология Клегга и Баркера, [8]):

Must have - необходимые функции;

Should have - желательные функции;

Could have - возможные функции;

Won't have - отсутствующие функции

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

Примечание: если применяются средства автоматизации проектирования (CASE-средства), то задачу последовательного внесения изменений берёт на себя это CASE-средство.

2. 
   Рассмотрение и принятие результатов анализа.
   

Эта задача обычно решается итеративно во взаимодействии проектировщиков и заказчиков (или аналитиков). На этом этапе очень важно определить, что проектировщики правильно понимают описание предметной области и задачи, поставленные перед ними аналитиками.

Для этого обычно проводятся совместные семинары, на которых проверяется адекватность модели и предметной области.

Рис. 8.1. Жизненный цикл приложения баз данных

3. 
   Определение критических факторов успеха.
   

В данном случае под термином критические факторы подразумеваются как "жизненно важные для приёмки и успешной реализации проекта”, так и "критические с точки зрения функционирования системы". Очевидно, что если не учесть хотя бы один из таких факторов, то существование и успешное функционирование проекта будет поставлено под вопрос.

4. 
   Оценка системных ограничений.
   

В качестве часто встречающихся ограничений можно отметить следующие:

о финансовые

о временные

о технические (например, выбор определённой аппаратуры);

о программные (например, выбор определённого программного обеспечения);

5. 
   Определение целевой архитектуры.
   

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

6. 
   Определение требований к производительности.
   

Необходимо примерно оценить количество транзакций в единицу времени и объём обрабатываемых этими транзакциями данных. Требования к производительности зависят от режима, в котором будет функционировать система:

1. 
   Интерактивный режим. Для этого режима устанавливается время, в течение которого пользователь должен получить ответ на свой запрос. Обычно время реакции системы не должно превышать нескольких секунд.
   
2. 
   Пакетный режим. Здесь требования к производительности обычно не такие жёсткие, как для интерактивного режима, и выражаются в минутах или часах, требующихся на получение конечного результата вычислений.
   
3. 
   Режим реального времени. Этот режим является самым сложно реализуемым. В настоящее время (2009 г.) существует только одна СУБД, которая в полной мере отвечает требованиям режима реального времени: СУБД ЛИНТЕР - единственная СУБД отечественного производства (компания РЕЛЭКС, г. Воронеж).
   

7. 
   Согласование стандартов проектирования, в частности:
   

о правил именования объектов;

о стандарта проектной документации;

о правил введения общих типов и т.п.

8. 
   Выбор программных средств для проектирования и реализации системы (имеется в виду вспомогательные средства типа CASE и др.).
   

Собственно процесс проектирования БД включает в себя следующие основные этапы:

1. 
   Информационно-логическое (инфологическое) проектирование
   
2. 
   Определение требований к операционной обстановке, в которой будет функционировать информационная система.
   
3. 
   Выбор СУБД и других инструментальных программных средств
   
4. 
   Логическое проектирование БД. (Иногда этот этап называется даталогическим проектированием).
   
5. 
   Физическое проектирование БД.
   

Эти этапы подробно рассмотрены в следующем разделе.

После того, как проект базы данных создан, наступает этап реализации проекта.

Он разбивается на следующие шаги:

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

о автономные - тесты отдельных модулей;

о тестыг связей - тесты между модулями;

о регрессивныге - тесты на проверку уже автономные - тесты отдельных модулей;

о протестированных модулей в связи с подключением новых модулей (функций), которые могут нарушить работу ранее созданных модулей;

о нагрузочныге - тесты на проверку времени реакции системы в рабочем режиме или определение производительности системы;

о системныге - тесты на проверку функционирования системы в целом;

о приёмо-сдаточные - тесты, которые проводятся при сдаче системы (АИС) в эксплуатацию.

На этапе III.4 обычно выполняются нагрузочные, системные и приёмосдаточные тесты.