Диго С.М. Базы данных. Часть 1

Подождите немного. Документ загружается.

Концептуальное проектирование

Глава 2. КОНЦЕПТУАЛЬНОЕ ПРОЕКТИРОВАНИЕ

Концептуальное проектирование является центральной частью, ядром всего про-

цесса проектирования баз данных. Подходы к концептуальному проектированию, изла-

гаемые в разных литературных источниках и реализованные в разнообразных CASE-

системах, отличаются друг от друга. Многие из подходов имеют существенные недостат-

ки, что не позволяет рекомендовать именно их как основные. В связи с этим в данной гла-

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

Так как в настоящее время CASE-систем достаточно много, то неизвестно, с какой

именно из систем придется проектировщику столкнуться на практике. Поэтому в данной гла-

ве даны некоторые критерии, по которым следует сравнивать CASE-системы, и приведены

обобщенные рекомендации по построению ER-моделей в зависимости от доступных изобра-

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

В качестве примеров рассмотрен процесс концептуального моделирования в среде

Design / IDEF и ERWin. Эти системы достаточно широко известны, приемлемы по стои-

мости и, в силу этого, широко используются в учебном процессе. При освоении курса «Ба-

зы данных» можно ознакомиться только с тем разделом, который соответствует CASE-

средству, которое будет реально использоваться. Если предполагается использовать

CASE-систему, которая подробно не освещена в учебнике, то следует обращаться к доку-

ментации по данной системе и другим доступным источникам, а по методике построения

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

2.1. ОБЩИЕ СВЕДЕНИЯ О МОДЕЛИРОВАНИИ ПРЕДМЕТНОЙ ОБЛАСТИ

Уточнение понятия концептуальной модели

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

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

зано выше, часть реального мира, представляющая интерес для данного исследования, на-

зывается предметной областью (ПО). Для того чтобы база данных адекватно отражала

предметную область, проектировщик должен хорошо представлять себе все нюансы, при-

сущие ей, и уметь отобразить их в базе данных.

Предметная область должна быть предварительно описана. Для этого, в принципе,

может использоваться и естественный язык, но его применение имеет много недостатков,

основными из которых являются громоздкость описания и неоднозначность его трактов-

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

всего – графические) языковые средства.

Формализованное описание предметной области будем называть ее концептуаль-

ной моделью (КМ). Предметные области могут быть различными, и для их моделирования

могут потребоваться специфические средства, соответствующие особенностям этих об-

ластей. Мы в данном учебнике будем ориентироваться, в основном, на экономико-

организационные системы. Хотя описываемые далее подходы к проектированию являются

более универсальными и могут быть использованы и в других предметных областях.

Моделирование предметных областей выполняется с разными целями, например,

для реинжиниринга бизнес-процессов, для прогнозирования развития предметной облас-

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

средства и методы моделирования при этом будут различаться. Естественно, что в данном

учебном пособии мы остановимся только на тех средствах и методах моделирования, ко-

торые находят наибольшее использование при проектировании баз данных.

Концептуальное проектирование

Как было отмечено в главе 1 данного пособия, существует большое разнообразие видов

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

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

данных, то основное внимание будет уделено проектированию именно таких систем.

Рис. 2.1. Стадия инфологического моделирования – исходная и

результатная информация

Изучение предметной области складывается из непосредственного наблюдения

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

интервьюирования участников этих процессов (рис. 2.1). Так как описание инфологиче-

ской модели выполняется на специализированном языке, то необходимо владение этим

языком. Следует обратить внимание на то, что возможности языка описания ИМЛ оказы-

вают влияние на методику построения модели с использованием данных языковых

средств. Построение концептуальной модели может выполняться как «вручную», так и с

использованием автоматизированных средств проектирования. Средства автоматизации

проектирования отличаются как нотациями используемых языковых средств, так и алго-

ритмами преобразования концептуальной модели в модели базы данных. Это в свою оче-

редь скажется на методике построения модели в их среде.

Основные компоненты концептуальной модели

Основными компонентами концептуальной модели ПО являются (рис. 2.2):

• описание объектов ПО и связей между ними;

• описание информационных потребностей пользователей;

• описание существующей информационной системы (документы, документообо-

рот, при наличии автоматизированной информационной системы – ее описание);

• описание алгоритмических зависимостей показателей;

• описание ограничений целостности;

