Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 24)

Несмотря на имеющиеся различия в нотациях и реализации, мо­делирование в Design/IDEF и ERWin имеет много общего. Поэтому при построении концептуальной модели в ERWin за основу следует взять методологию моделирования, изложенную в разд. 2.4.2. В эту методологию должны быть внесены некоторые коррективы. Особен­ности в методологии при проектировании в среде ERWin и причины, обусловливающие их, изложены ниже.

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

2. В ERWin есть возможность указывать свойство «только физи­ческая/только логическая» для сущности в целом и любого из ее ат­рибутов. Эту возможность можно использовать в процессе проекти­рования следующим образом:

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

• отметить те сущности/атрибуты, которые не требуется хранить в базе данных, признаком Logical Only, чтобы они не попадали в фи­зическую модель.

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

В ERWin имеется целый ряд возможностей, которые отсутствуют в Design/IDEF.

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

Задание ограничений целостности является неотъемлемым эле­ментом создания концептуальной модели. ERWin позволяет описы­вать ограничения целостности при описании атрибутов, а также при описании связей между объектами. Более подробно задание ограни­чений целостности изложено в главе 4.

На это следует обратить внимание

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

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

• Концептуальная модель используется разными категориями про­ектировщиков ИС и заказчиков. Поэтому и те, и другие должны по­нимать основы концептуального моделирования.

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

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

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

Контрольные вопросы

1. Что называется предметной областью?

2. Что называется концептуальной моделью? Для каких целей она служит?

3. Перечислите основные компоненты концептуальной модели.

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

5. Какие преимущества дает использование ER-моделирования при создании БД?

6. Что называется классом объектов?

7. Какие разновидности объектов выделяются в базовой ER-модели? Какие графические обозначения используются для изображения каждого вида объектов?

8. Приведите примеры из любых предметных областей для каждой разновидности объектов.

9. Какие разновидности свойств объектов выделяются в базовой ER-модели? Какие графические обозначения используются для изображения каждого вида свойств?

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

11. Что называется зависимыми от идентификации сущностями?

12. Что следует выделять в качестве самостоятельного объекта в ER-модели?

13. Какие интегральные характеристики класса объектов обычно фик­сируются при описании предметной области? Как они используются при проектировании БД?

14. В каких случаях в концептуальной модели следует в явном виде отображать класс объектов?

15. Какие разновидности связи между объектами выделяются в базовой ER-модели? Какие графические обозначения используются для изоб­ражения каждого вида связи?

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

17. В каком случае следует вводить в модель обобщенный объект?

18. Какую информацию о предметной области дает граф пересечений?

19. Какие CASE-средства вы знаете?

20. Чем отличаются известные вам методологии ER-моделирования друг от друга?

21. Какие разновидности объектов выделяются в ER-модели, постро­енной в нотации IDEF1X?

22. В чем общность и различие процесса ER-моделирования в CASE-системах Design/IDEF и ERWin?

23. Что называется дискриминатором? Для каких целей он служит?

24. Что называется инверсным входом (Inversion Entry)? В каких слу­чаях при описании атрибута следует использовать этот признак?

25. В каких случаях в ERWin следует использовать при описании ат­рибута признак Logical Only (только логический)?

26. В чем отличие полных категорий (Complete sub-category) от не­полных (Incomplete sub-category)?

Глава 3 ДАТАЛОГИЧЕСКОЕ ПРОЕКТИРОВАНИЕ

3.1. Общие сведения о даталогическом проектировании

3.1.1. Исходные данные для даталогического проектирования

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

В разд. 1.5 было дано понятие даталогического проектирования и определен состав работ на этой стадии (см. рис. 1.23). Рассмотрим эту схему подробнее.

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

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

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

Все шаги проектирования даталогической модели выполняются итеративно. Причем вероятны итерации не только внутри стадии даталогического проектирования, но и с «захватом» других стадий про­ектирования БД.

3.1.2. Результат даталогического проектирования

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

Спроектировать логическую структуру базы данных - означает определить все информационные единицы и связи между ними, за­дать их имена; если для информационных единиц возможно исполь­зование разных типов, то определить их тип. Следует также задать некоторые количественные характеристики, например длину поля.

3.1.3. Подход к даталогическому проектированию

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

В БД отражается определенная предметная область. Поэтому про­цесс проектирования БД предусматривает предварительную класси­фикацию объектов предметной области, систематизированное пред­ставление информации об объектах и связях между ними.

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

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

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

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

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

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

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

Следует обратить внимание на то, что отношения, имеющие место в предметной области и отражаемые в ИЛМ, могут быть переданы не только посредством структуры базы данных, но и программным путем (т.е. всегда существует альтернатива между декларативным и проце­дурным способом описания явления). Например, при отображении обобщенных объектов можно не выделять подклассы на уровне логи­ческой структуры базы данных. В этом случае подклассы будут выде­ляться программным путем при обработке хранимых данных.

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

Характеристики

Список файлов книги