Документирование первичных и альтернативных ключей

Определение потенциальных ключей и выбор первичного ключа

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

• Используйте потенциальный ключ с минимальным набором атрибутов.

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

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

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

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

В процессе определения первичного ключа устанавливается, является данная сущность сильной или слабой. Если выбрать первичный ключ для данной сущности оказалось возможным, то такую сущность принято называть сильной: И наоборот, если выбрать первичный ключ для заданной сущности невозможно, то ее называют слабой (см. раздел 5.1.1).

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

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

Этап 1.6. Специализация или генерализация типов сущностей (необязательный этап)

Цель Определение суперклассов и подклассов для типов сущностей (если это необходимо).

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

В качестве примера рассмотрим сущности Property for_Rent (Недвижимость, сдавае­мая в аренду) и Proprty for_Sale (Недвижимость для продажи), представленные на рис. 7.1, а. Следует принять решение, есть ли необходимость генерализировать эти сущности в подклассы обобщающего суперкласса, представленного сущностью Property (Недвижимость), или же целесообразнее оставить их независимыми сущностями. Обе эти сущности имеют несколько одинаковых атрибутов, связанных с типом объекта не­движимости (Type) и его адресом (Street, Area, City, Postcode), а также одинаковый пер­вичный ключ (Property_No — Учетный номер объекта недвижимости). Однако они обла­дают и различными атрибутами — например, такими как Rent (Арендная ставка) в случае сущности Property_for_Rent и Price (Цена) в случае сущности Proprty_for_Sale. Кроме того, отметим, что обе рассматриваемые сущности имеют общую связь Owner Owns Property. Однако каждая из сущностей имеет и собственную уникальную связь — Renter rents Property_for_Rent и Buyer Buys Property_for_Sale.

Мы принимаем решение генерализировать сущности Property_for Sale и Prop­erty for Rent исходя из существующей между ними общности атрибутов и связей. В результате сущности Property_for_Sale и Property £or_Rent теперь будут рассматри­ваться нами как отдельные подклассы суперкласса Property, структура которого по­казана на рис. 7.1, б. Связь, которую суперкласс Property имеет со своими подклас­сами, является полной и непересекающейся, поскольку каждый член суперкласса Property должен быть членом одного из подклассов (Property for Sale или Prop-erty_for_Rent), но никогда не может принадлежать сразу обоим подклассам. Данное представление является достаточно полезным для отображения общих атрибутов и связей, относящихся к отдельным подклассами.

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

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

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

Этап 1.7. Создание диаграммы „сущность-связь"

Цель Разработка диаграмм "сущность-связь" (ER-диаграмм), содержащих концептуальное отражение представлений пользователя о предметной области приложения.

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

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

I'

Прежде чем завершить первый этап разработки, необходимо обсудить созданные локальные концептуальные модели данных с конечными пользователями. Концепту­альная модель данных должна быть представлена ER-диаграммой и сопроводительной документацией, содержащей описание разработанной модели данных. 'Если в предло­женной модели будут обнаружены какие-либо несоответствия, следует внести в нее не­обходимые изменения (скорее всего, для этого потребуется повторно выполнить один или несколько предыдущих этапов разработки). Этот процесс должен продолжаться до тех пор, пока пользователь не подтвердит, что предложенная ему модель адекватно от­ражает его личное представление о работе приложения и предприятия в целом.

В главе 10, "Пример разработки концептуального проекта базы данных", мы пока­жем, как предложенную в этой главе методологию можно использовать на практике. Для этой цели мы воспользуемся демонстрационным примером — приложением DreamHome. Все описанные в этой главе этапы в обобщенном виде представлены в приложении Е, "Краткий обзор методологии проектирования реляционных баз данных", В следующей главе описываются этапы логического проектирования базы данных.

Резюме

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

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

• Концептуальное проектирование базы данных представляет собой процесс конструирования информационной модели работы предприятия, не зависящей от каких-либо физических пащияетров реализации.

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

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

• Логическое проектирование базы данных представляет собой процесс создания информационной модели работы предприятия на основе отдельных концепту­альных моделей данных. Создаваемая модель не зависит от особенностей функ­ционирования конкретных СУБД и других физических условий реализации.

• В процессе логического проектирования базы данных локальные концептуаль­ные модели данных преобразуются в локальные логические модели данных, структура которых определяется выбранным классом целевой СУБД (напри­мер, СУБД реляционного типа).

• Локальные логические модели данных объединяются в глобальную логиче­скую модель данных, отражающую обобщенное представление всех пользова­телей о предметной области приложения.*

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

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

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

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

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

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

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

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

Вопросы

7.1. Укажите общее назначение предлагаемой методологии проектирования.

7.2. Назовите основные фазы процесса проектирования базы данных.

7.3. Укажите важнейшие факторы успешного завершения процесса разработки ба­зы данных.

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

7.5. Назовите основную цель фазы концептуального проектирования базы данных.

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

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

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

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

Дата добавления: 2014-01-04