• описание функциональной структуры системы, для которой создается АИС;

• требования к ИС и существующие ограничения.

Концептуальное проектирование

Концептуальная модель

Описание объектов и Описание информационных Алгоритмические Требования и

связей между ними потребностей пользователей связи показателей ограничения

Лингвистические Ограничения Описание Описание функциональной

отношения целостности существующей ИС структуры системы

Рис. 2.2. Компоненты концептуальной модели

Далее мы более подробно остановимся на первой из перечисленных компонент, так

как именно она оказывает наибольшее влияние на проектирование структуры базы дан-

ных. Чаще всего описание объектов ПО и связей между ними представляется в виде так

называемых ER-моделей (или ER-диаграмм)

Требования, предъявляемые к концептуальной модели

К концептуальной модели предъявляются следующие требования:

• адекватное отображение предметной области (язык для представления модели

должен обладать достаточными выразительными возможностями для отобра-

жения явлений, имеющих место в предметной области, а сама модель должна

содержать всю необходимую и достаточную информацию для дальнейшего

проектирования системы);

• непротиворечивость (модель отражает взгляды и потребности всех пользователей

системы, а также обычно является результатом работы многих специалистов, по-

этому целостное описание ПО должно быть проверено на непротиворечивость);

• однозначная трактовка модели всеми ее пользователями (обеспечивается фор-

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

создания ИС);

• легкость восприятия разными категориями пользователей (обеспечивается вы-

бором соответствующего языка моделирования);

• конечность модели (несмотря на то, что реальный мир, отображаемый в КМ,

является по своей природе бесконечным, инфологическая модель является ко-

нечной, что обеспечивается четким ограничением предметной области);

• легкость модификации (в концептуальную модель по разным причинам часто

приходится вводить новые объекты или модифицировать существующие; ИЛМ

должна в связи с этим обладать свойством легкой расширяемости, обеспечи-

вающим ввод новых данных без изменения раннее определенных. То же самое

можно сказать и об удалении и корректировке данных);

• возможность композиции и декомпозиции модели (в связи с большой размерно-

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

ее композиции и декомпозиции).

ER – Entity-Relationship – Сущность-отношение.

Концептуальное проектирование

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

меним как при ручном, так и при автоматизированном проектировании информационных

систем. Последние предъявляет к языку дополнительные требования, а именно, он должен:

• быть вычисляемым, то есть восприниматься и обрабатываться ЭВМ;

• использовать «дружелюбные» пользователю интерфейсы, в частности, графические;

• быть независимым от оборудования и других ресурсов, которые подвержены

частым изменениям;

• использовать средства тестирования КМ, а также иметь аппарат для указания

того, что спецификация завершена и по ней может быть выполнена генерация

структур баз данных.

При автоматизированном проектировании все изменения, внесенные в КМ, должны

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

банка данных.

Желательно, чтобы КМ строили специалисты, работающие в предметной области,

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

Если в силу определенных причин это невозможно обеспечить, то необходимо, чтобы

первые могли хотя бы проверить сделанное другим специалистом описание, чтобы убе-

диться, что специфика предметной области воспринята и отображена правильно.

Концептуальная модель является средством коммуникации разнообразных коллек-

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

дирует со словарной системой и другими компонентами банка данных.

Преимущества использования ER-моделирования

ER-модель представляет собой графическое описание предметной области в тер-

минах «объект-свойство-связь». ER-модель является одним из элементов концептуальной

модели. Использование ER-моделирования (и, особенно, в сочетании с автоматизирован-

ными средствами проектирования – CASE-средствами) дает много преимуществ:

• предписывая определенную методологию моделирования, делает анализ пред-

метной области более целенаправленным и конкретным;

• является удобным средством документирования проекта;

• позволяет вести проектирование АИС без привязки к конкретной целевой

