DocumentType

Document

DocumentTypelD

Description

lO -

DocumentID

DocumentTypelD (FK)

Title

Author

CreatedOn

LastUpdatedOn

StorageLocation

Leasejr

Divorces у

Sales у у

DocumentID (FK)

Leasee Leasor LeaseTerm Rate

SecurityDeposit StartDate ExpirationDate OptionDate Option Period

DocumentID (FK)

Plantlff

Defendant

SeparationDate

FiledOn

FinalizedOn

Alimony

ChildSuppd

DocumentID (FK)

SaleDate

SaleAmount

Seller

Purchaser

WarrantyPeriod

Puc. 7.12. Классификация на основе исключительных категорий

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

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

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

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

в которой приведены общие данные, относящиеся к каждому документу. Безусловно, таблица, в которой содержатся данные, общие для всех документов, позволяет сразу же получить информацию, которая касается общих атрибутов документов, но чаще всего возникает необходимость обеспечить получение данных, касающихся документа конкретного типа (которые можно получить только в таблице, предназначенной для хранения информации документов этого типа). Для этого требуется прежде всего определить, в какой таблице находится искомая информация. Для этого достаточно ввести в таблицу суперкатегории такое поле, которое указывает, к какой подкатегории относится документ, представленный в каждой конкретной строке. В рассматриваемом примере было бы удобней всего ввести в таблицу с данными обо всех документах (назовем ее Documents) столбец с указанием типа документа, допустим, столбец Document Туре. На основании информации о типе документа можно определить, к какой таблице следует обратиться после чтения строки с основными данными о документе, чтобы получить все необходимые дополнительные сведения. Кроме того, связь между таблицами можно организовать с помощью столбца, данные в который вводятся только после проверки по справочной таблице (таблице, в которой указаны только те значения, относящиеся к применяемым тгаам документов, которые могут находиться в столбце Document Туре), и предусмотреть применение внешнего ключа, который указывает на эту таблицу.

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

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

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

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

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

Document Туре

Document

Document TypelD

Description

----OK

DocumentID

DocumentTypelD (FK)

Title

Author

CreatedOn

LastUpdatedOn

StorageLocation

Puc. 7.13. Пример логической модели

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

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