Волк В.К. Базы данных. Практикум по проектированию, программированию и администрированию баз данных, включающий примеры и практические задания для самостоятельного выполнения
 Скачать 3.17 Mb.
|
|
ГЛАВА 3. ЭСКИЗНЫЙ ПРОЕКТ. РАЗРАБОТКА КОНЦЕПТУАЛЬНОЙ ER-МОДЕЛИ 3.1. Два уровня объектной декомпозиции В соответствии с базовыми принципами проектирования сложных объек- тов, объектную декомпозицию системы целесообразно проводить несколькими этапами на двух иерархических уровнях. На первом этапе производится декомпозиция объектов верхнего уровня иерархии, в результате которой формируется множество так называемых ло- кальных представлений, группирующих объекты предметной области по опре- деленным критериям с целью упрощения последующей разработки ER-модели. Возможны различные подходы к такой группировке, один из вариантов базируется на результатах функциональной декомпозиции системы, пред- ставленной, например, в форме UML-диаграммы вариантов использования (UseCase-Diagram). В зависимости от сложности UseCase-модели локальные представления могут быть сформированы на основе каждого базового варианта использования или на основе множества вариантов использования, ассоцииро- ванных с одной пользовательской ролью. В более сложных случаях разработ- чик ER-модели может принять решение о более детальной декомпозиции на этом уровне, например с использованием вложенности одних локальных пред- ставлений в другие. Для документального оформления результатов этого этапа декомпозиции можно использовать UML-диаграмму пакетов (Package Diagram), в которой множество локальных представлений будет соответствовать множеству поиме- нованных «пакетов», связанных между собой отношениями вложенности или зависимости. На следующем этапе проводится более детальная декомпозиция каждого локального представления (пакета), в результате разрабатываются локальные ER- модели, представляющие соответствующие пакеты в виде множества взаимосвя- занных сущностей. Для документального оформления концептуальных моделей используется ER-диаграмма — граф-схема специального вида, представляющая сущности (именованные узлы графа) и связи между ними (именованные дуги графа, помеченные специальными символами). Для отображения ER-диаграмм возможно также использование графической нотации UML-диаграмм классов: на этих диаграммах аналогом сущности является пассивный концептуальный класс, не содержащий методов и обозначаемый стереотипом entity. Завершающий этап объектной декомпозиции связан с объединением ло- кальных ER-моделей в единую модель. Основное содержание этого этапа — формальная унификация общих компонентов различных локальных моделей (исключение дубликатов сущностей, согласование имен подобных сущностей и состава их атрибутов, уточнение типов атрибутов, видов связей и пр.). Задача унификации локальных моделей наиболее актуальна для крупномасштабных проектов, в которых ER-модели локальных представлений могут разрабаты- ваться параллельно и независимо различными командами проектировщиков. 19 / 19 39 3.2. Сущности и атрибуты Сущность — это абстракция (информационная модель) реального объек- та предметной области, а атрибут сущности — абстракция одного из свойств (характеристик) моделируемого объекта. Множество всех атрибутов сущности должно полностью определять характеристики объекта, существенные в кон- тексте проектируемой АИС. Сущность представляет собой множество однотипных объектов, каждый из которых соответствует в ER-модели одному экземпляру сущности, а атрибут сущности представляет множество допустимых значений определенной харак- теристики моделируемого объекта. Для каждого экземпляра сущности опреде- лен соответствующий набор экземпляров атрибутов. ER-модель не допускает дублирования экземпляров сущности, что соответствует требованию однократ- ного хранения информации о каждом объекте в проектируемой базе данных. Описательные атрибуты сущностей представляют свойства моделируе- мых объектов, их значения предъявляются пользователям в качестве результа- та выполнения запроса к базе данных, которым производится выборка требуе- мых пользователю экземпляров сущности и визуализация (или иная, более сложная обработка) значений их свойств. Атрибуты другой категории предназначены для идентификации экзем- пляров сущностей,такие атрибуты называются идентифицирующими или клю- чевыми. Ключевые атрибуты (называемые также ключами), в отличие от описа- тельных, являются не результатом, а средством реализации запросов выборки экземпляров сущности, для которых значения ключей соответствуют заданным ограничениям. Роль ключей могут выполнять некоторые из описательных ат- рибутов, допускается также объединение нескольких атрибутов в один состав- ной ключ. Различают первичные ключи, обладающие свойством уникальности в пре- делах сущности и однозначно идентифицирующие каждый ее экземпляр, и вторичные ключи — идентификаторы групп экземпляров сущности. Первичные ключи В каждой сущности должен быть определен как минимум один первич- ный ключ, что гарантирует отсутствие дубликатов среди ее экземпляров. Если несколько атрибутов сущности объективно обладают свойством уникальности, один из них (как правило, самый экономичный) объявляется первичным клю- чом, а остальные получают статус «возможных первичных ключей», не теряя при этом свойства своей уникальности 4 Возможно и более радикальное решение — ни один из уникальных опи- сательных атрибутов сущности не получает статуса первичного ключа, а на эту 4 Требование «экономичности» первичных ключей обосновывается способом реализации свя- зей между сущностями в логической (реляционной) модели данных, предусматривающим со- здание дополнительных внешних ключей в подчиненных таблицах, в которые будут «копиро- ваться» значения первичных ключей связанных с ними главных таблиц. Физическая модель данных также требует экономичного формата представления первичных ключей для эффек- тивной реализации индексных структур, ускоряющих поиск информации в базах данных. 1 / 19 40 роль назначается дополнительный «искусственный» атрибут, не представляю- щий никаких свойств моделируемого сущностью объекта предметной области и используемый исключительно для идентификации экземпляров этой сущности. Поддержка уникальности первичных ключей обеспечивается сервером баз данных, в языке SQL имеются специальные типы ограничений целостности (unique и primary key) и специальные автоинкрементные типы данных для ис- кусственных ключей. Вторичные ключи Вторичные ключи обеспечивают возможность параметрического поиска экземпляров сущности, соответствующих заданным значениям ее атрибутов. Состав вторичных ключей сущностей определяется пользовательскими запро- сами к базе данных, требующими группировки экземпляров сущностей по определенным критериям, включающим соответствующие атрибуты. Рисунок 2.2 иллюстрирует классификацию атрибутов на примере сущно- сти Сотрудник. Все атрибуты сущности, за исключением атрибута Employee_ID, имеют статус описательных, так как представляют свойства со- трудников предприятия, существенные для системы кадрового учета. Рис. 2.2 Пример описания сущности ER-модели Описательные атрибуты Паспорт и ИНН обладают свойством уникально- сти, и каждый из них мог бы выполнять функции первичного ключа, но разра- ботчик ER-модели принял другое решение: эти атрибуты объявлены возмож- ными первичными ключами, а на роль первичного ключа назначен дополнитель- ный «искусственный» атрибут Employee_ID (его имя в обозначении подчеркну- то), который более экономичен, выполняет исключительно техническую функ- цию идентификации, не ассоциируется ни с одним из свойств сотрудника и ни- когда не будет «показан» конечным пользователям АИС. Атрибуты Пол и Год_рождения вместе образуют составной вторичный ключ, необходимость которого может быть обусловлена, например, требовани- ем ежегодного формирования справки о сотрудниках предприятия, подлежа- щих призыву на срочную воинскую службу. Наличие составного вторичного ключа (Дата_найма, Стаж) позволит формировать планы повышения квали- фикации молодых специалистов предприятия, а составной вторичный ключ (Год_Рождения, Дата_найма, Стаж) будет полезен при планировании профес- сиональной переподготовки сотрудников предпенсионного возраста. 2 / 19 41 По результатам анализа бизнес-процессов могут быть приняты и другие решения, связанные с определением вторичных ключей. Например, если в функции отдела кадров входит подбор персонала для выполнения работ с тяже- лыми условиями труда или производится ежегодная рассылка поздравлений с Международным женским днем 8 марта всем сотрудницам предприятия, то ат- рибут Пол также может получить статус вторичного ключа (в данном случае атомарного, а не составного). Информация о составе вторичных ключей всех сущностей ER-модели должна быть детально проработана и отражена в проектной документации, эта информация будет необходима разработчикам физической модели данных для принятия решений о создании индексов, ускоряющих поиск и группировку данных. 3.3. Связи между сущностями Связь в ER-модели — это абстракция некоторого семантического отно- шения между реальными объектами предметной области, существенная в кон- тексте проектируемой базы данных и обеспечивающая возможность навигаци- онного поиска, то есть поиска экземпляров одних сущностей по их связям с эк- земплярами других сущностей. Например, если в ER-модели подсистемы кадрового учета предприятия определены связи между сущностями Сотрудники — Отделы и Сотрудни- ки — Должности, то реализация этих связей позволит соответствующими за- просами к базе данных определить место работы и должность каждого «экзем- пляра» сотрудника, состав сотрудников каждого «экземпляра» отдела, а также штатное расписание отделов (за исключением вакантных должностей). Связи между сущностями — это именованные элементы ER-модели, их, как правило, именуют глаголами, кратко обозначающими отношения между связанными объектами. В рассмотренном выше примере связь Сотрудники — Отделы может быть названа «работает в», а связь Сотрудники — Должно- сти может получить имя «занимает». В процессе выявления и именования связей производится их классифика- ция: отнесение каждой связи к одному из видов связи, определение параметров арности и кратности связей, а также определение и именование описательных атрибутов связей (при их наличии). Наиболее общим видом связи между сущностями является связь ассоциа- ции, все остальные виды связи в определенном смысле являются ее частными случаями, выделяемыми в отдельные категории из-за специфических особенно- стей их последующей реализации в логической модели данных. Из других видов связи можно отметить связи, моделирующие иерархиче- ские отношения между объектами — это связь агрегации, представляющая от- ношения типа «целое — часть», и связь обобщения, используемая для описания иерархий наследования типа «общее — частное» («предок — потомок»). Для обозначения видов связей на ER-диаграмме соответствующие дуги граф-схемы 3 / 19 42 помечаются специальными символами (отличающимися в различных системах графической нотации ER-диаграмм). Арность связи определяется количеством сущностей, участвующих в свя- зи. В рассмотренном выше примере обе связи — бинарные. Примером тернар- ной связи может служить связь между тремя сущностями Клиент — Дого- вор — Услуга: каждый экземпляр этой связи содержит информацию об одном виде услуг, предоставляемом одному клиенту в рамках одного из заключенных с ним договоров. В тетрарной связи участвуют четыре сущности, в пентар- ной — пять, в общем случае связь может быть определена как n-арная, где n — количество сущностей, участвующих в связи. В реализации каждая связь между сущностями ER-модели представляется множеством своих экземпляров — n-арных кортежей, каждый из которых со- ставлен из n экземпляров сущностей, участвующих в связи. Количество экзем- пляров сущностей, участвующих в одном экземпляре связи, определяют крат- ность связи (называемую также степенью или порядком связи). Кратность связей определяется по результатам семантического анализа предметной области в соответствии с простыми правилами, приведенными ни- же, для случая бинарной связи. Если экземпляр одной сущности не может быть связан более чем с одним экземпляром связанной с ней другой сущности, то между этими сущностями определяется симметричная связь кратности «один-к-одному», обозначаемая на ER-диаграмме как «1:1», где «1» и «1» — параметры кратности соответ- ствующих концов ассоциации. Если экземпляр первой сущности может быть связан более чем с одним экземпляром второй сущности, а экземпляр второй сущности — не более чем с одним экземпляром первой, то между этими сущностями определяется асим- метричная связь кратности «один-ко-многим», направленная от первой сущ- ности ко второй и обозначаемая на ER-диаграмме как «1:M». Если такая связь на диаграмме направлена от второй сущности к первой, то она будет иметь кратность «многие-к-одному» и будет обозначена как «M:1». Если каждый экземпляр любой из связанных сущностей может быть свя- зан более чем с одним экземпляром другой сущности, то между этими сущно- стями определяется симметричная связь кратности «многие-ко-многим», обо- значаемая на ER-диаграмме как «M:N». В обозначениях параметров кратности концов ассоциации «1» следует трактовать как «не более одного, в том числе ноль», «M» и «N» — как «неопре- деленно много, в том числе ноль или один». Из этого, в частности, следует не- обязательность участия некоторых (в том числе и всех) экземпляров сущности в экземплярах связи, обозначенной на ER-диаграмме для этой сущности. Для более точного указания на ER-диаграмме параметров кратности кон- цов ассоциаций можно использовать следующие стандартизованные обозначе- ния: «n» (любое натуральное число) — строго равно n; «m ... n» — любое натуральное число в заданном диапазоне; «1 ...*» — не менее 1. 4 / 19 43 Приведенные ниже примеры иллюстрируют использование параметров кратности концов ассоциации для бинарной связи Сотрудники — Должности в ER-диаграмме модели системы кадрового учета. Пример 1. Если на предприятии запрещено штатное совместительство, кратность связи может быть определена как «M:1», но более строго — как «1 ...* : 0 ... 1», что подчеркивает тот факт, что хотя бы одну должность сотруд- ник занимать все-таки должен (иначе какой же он «сотрудник»?), и при этом допускается хранение информации о вакантных должностях, не занятых ни од- ним из сотрудников. Пример 2. Если штатное совместительство разрешено без ограничений, кратность данной ассоциации будет обозначена как «M:N» или, более точно, «1 ...* : 1 ...*». Пример 3. Если штатное совместительство сотрудников ограничено, например, тремя должностями, кратность данной ассоциации будет обозначена как «1 ...* : 1 ... 3». Пример 4. Если при формировании штатного расписания действуют ограничения «не более десяти сотрудников на одной должности» и «совме- стительство запрещено», то кратность соответствующей ассоциации будет обозначена как «0 ... 10 : 0 ... 1». В отличие от сущностей, связи могут не иметь собственных описательных атрибутов, но в случае их наличия они также должны быть включены в ER-мо- дель, поименованы и соответствующим образом обозначены на ER-диаграмме. Например, для связи Сотрудники — Должности в рассмотренном выше при- мере могут быть определены описательные атрибуты Доля_должностной_ставки, Дата_назначения и Номер_приказа, которые не представляют ни свойств со- трудников, ни свойств должностей — они характеризуют связь между этими сущностями. Примеры обозначений на ER-диаграммах сущностей и связей различных видов в различных системах графической нотации приведены на рисунках 2.3–2.7. ER-диаграмма, представленная на рисунке 2.3, изображена в стиле гра- фической нотации UML-диаграмм классов. Три класса-сущности, имена кото- рых помечены специальным стереотипом entity, моделируют справочники об- разовательных уровней, специальностей и форм обучения — они связаны с сущностью Groups, моделирующей группы студентов, отношениями ассоциа- ции кратности «1:М», а классы-сущности Groups и Students связаны отношени- ем агрегации (частный случай ассоциации) кратности «1:М». Кратность «1» («строго один») концов ассоциаций обозначает обязатель- ность связей со стороны сущностей-справочников: для каждой студенческой группы обязательно должна быть определена ее принадлежность строго одной специальности, одной форме обучения и одному образовательному уровню. Кратность «*» концов ассоциации («неопределенно много, в том числе и ноль») обозначает необязательность связей со стороны сущности Groups: в базе данных могут быть представлены такие образовательные уровни (например, «начальное профессиональное обучение» или «адъюнктура») и такие формы 5 / 19 44 обучения (например, «экстернат» или «индивидуальное репетиторство»), по которым не сформировано ни одной студенческой группы. Рис. 2.3 Фрагмент ER-диаграммы модели «Контингент студентов» Кратность «1 ... *» концов ассоциации («неопределенно много, но не менее единицы») обозначает обязательность соответствующей связи: по любой специ- альности должна быть сформирована хотя бы одна студенческая группа, вклю- чающая хотя бы одного студента. Заметим, что кратность конца агрегации со стороны сущности Students правильнее было бы обозначить не «1 ... *», а, например, «10 ... 30», что опре- деляло бы минимально и максимально допустимое количество студентов в группе. На рисунке 2.4 представлены два варианта изображения бинарной связи кратности «M:N» на фрагменте ER-диаграммы системы кадрового учета. На рисунке 2.5 представлена ER-диаграмма, моделирующая структуру контрольных заданий, обеспечивающих систему тестирования студентов по простейшей схеме — «выбор правильного ответа из нескольких предложен- ных». Сущность Type_of_Test — это модель классификатора тестов (например, «пробный», «контрольный» и «аттестационный»), а экземпляры сущности Them_plan представляют множество разделов тематического плана учебной дисциплины. Для каждой темы может быть сформировано множество тестов различных типов, при этом тест включает множество заданий (Task), каждое из которых со- стоит из строго одного вопроса (Question) и множества возможных ответов (Ansver), некоторые из которых являются правильными (описательный атрибут экземпляра связи заданий с правильными ответами получит значение «is_true»). 6 / 19 45 Рис. 2.4 Два способа обозначений связей кратности «M:N» Рис. 2.5 Фрагмент ER-диаграммы модели «Тестирование» На рисунке 2.6 изображен фрагмент ER-диаграммы предметной области «Библиотечный каталог» в нотации П. Чена. Объекты хранения в библиотечном фонде представлены двумя категория- ми: Книги и Журналы, что отображено на ER-диаграмме соответствующими связями вида «обобщение», на которых стрелка направлена от сущности- «потомка» к сущности-«предку». Все атрибуты и связи сущности-«предка» Библ. фонд наследуются сущ- ностями-«потомками» Книги и Журналы, при этом каждый из «потомков» мо- 7 / 19 46 жет иметь собственные атрибуты и участвовать в разных связях с другими сущностями. Рис. 2.6 Пример использования унарных связей и связей вида «обобщение» Для сущности Жанры определена унарная связь кратности «1:М» — это связь между различными экземплярами этой сущности, позволяющая постро- ить дерево жанров, в котором один жанр-«предок» может быть связан с не- определенно большим количеством жанров-«потомков», каждый из которых может выступать в роли «предка» по отношению к другим экземплярам этой сущности. 3.4. Слабые сущности Слабой называют сущность, экземпляры которой не могут существовать вне связей с экземплярами других (сильных) сущностей. Как правило, слабая сущность не является моделью каких-либо реальных объектов предметной об- ласти, а «заменяет» собой на ER-диаграмме связь кратности «M:N» между сильными сущностями, представляющими реальные объекты. В результате такой «замены» слабая сущность оказывается связанной с сильными сущностями отношениями кратности «M:1» и при этом наследует имя «замененной» связи и все ее описательные атрибуты (при их наличии). Иными словами, каждый экземпляр n-арной связи кратности «M:N» между сильными сущностями заменяется n экземплярами бинарной связи кратности «N:1» между слабой сущностью и сильными сущностями, участвовавшими в исходной n-арной связи. Слабая сущность является «слабой» лишь в отношениях с теми n сущно- стями, связь между которыми она заменила, во всех остальных отношениях она подобна другим сущностям ER-модели. Слабая сущность должна иметь соб- 8 / 19 47 ственный первичный ключ и может участвовать в связях с другими слабыми сущностями в качестве сильной сущности (рис. 2.7). Рис. 2.7 Пример использования «слабых сущностей» При разработке ER-модели для каждого атрибута сущности или связи до- полнительно должны быть определенны такие их параметры, как предполагае- мый тип данных и множество допустимых значений, а в необходимых случаях и другие ограничения, которые могут оказаться полезными разработчикам базы данных на последующих этапах ее проектирования и программной реализации. 3.5. Пример разработки ER-модели Для иллюстрации содержания и результатов выполнения начальных ста- дий проекта базы данных рассмотрим подсистему учета работы с клиентами ин- тернет-провайдера, которая уже использовалась в качестве примера при обсуж- дении концепций иерархической (п. 2.3.1) и сетевой (п. 2.3.2) моделей данных. Техническое задание — первая стадия проекта АИС. На этой стадии проекта проводится анализ бизнес-процессов интернет- провайдера, по результатам которого определяются основные пользовательские роли и проводится функциональная декомпозиция проектируемой АИС. Результаты проведенной функциональной декомпозиции представлены на укрупненной UseCase-диаграмме, приведенной на рисунке 2.8. Внешними пользователями подсистемы являются Гость и Клиент, кото- рым доступен сервис просмотра тарифных планов, а Клиенту и дополнительно сервисы управления договорами и заявками на обслуживание. Внутренние пользователи — это Руководитель, Менеджер по работе с клиентами, сотрудники Call-центра, а также Руководитель и Сотрудники от- дела технической поддержки. 9 / 19 48 Рис. 2.8 UseCase-диаграмма подсистемы учета работы с клиентами интернет-провайдера Руководитель формирует и корректирует тарифные планы. Сотрудники Call-центра принимают, оформляют и регистрируют посту- пающие от клиентов заявки на обслуживание. Руководитель отдела технической поддержки анализирует поступив- шие заявки, распределяет работы по их исполнению между своими сотрудни- ками и контролирует выполнение работ. Сотрудникам этого отдела доступны сервисы просмотра заявок и реги- страции выполненных ими работ. Эскизный проект — третья стадия проекта базы данных. На этой стадии проекта проводится объектная (структурная) декомпози- ция предметной области, в результате которой формируется ее информацион- ная ER-модель. ER-модель представляет проектируемую базу данных на концептуальном уровне как множество взаимосвязанных сущностей, атрибуты которых полно и адекватно описывают свойства моделируемых объектов, а связи между сущно- стями обеспечивают выполнение системой требований к ее функциональным характеристикам, выработанным на стадии технического задания. При выполнении крупномасштабных проектов рекомендуется проводить структурную декомпозицию системы в три этапа, последовательно увеличивая степень детализации рассмотрения ее свойств. По завершении каждого этапа производится контроль информативности полученного варианта концептуаль- ной модели. 10 / 19 49 Следуя этой рекомендации и считая (весьма условно) наш учебный про- ект «крупномасштабным», получим следующие результаты проведения струк- турной декомпозиции, иллюстрируемые рисунками 2.9–2.13. На первом этапе по результатам анализа UseCase-модели АИС (рис. 2.8) произведена декомпозиция проектируемой базы данных на три взаимосвязан- ных локальных представления (или в терминах языка UML — на три пакета): Тарифные планы, Договоры с клиентами и Обработка заявок (рис. 2.9). Пакет Тарифные планы обеспечивает информационную поддержку сер- висов, востребованных пользовательскими ролями Руководитель, Гость и Клиент, для формирования, редактирования и просмотра тарифных планов. Пакет включает подчиненный ему пакет Услуги, в который, в свою очередь, включен пакет Тарифы. Такая структура пакета Тарифные планы позволит формировать перечень базовых услуг, оказываемых интернет-провайдером своим клиентам, включать услуги в различные тарифные планы и определять цены услуг (возможно, отличающиеся для различных тарифных планов). Пакет Договоры с клиентами поддерживает функции управления кли- ентской базой, используемые ролями Менеджер и Клиент. Подчиненный пакет Договоры содержит информацию о заключенных с клиентами договорах. Для формирования предмета и условий договоров этот пакет использует данные па- кетов Услуги и Тарифы, подчиненных пакету Тарифные планы, на что указы- вают соответствующие отношения зависимости (Use) между пакетами. Рис. 2.9 UML-диаграмма пакетов подсистемы учета работы с клиентами Пакет Обработка заявок обеспечивает регистрацию заявок на обслужива- ние, поступающих от клиентов, а также планирование и учет выполнения работ, связанных с исполнением заявок. Эти сервисы используются клиентами и со- трудниками Call-центра, а также сотрудниками отдела технической поддержки. 11 / 19 50 Подчиненный пакет Заявки связан отношением зависимости типа Create с пакетом Клиенты, что отражает факт подачи заявки клиентом и потребует установления связей между соответствующими сущностями при разработке ER-модели. Этот же пакет Заявки связан отношением зависимости Use с паке- том Договоры, что обеспечит доступ к содержанию соответствующего договора как на этапе регистрации заявки, так и при планировании работ по ее исполне- нию. На втором этапе структурной декомпозиции были разработаны локаль- ные ER-модели для каждого из трех пакетов, сформированных на предыдущем этапе. ER-модель пакета Тарифные планы (рис. 2.10) содержит классификатор услуг, представленный сущностями Услуги и Категории, связанными отноше- нием кратности «M:1». Такое решение даст возможность гибкого управления классификатором услуг в процессе эксплуатации БД без внесения изменений в ее структуру. Рис. 2.10 ER-диаграмма пакета Тарифные планы Изменение состава экземпляров и связей между экземплярами этих двух сущностей позволит неограниченно расширять (или сужать до единицы) как перечень категорий оказываемых услуг, так и перечень услуг каждой катего- рии. Например, прайс-лист одного интернет-провайдера может включать та- кие категории услуг, как «Цифровое телевидение», «Доступ в Интернет» и «Телефония» (которая может включать услуги «Мобильная связь» и «IP-теле- фония»). У другого провайдера все может быть иначе. Экземпляры сущности Параметры представляют перечень наименова- ний различных параметров услуг всех категорий с указанием единиц измерения каждого параметра. Например, параметром услуги «Просмотр», принадлежа- щей категории «Цифровое телевидение», может быть «Количество каналов», 12 / 19 51 а параметрами услуги «Мобильный Интернет» категории «Доступ в Интер- нет» — «Скорость передачи данных» и «Ограничение объема передаваемых данных». Связь между сущностями Параметры и Категории позволяет опреде- лить состав параметров, актуальных для каждой категории услуг. Кратность M:N, заданная для этой связи, подтверждает тот факт, что услуги одной катего- рии могут иметь много параметров, и один параметр может быть актуальным для нескольких категорий услуг. Заметим, что в такой модели все услуги, отне- сенные к одной категории, должны иметь единый набор параметров. Сущность Тарифные планы — это, по существу, перечень наименований пакетов услуг, предоставляемых интернет-провайдером своим клиентам, а каж- дый экземпляр слабой сущности Тарифы представляет одну из услуг в составе одного из таких «пакетов». Заметим, что атрибут Цена представляет свойство Тарифа, а не Услуги, из чего следует, что одинаковые услуги в различных тарифных планах могут предоставляться по разным ценам. Связь кратности «M:N» между сущностями Тарифы и Параметры опре- деляет значения параметров услуг, предоставляемых по каждому тарифному плану. Один и тот же параметр одной и той же услуги может иметь различные значения в разных тарифных планах, что, естественно, может повлиять на цену этой услуги. Например, значения параметра «Ограничение объема передавае- мых данных» услуги «Мобильный Интернет» могут существенно отличаться в тарифных планах «Бюджетный» и «Безлимитный». Основная цель проведения детального анализа результатов концептуаль- ного моделирования — оценка информативности и адекватности разработан- ных локальных ER-моделей. Пример такого анализа для пакета Тарифные пла- ны приведен выше, оценку качества ER-моделей для двух остальных пакетов (рис. 2.11 и 2.12) читателю предлагается провести самостоятельно. Рис. 2.11 ER-диаграмма пакета Договоры с клиентами 13 / 19 52 Рис. 2.12 ER-диаграмма пакета Обработка заявок На третьем этапе, завершающем стадию эскизного проекта базы дан- ных, все три локальные модели были объединены в единую концептуальную ER-модель. В процессе такого объединения был уточнен состав сущностей мо- дели, унифицированы имена и типы данных их атрибутов, определены ключе- вые атрибуты сущностей, имена и кратности связей между ними, атрибуты свя- зей. Результат объединения локальных ER-моделей в единую ER-модель предметной области проектируемой АИС представлен на рисунке 2.13. Контрольные вопросы и задания 1. Определите понятие «связь» как элемент ER-модели. Как классифици- руются связи между сущностями? В каких случаях целесообразно использовать связи видов «ассоциация», «агрегация» и «обобщение»? 2. Определите понятие «кратность связи». Определите кратности связей между сущностями Test, Task, Question и Answer (рис. 2.5). 3. Определите понятие «слабая сущность». Какую роль выполняют сущ- ности Предмет договора и Услуги_Тарифных_Планов (рис. 2.13)? 4. На рисунке 2.10 приведена ER-диаграмма пакета Тарифные планы. Пере- стройте эту диаграмму с использованием связей вида «Обобщение» для условий, когда категорий услуг всегда ровно три, а параметры услуг одной категории не могут входить в состав параметров услуг других категорий. 14 / 19 53 Рис. 2.13 Объединенная ER-диаграмма 15 / 19 |