СУБД и осуществлять выбор последней в любой момент времени (чем ближе к

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

При использовании ER-моделирования в составе CASE-средств появляются допол-

нительные преимущества:

• снижаются требования к знанию деталей языков описания данных (DDL) и диа-

лектов SQL конкретных СУБД;

• при смене используемой СУБД не надо проводить проектирование заново; сле-

дует только осуществить шаг по переводу ER-модели в целевую (если выбран-

ная Вами целевая СУБД поддерживается данным CASE-средством, то такой пе-

реход вообще будет выполнен автоматически);

• наличие в CASE-средстве возможности «обратного проектирования» (т.е. полу-

чения ER-диаграммы по имеющимся описаниям данных) позволяет использо-

вать существовавшие ранее наработки для «реинжиниринга» системы;

• указание связи объектов в ER-модели, и соответствующая миграция ключа при

преобразовании этой модели в целевую, позволяет не только задавать контроль це-

лостности связи при ведении БД, но и автоматически обеспечивает согласованное

описание схемы (внешний ключ мигрирует в связанное отношение; при этом имя,

тип и длина соответствующего атрибута повторяются в зависимой сущности);

Концептуальное проектирование

• сокращается время проектирования системы;

• появляется возможность автоматизированного тестирования проекта на всех

этапах проектирования;

• повышается качество документирования проекта;

• мощные современные CASE-средства позволяют вести коллективную разработку

проекта.

2.2. ОПИСАНИЕ БАЗОВОЙ ER-МОДЕЛИ

Существует большое число нотаций (изобразительных средств) и методик построе-

ния ER-моделей. Ниже мы рассмотрим методику построения ER-модели, предлагаемую

автором данного пособия. Будем называть эту методику ER-моделирования базовой. С не-

которыми другими методиками можно познакомиться в п 2.3, а также по литературным

источникам [3, 5, 7] или по документации по CASE-средствам.

Понятие «объект» и «класс объектов»

В предметной области имеется множество разнообразных объектов. Объект – поня-

тие очень широкое. Его трудно точно определить. Обычно под объектом понимают некую

сущность (реальную или абстрактную), о которой собирается какая-то информация. Объ-

екты группируются в классы. Классом объектов называют совокупность объектов, обла-

дающих одинаковым набором свойств. Например, для объектов класса «СТУДЕНТ» таким

набором свойств являются: «ГОД _ РОЖДЕНИЯ», «ПОЛ» и другие.

Объекты могут быть реальными, как названный выше объект «СТУДЕНТ», и абст-

рактными, как, например, «ПРЕДМЕТЫ», которые изучают студенты.

ER-модель строится на уровне классов объектов, а не отдельных экземпляров объектов.

Каждому классу объектов в ER-модели присваивается уникальное имя. Именем

класса объекта является грамматический оборот существительного (существительное, у

которого могут быть прилагательные и предлоги). Если имя состоит из нескольких слов,

то желательно, чтобы первым стояло существительное. Существительное должно упот-

ребляться в единственном, а не во множественном числе (например, «ДИСЦИПЛИНА _

ИЗУЧАЕМАЯ»). Если в предметной области традиционно используются разные имена

для обозначения какого-либо класса объектов (т.е. имеет место синонимия), то все они

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

основное, и только оно должно в дальнейшем использоваться в ER-модели. Помимо име-

ни класса объектов в ER-модели может использоваться его короткое кодовое обозначение;

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

будет использоваться при описании структуры базы данных.

При построении ER-модели желательно дать словесную интерпретацию каждой

сущности, особенно, если возможно неоднозначное толкование понятия.

Вместо термина «объект» часто используется термин «сущность». В дальнейшем

мы будем рассматривать эти термины как синонимы.

При отражении в информационной системе каждый объект (имеется в виду уже эк-

земпляр объекта, а не весь класс) представляется своим именем, которое называет конкрет-

ный объект и отличает один объект от другого. Чтобы выполнять свою роль, имя должно

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

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

естественное имя объекта является не уникальным. Уникальное имя объекта будем называть

идентификатором. Каждый объект должен иметь, по крайней мере, один идентификатор.

Концептуальное проектирование

Каждый объект обладает определенным набором свойств – характеристик, описы-

вающих состояние каждой сущности. Набор (перечень) свойств для всех объектов данного

класса будет одинаковым, но конкретные значения этих характеристик и, особенно, соче-

тание этих значений, будут отличаться от объекта к объекту, что, собственно, и отличает

один экземпляр объекта от другого.

Может случиться, что в данной предметной области свойства объекта не представ-

ляют для нас интереса. В связи с этим в ER-модели возможно наличие объектов, не

имеющих свойств и представленных только своими идентификаторами.

Разновидности объектов

Различают несколько разновидностей объектов. Прежде всего, это простые и

сложные объекты. Объект называется простым, если он рассматривается в данном иссле-

довании как неделимый.

Сложный объект представляет собой объединение других объектов, простых или

сложных, также отображаемых в информационной системе. Понятие «простой» и «слож-

ный» объект является относительным. В одном рассмотрении объект может считаться

простым, а в другом этот же объект может рассматриваться как сложный. Так, например,

объект «АУДИТОРИЯ» в случае, если АИС строится только для управления учебным

процессом, будет рассматриваться как простой. Если же АИС будет включать подсистемы

для служб энергетика, материально-технического снабжения и др., то «АУДИТОРИЯ» бу-

дет рассматриваться как составной объект.

Выделяют несколько разновидностей сложных объектов: составные, обобщенные и

агрегированные объекты.

Составной объект соответствует отображению отношения «целое-часть». Приме-

рами составных объектов являются УЗЕЛ – ДЕТАЛИ, КЛАСС – УЧЕНИКИ и т.п.

Обобщенный объект отражает наличие связи «род-вид» между объектами пред-

метной области. Например, объекты «СТУДЕНТ», «ШКОЛЬНИК», «АСПИРАНТ»,

«УЧАЩИЙСЯ ТЕХНИКУМА» образуют обобщенный объект «УЧАЩИЙСЯ». Объекты,

составляющие обобщенный объект, называются его категориями.

Как «родовой» объект, так и «видовые» объекты могут обладать определенным на-

бором свойств. Причем наблюдается так называемое наследование свойств, т.е. «видовой»

объект обладает всеми теми свойствами, которыми обладает «родовой» объект, плюс

свойствами, присущими только объектам этого вида.

Определение родовидовых связей означает классификацию объектов предметной

области по тем или иным признакам. Естественно, что классификация может быть мно-

гоуровневой.

Агрегированные объекты соответствуют обычно какому-либо процессу, в кото-

рый оказываются «вовлеченными» другие объекты. Например, агрегированный объект

«ПОСТАВКА» объединяет в себе объекты «ПОСТАВЩИК», «ПОТРЕБИТЕЛЬ», а также

саму поставляемую «ПРОДУКЦИЮ». Своеобразным объектом является «ДАТА _

ПОСТАВКИ». Агрегированный объект может, так же как и простой объект, иметь харак-

теризующие его свойства. В рассматриваемом примере таким свойством может быть

«РАЗМЕР _ ПОСТАВКИ». Агрегированные объекты обычно называются отглагольными

существительными.

Концептуальное проектирование

Изображение простого объекта

Для графического обозначения простого объекта будем использовать прямоуголь-

ник, ограниченный сплошной линией. Название класса объекта пишется над ним. Внутри

прямоугольника записывается название атрибута, именующего объект (рис. 2.3). Если у

объекта имеется несколько имен, то для каждого из них выделяется отдельный «сектор» в

этом прямоугольнике.

Рис. 2.3. Изображение объекта

Если какое-либо имя объекта не является уникальным, будем использовать букву

«н» рядом с таким именем (рис. 2.4).

Личность

ФИО (н)

Табельный номер

Рис. 2.4. Пример изображения объекта с несколькими идентифицирующими атрибутами

Встречаются случаи, когда идентификация одних объектов зависит от идентифика-

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

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

«НОМЕР _ ЦЕХА*НОМЕР _ УЧАСТКА». Назовем подобные объекты (в нашем примере

это объект «УЧАСТОК») зависимыми от идентификации сущностями. Для отображения

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

около конца, прилегающего к зависимому объекту (рис. 2.5, 2.6).

Рис. 2.5. Изображение зависимой по идентификации сущности

Если не использовать специального обозначения для указания зависимости по

идентификации, то (для нашего примера) для объекта «УЧАСТОК» следует указать со-

ставной идентификатор «НОМЕР_ЦЕХА*НОМЕР_УЧАСТКА», при этом его надо указать

в одном секторе прямоугольника, а не выделять несколько секторов, как в случае наличия

у объекта несколько имен.

ЦЕХ УЧАСТОК

Номер цеха Номер участка

Рис. 2.6. Пример изображения зависимой по идентификации сущности

Концептуальное проектирование

Описание свойств объекта. Разновидности свойств

Как указывалось выше, класс объектов представляет собой совокупность объектов,

обладающих одинаковым набором свойств. При описании предметной области надо изо-

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

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

пунктирной линией.

Рис. 2.7. Изображение объекта и его свойств (условные обозначения)

Связь между объектом и характеризующим его свойством изображается в виде ли-

нии, соединяющей их обозначения. Характер связи между объектом и его свойством мо-

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

в каждый момент времени. Например, каждый человек может иметь только одну «ДАТУ _

РОЖДЕНИЯ» или «СТАЖ _ РАБОТЫ». Назовем такие свойства единичными. Для других

свойств возможно существование одновременно нескольких их значений у одного и того

же объекта (например, свойство «ИНОСТРАННЫЙ ЯЗЫК» у объекта «СОТРУДНИК» в

случае, если «СОТРУДНИК» может владеть несколькими иностранными языками). Такое

свойство будем называть множественным. При изображении связи между объектом и его

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

ственных свойств – двойную стрелку на конце линии, соединяющей объект с данным

свойством (рис. 2.7, 2.8).

Концептуальное проектирование

Личность

ФИО (н)

Табельный номер

С Дата

рождения

Д Стаж

работы

Д Иностранный

язык

Рис. 2.8. Пример изображения единичных и множественных

динамических и статических свойств

Значения некоторых свойств не может измениться с течением времени. Назовем такие

свойства статическими, а те свойства, значения которых может изменяться со временем, бу-

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

букву «Д», а статических – «С» над соответствующей линией. Так, упомянутое выше свойст-

во ДАТА_РОЖДЕНИЯ будет являться статическим, а «СТАЖ» – динамическим.

Другой характеристикой связи между объектом и его свойством является признак

того, присутствует ли это свойство у всех объектов данного класса, либо оно может отсут-

ствовать у некоторых из объектов. Например, для отдельных служащих может иметь ме-

сто свойство «УЧЕНАЯ_СТЕПЕНЬ», а другие объекты этого класса могут не обладать

указанным свойством. Назовем свойства, присутствующие не у всех объектов данного

класса, условными. При изображении связи условного свойства с объектом будем исполь-

зовать пунктирную линию, а в случае, если свойство определено для всех экземпляров

объектов данного класса, – сплошную (рис. 2.9).

Личность

ФИО (н)

Табельный номер

......

...

Д Ученая

степень

Рис. 2.9. Пример изображения условного свойства

Правильность отображения предметной области в ER-модель будет зависеть от того,

какие ситуации возможны в данной предметной области, а какие – нет. Так, если в вузе со-

трудник может занимать несколько должностей одновременно, например, быть одновре-

менно ректором и заведующим кафедрой, то фрагмент ER-модели будет выглядеть так, как

изображено на рис. 2.10 а), а если внутривузовское совместительство не разрешено, – то как

