Даталогическое проектирование - Банки и базы данных. Системы управления базами данных

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

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

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

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

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

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

    1. Наличие синонимов в предметной области. Это означает, что естественное свойство объекта, наиболее подходящее для использования его в качестве первичного ключа, не обладает свойством уникальности. Например, в списке сотрудников может быть по каким-то причинам не предусмотрено наличие таких свойств, как табельный номер или номер паспорта (эти поля, очевидно, были бы уникальными и могли бы использоваться в качестве ключей). Естественный идентификатор сотрудника - ФИО - при наличии полных однофамильцев в этом случае теряет свойство уникальности и не может быть использован в качестве ключа. Единственным выходом из ситуации становится искусственное добавление дополнительного ключевого (например, автоинкрементного) поля. 2. Второй случай рассмотрен выше - значения естественного идентификатора объекта могут меняться со временем. 3. Один и тот же объект может участвовать во множестве связей с другими объектами. Это значит, что некий естественный идентификатор объекта должен присутствовать в качестве атрибута во многих отношениях. Если этот идентификатор является длинным (например, текстовым полем), а других более коротких естественных идентификаторов у этого объекта нет, то целесообразным является введение какого-то более короткого кодового обозначения для каждого экземпляра этого объекта.

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

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

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

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

Отдельного анализа требует задача создания отношений в случае наличия в ER-модели сложных объектов.

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

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

Другим вариантом является создание для каждой категории объекта собственного отношения с атрибутами, соответствующими наследуемым и уникальным свойствам данной категории.

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

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

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

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

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

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

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

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

Еще одним аспектом является возможность адаптации системы к изменениям в программном обеспечении. Это означает, что программное обеспечение должно быть стандартизированным и широко распространенным.

    5. Дублирование данных. Дублирование данных является необходимым для обеспечения целостности данных в случае необходимости восстановления БД. Однако необходимо понимать, что дублирование приводит к увеличению объема памяти, к затратам на поддержание идентичности всех имеющихся копий, к требованиям, накладываемым на программное обеспечение, а значит, и к усложнению всей системы. 6. Объем необходимой памяти. 7. Скорость доступа к данным и обработки информации. Этот критерий относится, прежде всего, к системам, работающим в реальном масштабе времени. Оценить его иногда бывает достаточно сложно, особенно если система работает в многопользовательском режиме. Легче всего это сделать с помощью специальных тестовых программ, учитывающих большое количество как взаимозависимых, так и взаимонезависимых факторов. 8. Универсальность. Под этим, в частности, понимается возможность использования БД широким кругом пользователей, в том числе не являющихся специалистами в области компьютерных технологий.

Похожие статьи




Даталогическое проектирование - Банки и базы данных. Системы управления базами данных

Предыдущая | Следующая