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

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

36. Какие требования предъявляются к инфологической модели?

37. Что называется даталогической моделью?

38. Какая информация является исходной для построения даталоги­ческой модели?

39. Какие вопросы решаются на стадии даталогического моделиро­вания?

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

41. Что называется физической моделью?

42. Какая информация является исходной для построения физичес­кой модели?

43. Какие вопросы решаются на стадии физического моделирования?

44. Какие факторы влияют на проектирование БД?

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

46. Кого называют конечными пользователями?

47. Кого называют администраторами банка данных?

48. Перечислите основные функции администратора банка данных.

49. В каком порядке должны выполняться этапы проектирования БнД?

50. Какая информация является исходной при выполнении инфологического проектирования?

51. Какие факторы влияют на проектные решения при создании баз данных?

52. Какие критерии используются при оценке спроектированной БД?

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

2.1. Общие сведения о моделировании предметной области

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

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

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

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

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

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

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

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

Изучение предметной области складывается из непосредственного наблюдения протекающих в ней процессов, изучения документов, циркулирующих в системе, а также интервьюирования участников этих процессов (рис. 2.1). Так как описание инфологической модели выполняется на специализированном языке, то необходимо владение этим языком. Следует обратить внимание на то, что возможности языка описания ИМЛ оказывают влияние на методику построения модели с использованием данных языковых средств. Построение концептуальной модели может выполняться и вручную, и с использованием автоматизированных средств проектирования. Средства автоматизации проектирования отличаются как нотациями используемых языковых средств, так и алгоритмами преобразования концептуальной модели в модели базы данных. Это, в свою очередь, скажется на методике построения модели в их среде.

Рис. 2.1. Стадия инфологического моделирования - исходная и результатная информация

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

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

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

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

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

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

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

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

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

• лингвистические отношения.

Далее более подробно остановимся на первом из перечисленных компонентов, так как именно он оказывает наибольшее влияние на проектирование структуры базы данных. Чаще всего описание объектов ПО и связей между ними представляется в виде так называемых ER-моделей (или ER-диаграмм)^.

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

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

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

• непротиворечивость (модель отражает взгляды и потребности всех пользователей системы, а также обычно является результатом работы многих специалистов, поэтому целостное описание ПО должно быть проверено на непротиворечивость);

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

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

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

• конечность модели (несмотря на то, что реальный мир, отобра­жаемый в КМ, является по своей природе бесконечным, инфологи-ческая модель является конечной, что обеспечивается четким огра­ничением предметной области);

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

• возможность композиции и декомпозиции модели.

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

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

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

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

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

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

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

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

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

ER-модель представляет собой графическое описание предметной области в терминах «объект – свойство – связь». ER-модель является одним из элементов концептуальной модели. Использование ER-моделирования (особенно в сочетании с автоматизированными средствами проектирования - CASE-средствами) дает много преимуществ:

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

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

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

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

• снижаются требования к знанию деталей языков описания данных (DDL - Data Definition Language) и диалектов SQL конкретных СУБД;

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

• наличие в CASE-средстве возможности «обратного проектиро­вания» (т.е. получения ER-диаграммы по имеющимся описаниям данных) позволяет использовать существовавшие ранее наработки для «реверс-инжиниринга» системы;

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

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

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

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

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

2.2. Описание базовой ER-модели

Существует большое число нотаций (изобразительных средств) и методик построения ER-моделей. Рассмотрим методику построения ER-модели, предлагаемую автором данного учебника. Будем называть эту методику ER-моделирования базовой. Некоторые другие методи­ки изложены в разд. 2.3, а также в [1-3, 7, 15, 20, 21, 25] или в доку­ментации по CASE-средствам.

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

В предметной области имеется множество разнообразных объектов. Объект – понятие широкое. Его трудно точно определить. Обычно под объектом понимают некую сущность (реальную или абстрактную), о которой собирается какая-то информация. Объекты группируются в классы. Классом объектов называют совокупность объектов, обладающих одинаковым набором свойств. Например, для объектов класса СТУДЕНТ таким набором свойств являются: «Год_рождения», «Пол» и др.

Объекты могут быть реальными, как названный выше объект СТУДЕНТ, и абстрактными, как, например, ПРЕДМЕТЫ, которые изучают студенты.

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

Каждому классу объектов в ER-модели присваивается уникальное имя. Именем класса объекта является грамматический оборот существительного (существительное, у которого могут быть прилагательные и предлоги). Если имя состоит из нескольких слов, то желательно, чтобы первым стояло существительное. Существительное должно употребляться в единственном, а не во множественном числе (например, ДИСЦИПЛИНА_ИЗУЧАЕМАЯ). Если в предметной об­ласти традиционно используются разные имена для обозначения какого-либо класса объектов (т.е. имеет место синонимия), то все они должны быть зафиксированы при описании системы, и затем одно из них выбирается за основное, и только оно должно в дальнейшем использоваться в ER-модели. Помимо имени класса объектов в ER-mo-дели может использоваться его короткое кодовое обозначение; для дальнейшего перехода к даталогической модели еще может указы­ваться имя, которое будет использоваться при описании структуры базы данных.

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

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

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