изображено на рис. 2.10 б).

Концептуальное проектирование

Рис. 2.10. Варианты изображения

(в зависимости от особенностей предметной области)

Иногда в ER-модели бывает полезно ввести понятие «составного свойства». При-

мером такого свойства могут быть «АДРЕС», состоящий из «ГОРОДА», «УЛИЦЫ»,

«ДОМА» и «КВАРТИРЫ». Будем использовать для обозначения составного свойства

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

ставляющих его элементов (рис. 2.7, 2.11).

Личность

ФИО (н)

Табельный номер

......

...

страна

адрес населенный пункт

улица

...

Рис. 2.11. Пример изображения составного свойства

При проектировании БД определяются тип и длина полей. Для того, чтобы иметь

возможность правильно выбрать эти характеристики, необходимо иметь соответствую-

щую информацию о типе представления атрибута в «немашинной» системе и требования /

пожелания пользователей об их отображении в автоматизированной системе, может быть

даже с предпочтениями. Например, предположим, что желательно было бы хранить в БД

изображение. Если это невозможно в целевой СУБД, то:

• поле, соответствующее данному атрибуту, не вводить;

• связать с системой, которая может хранить рисунок;

• заменить рисунок описанием.

Например, в «Листке по учету кадров» хранится фотография. Если есть возмож-

ность ее сканирования и связи соответствующего файла с записями БД, то сделать это, ес-

ли нет – то ничего, соответствующего фотографии, не хранить в ИС.

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

на (а лучше не только максимальная, но и минимальная и «средневзвешенная»).

Чтобы не загромождать ER-модель, такие характеристики рекомендуется отобра-

жать в репозитории (в каталоге реквизитов).