IX Международная студенческая научная конференция Студенческий научный форум - 2017

ВВЕДЕНИЕ

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

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

Физическое проектирование базы данных — процесс подготовки описания реализации базы данных на вторичных запоминающих устройствах; на этом этапе рассматриваются основные отношения, организация файлов и индексов, предназначенных для обеспечения эффективного доступа к данным, а также все связанные с этим ограничения целостности и средства защиты.

Как правило, основной целью физического проектирования базы данных является описание способа физической реализации логического проекта базы данных.

1 Основные принципы проектирования баз данных

Современные информационные системы характеризуются большими объемами хранимых данных, их сложной организацией, а также высокими требованиями к скорости и эффективности обработки этих данных. Это становится возможным при использовании специальных программных средств - систем управления базами данных (СУБД).

База данных (БД) — это поименованная совокупность данных, относящихся к определенной предметной области.

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

Почти все современные СУБД основаны на реляционной модели данных. Название "реляционная" связано с тем, что каждая запись в такой базе данных содержит информацию, относящуюся (related) только к одному объекту. Все данные в реляционной БД представлены в виде таблиц. Каждая строка таблицы содержит информацию только об одном объекте и называется записью. Столбец таблицы содержит однотипную для всех записей информацию и называется полем.

К современным базам данных, а следовательно, и к СУБД, на которых они строятся, предъявляются следующие основные требования:

— Высокое быстродействие (малое время отклика на запрос). Время отклика — промежуток времени от момента запроса к БД до фактического получения данных.

— Простота обновления данных.

— Независимость данных (возможность изменения логической и физической структуры БД без изменения представлений пользователей).

— Совместное использование данных многими пользователями.

— Безопасность данных (защита данных от преднамеренного или непреднамеренного нарушения секретности, искажения или разрушения).

— Стандартизация построения и эксплуатации БД (фактически СУБД).

— Адекватность отображения данных соответствующей предметной области.

— Простой интерфейс пользователя.

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

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

Проектирование баз данных — это процесс решения класса задач, связанных с созданием баз данных.

Основными задачами проектирования баз данных являются:

— Обеспечение хранения в БД всей необходимой информации.

— Обеспечение возможности получения данных по всем необходимым запросам.

— Сокращение избыточности и дублирования данных.

— Обеспечение целостности данных (правильности их содержания): исключение противоречий в содержании данных, исключение их потери и так далее.

2 ЭТАПЫ ПРОКТИРОВАНИЯ БАЗЫ ДАННЫХ

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

Процесс проектирования базы данных состоит из трех основных этапов (приложение 1):

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

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

Основные элементы данной модели:

1. Описание объектов предметной области и связей между ними.

2. Описание информационных потребностей пользователей (описание основных запросов к БД).

3. Описание алгоритмических зависимостей между данными.

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

— Логическое (даталогическое) проектирование. Его цель состоит в создании логической модели данных для исследуемой части предприятия. Концептуальная модель данных, созданная на предыдущем этапе, уточняется и преобразуется в логическую модель данных. Логическая модель данных учитывает особенности выбранной модели организации данных в целевой СУБД (например, реляционная модель).

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

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

Логическое (даталогическое) проектирование – отображение инфологической модели на модель данных, используемую в конкретной СУБД, например на реляционную модель данных. Для реляционных СУБД даталогическая модель – набор таблиц, обычно с указанием ключевых полей, связей между таблицами. Если инфологическая модель построена в виде ER-диаграмм (или других формализованных средств), то даталогическое проектирование представляет собой построение таблиц по определённым формализованным правилам, а также нормализацию этих таблиц. Этот этап может быть в значительной степени автоматизирован.

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

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

На этапе инфологического проектирования в ходе сбора информации о предметной области требуется выяснить:

1. основные объекты предметной области (объекты, о которых должна храниться информация в БД);

2. атрибуты объектов;

3. связи между объектами;

4. основные запросы к БД.

3 Этапы физического проектирования БД

Как правило, основной целью физического проектирования базы данных является описание способа физической реализации логического проекта базы данных.

В случае реляционной модели данных под этим подразумевается следующее:

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

— определение конкретных структур хранения данных и методов доступа к ним, обеспечивающих оптимальную производительность СУБД;

— разработка средств защиты создаваемой системы.

Этапы концептуального и логического проектирования больших систем следует отделять от этапов физического проектирования. На это есть несколько причин.

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

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

— Они требуют совершенно разных навыков и опыта, поэтому требуют привлечения специалистов различного профиля.

Этапы физического проектирования баз данных [6]:

1. Перенос логической модели данных в среду целевой СУБД.

2. Проектирование основных отношений.

3. Разработка способов получения производных данных.

4. Реализация ограничений предметной области.

5. Проектирование физического представления базы данных.

6. Анализ транзакций.

7. Выбор файловой структуры.

8. Определение индексов.

9. Определение требований к дисковой памяти.

10. Проектирование пользовательских представлений.

11. Разработка механизмов защиты.

12. Обоснование необходимости введения контролируемой избыточности.

13. Текущий контроль и настройка операционной системы.

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

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

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

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

4 Анализ транзакций

