Объектный подход

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

Использование атрибутов первичного ключа символьного типа для баз данных, предполагающих обработку большого объема данных, является достаточно неэффективным решением, которое никак не может быть разрешено с помощью правил нормализации. Эго видно по результату нормализации в документарном подходе построения модели базы данных, где некоторые первичные ключи являются символьными. Учитывая, что наименований товаров будет не очень много и их количество не превысит 1000—2000 экземпляров, такая ситуация с символьным первичным ключом серьезных проблем не создаст, но в случае номера заказа, который также представлен символьным типом данных, все становится намного сложнее. Первое время использования информационной системы, когда только будет начинать формироваться база заказов, проблемы скорости не будут замечены и построенные запросы по выборке и обработке данных, при их оценке, не покажут низкую скорость обработки. Однако со временем база заказов будет пополняться и количество экземпляров заказов и позиций товаров в этих заказах, которые, кстати, также имеют в качестве первичного ключа символьный атрибут "Наименование товара", будет экспоненциально увеличиваться. В конечном счете по истечении 3—5 лет использования информационной системы, а может быть и ранее, если магазин будет пользоваться популярностью, количество экземпляров позиций товаров в заказах может измеряться миллионами или даже десятками миллионов записей, что тут же скажется на скорости и эффективности обработки данных. Хоть атрибуты первичных ключей, по умолчанию, индексируются и внутренние механизмы СУБД обеспечивают оптимизацию запросов, но при попытках сделать запросы, где необходимо выполнять поиск по этим первичным ключам в рамках, например, соединения таблиц в запросах, все оптимизационные механизмы СУБД не смогут справиться с объемом обрабатываемых символьных данных и скорость получения результата запросов будет очень низкой.

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

1. Чтение двух сравниваемых значений в символьном виде.

2. Разделение каждого значения на множество (массив) отдельных символов.

3. Перевод всех символов в числовой вид (код таблицы символов).

4. Последовательное посимвольное сравнение кодов символов.

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

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

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

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

Правило

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

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

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

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

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

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

Эффективность объектного подхода заключается в том, что:

— результирующая модель находится в третьей и последующих нормальных формах;

- не проводится рассмотрение сразу большого количества сущностей (отношений, объектов, типов сущностей);

сразу формируется модель базы данных и нет необходимости представлять ее по итогам нормализации;

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

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

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

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

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

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

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

Рис. 4.19. Процесс использования объектного подхода проектирования базы данных

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