логическая модель. Как было описано выше в данной главе, логическая модель, кроме всего прочего, предоставляет возможность обсуждать со всеми заинтересованными лицами бизнес-правила и требования к данным. В частности, на рис. 7.13 представлена схема, которая позволяет любому (в том числе заказчику) без лишних пояснений понять, на каком основании типы документов, предназначенные для хранения в таблицах Leases (Арендные договора). Divorces (Свидетельства о разводе) и Sales (Акты купли-продажи), рассматриваются как принадлежащие к общей суперкатегории документа. К тому же эта схема дает возможность определить, в чем состоят различия между отдельными типами документов. Еще одна возможность продуктивного использования логической модели состоит в том, что на ее основе может быть проведено расширение подкатегорий, например, добавление в базу данных документов такого типа, как завещания и доверенности. Очевидно, что логическая модель и схема, составленная на ее основе, позволяют достичь значительной экономии времени и денег в процессе проектирования.

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

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

DocumentType

Document

DocumentTypelD

Description

lO----

Lease;r

DocumentID (FK)

Leasee Leasor LeaseTerm Rate

SecurityDeposit

StartDate

ExpirationDate

OptionDate

OptionPeriod

DocumentID

DocumenfTypelD (FK)

Title

Author

CreatedOn

LastUpdatedOn

StorageLocation

Divorces у

DocumentID (FK)

Plantiff

Defendant

Separation Date

FiledOn

FinalizedOn

Alimony

ChildSuppol

Sales/Г

DocumentID (FK)

SaleDate

SaleAmount

Seller

Purchaser

WarrantyPeriod

Puc. 7.14. Пример физической модели

При этом единственная реальная сложность возникает, если в проекте нельзя обойтись без применения неисключительных подкатегорий (что, к сожалению, встречается чаще, чем хотелось бы). В этом случае необходимо привязывать к таблицам подкатегорий определенные программные средства обработки (в форме триггеров), которые позволяли бы следить за тем, чтобы при вставке строки не обнаруживалась совпадающая с ней строка в таблице одной из прочих подкатегорий. Например, если могут совпадать идентификационные номера в таблицах с документами таких типов, как свидетельства о разводе и акты купли-продажи, с идентификационными номерами в таблице с арендными договорами, а для ссылки на эти таблицы как раз и применяется столбец DocumentID (Идентификационный номер), то необходимо предусмотреть триггер вставки, который позволил бы исключить появление строк с одинаковыми клю-чами в таблицах Divorces, Sales и Leases. При обнаружении такого совпадения триггер должен отвергнуть вставляемую строку, сформировать соответств}тощее сообщение об ошибке и вызвать на вьшолнение оператор ROLLBACK.

Применение дополнительных средств расширения подкатегорий

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

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

Иными словами, при проектировании на основе подкатегорий достигаются два основных преимущества масштабируемости.

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

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

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

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

Многократное использование базы данных

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

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

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

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