Транзакция – это одно действие или последовательность действий, выполняемых одним и тем же пользователем (или прикладной программой), осуществляющим доступ к базе данных или изменение ее содержимого. Транзакции представляют такие события реального мира, как, например, регистрация предлагаемого для сдачи в аренду объекта недвижимости, назначение встречи с потенциальным арендатором с целью осмотра некоторого объекта, прием на работу нового сотрудника или регистрация нового клиента. Все эти транзакции должны обращаться к базе данных с той целью, чтобы хранимые в ней данные всегда гарантированно соответствовали текущей ситуации в реальном мире, а также для удовлетворения информационных потребностей пользователей [5].

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

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

– данные, которые используются транзакцией;

– функциональные характеристики транзакции;

– выходные данные, формируемые транзакцией;

– степень важности транзакции для пользователей;

– предполагаемая интенсивность использования.

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

— транзакции, выполняемые наиболее часто и оказывающие существенное влияние на производительность;

— транзакции, наиболее важные для работы организации;

— периоды времени на протяжении суток/недель, в которые нагрузка базы данных возрастает до максимума (называемые периодами пиковой нагрузки);

— ожидаемая частота выполнения транзакций;

— отношения и атрибуты, к которым потребуется иметь доступ при выполнении транзакции, а также тип этого доступа;

— ограничения, устанавливаемые на время выполнения транзакций.

СУБД, созданная для поддержки оперативной обработки транзакций, называется OLTP-системой (Online Transaction Processing). Обычно OLTP-системы проектируются с целью обеспечения максимально интенсивной обработки транзакций.

5 Производительность: определение индексов

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

Индексирование (indexing) — это способ обеспечения быстрого доступа к значениям колонки или комбинации колонок. Физически новые строки добавляются в конец таблицы, результатом чего становится неупорядоченное размещение значений в колонках. Без использования каких-либо методов упорядочения данных единственным способом просмотра значения колонки со стороны СУБД является последовательный просмотр каждой строки от начала таблицы к ее концу — так называемое сканирование таблицы. Производительность такого сканирования пропорциональна размеру таблицы, размеру физической страницы БД и длине строки таблицы [2].

Одним из способов внесения отношения порядка в значения колонок без нарушения физического расположения строк таблицы является создание объекта реляционной СУБД — индекса (index). Индекс — это объект в реляционной БД, который предназначен для организации быстрого доступа к строкам таблицы по значениям одной или более колонок этих строк.

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

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

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

Каждая таблица БД может иметь один или несколько индексов. Индексы создаются по одной колонке или нескольким колонкам таблицы. Колонки, входящие в индекс, принято называть ключевыми полями (key fields), или ключами. Индексы могут быть уникальными и неуникальными. Уникальность индекса означает, что не существует двух строк с одним и тем же значением ключа индекса. Неуникальный индекс может иметь несколько ключей с одинаковыми значениями.

Основными целями создания индексов в БД являются:

— ускорение поиска строк в таблицах;

— обеспечение уникального значения в колонках;

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

На этапе создания физической модели данных БД необходимо принять ряд важных решений о том, что и как индексировать; при этом важно четко сформулировать правила индексирования. Для каждого проекта с БД необходимо создать и оформить в письменном виде правила индексирования как часть общих правил обеспечения производительности. Поддержка и сопровождение индексов в процессе эксплуатации БД является в основном задачей администратора БД. Решая задачи обеспечения производительности, администратор БД будет ставить вопрос о перепроектировании ее физической структуры (обратные задачи проектирования), в том числе и вопрос об удалении и создании новых индексов. Он может решать эти задачи самостоятельно. Тем более важно знать, по каким правилам и из каких соображений создавались индексы того или иного типа. Разработка таких правил значительно повысит качество эксплуатации ХД с точки зрения обеспечения ее производительности.

Чтобы решать эти задачи, проектировщик должен знать, как работает индекс, какие типы индексов поддерживает СУБД, и понимать смысл методов индексирования.

Заключение

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

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

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

Список использованной литературы

1. Ульман Дж. Основы систем баз данных. - М., Финансы и статистика, 2014. — 438 с.

2. Коннолли Томас, Бегг Карелин. Базы данных. Проектирование, реализация и сопровождение. Теория и практика. 3-е издание. : Пер. с англ. — М.: Издательский дом "Вильямс", 2011. — 1440 с.

3. Карпова Т. С. Базы данных: модели, разработка, реализация.– СПб.: Питер, 2013. – 304 с.

4. Bourabai Research: ТЕХНОЛОГИИ XXI ВЕКА [Электронный ресурс]: Физическое проектирование базы данных –– Режим доступа (URL): http://bourabai.ru/dbt/dbms/03.htm (Дата обращения: 17.12.2016)

5. Советов, Б.Я. Базы данных: теория и практика: Учебник для бакалавров / Б.Я. Советов, В.В. Цехановский, В.Д. Чертовской. — М.: Юрайт, 2013. — 463 c.

6. Кузин, А.В. Базы данных: Учебное пособие для студ. высш. учеб. заведений / А.В. Кузин, С.В. Левонисова. — М.: ИЦ Академия, 2012. — 320 c.

Приложение 1. Этапы проектирования баз данных

Результат проверки на антиплагиат:

20

Код для цитирования: Скопировать