Конспект лекций

Вид материала

Конспект

Содержание 2.2.Формулирование и анализ требований 2.3.Концептуальное проектирование

Подобный материал:

• Конспект лекций 2008 г. Батычко В. Т. Административное право. Конспект лекций. 2008, 1389.57kb.
• Конспект лекций 2010 г. Батычко Вл. Т. Муниципальное право. Конспект лекций. 2010, 2365.6kb.
• Конспект лекций 2011 г. Батычко В. Т. Семейное право. Конспект лекций. 2011, 1718.16kb.
• Конспект лекций 2011 г. Батычко Вл. Т. Конституционное право зарубежных стран. Конспект, 2667.54kb.
• Конспект лекций 2010 г. Батычко В. Т. Уголовное право. Общая часть. Конспект лекций., 3144.81kb.
• Конспект лекций для студентов по специальностям 190302 «Вагоны», 783.17kb.
• Конспект лекций бурлачков в. К., д э. н., проф. Москва, 1213.67kb.
• Конспект лекций для студентов специальности 080504 Государственное и муниципальное, 962.37kb.
• Конспект лекций по курсу "Начертательная геометрия и инженерная графика" Кемерово 2002, 786.75kb.
• Краткий конспект лекций 2009 г. Батычко В. Т. Прокурорский надзор. Конспект лекций., 1859.8kb.

2.2.Формулирование и анализ требований

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

Формулирование и анализ требований состоит из трех подэтапов:

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

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

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

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

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

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

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

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

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

Этап концептуального проектирования связан с описанием и синтезом разнообразных информационных требований пользователей в первоначальный проект БД. Результатом этого этапа является высокоуровневое представление информационных требований, например, такое как диаграмма "сущность - связь". Основу этой диаграммы составляет набор сущностей, который представляет или модернизирует определенную совокупность сведений, специфицированную в требованиях. Сущности могут быть описаны атрибутами, позволяющими детализировать свойства сущности. Один или несколько атрибутов могут служить идентификатором для обозначения отдельных экземпляров сущности. Связи между сущностями отображают функциональные аспекты информации, представленной сущностями.

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

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

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



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

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

Сущность представляет собой основное содержание того явления или процесса, о котором необходимо собрать информацию, она является узловой точкой сбора информации. В качестве сущности может выступать личность, место или вещь, информацию о которых нужно хранить. Необходимо различать такие понятия, как тип сущности и экземпляр сущности. Понятие тип сущности относится к набору однородных предметов или вещей, выступающему как целое. Экземпляр сущности относится к конкретной вещи в наборе. Например, типом сущности может быть СЛУЖАЩИЙ, а экземпляром сущности - Петров В.М., Сидоров А.Г., Терентьев М.С. и т.д.

Средством, с помощью которого определяются свойства сущностей, являются атрибуты. Атрибут - это поименованная характеристика сущности. Его наименование должно быть уникальным для конкретного типа сущности, но может быть одинаковым для различных типов сущностей (например, ЦВЕТ может быть определен для многих сущностей). Хотя сущности существуют сами по себе, атрибуты используются для определения того, какая информация должна быть собрана о сущности. Примерами атрибутов для сущности СЛУЖАЩИЙ являются ИМЯ. АДРЕС. ОТДЕЛ и т.д. Здесь также существует основное различие между типом и экземпляром. Тип атрибута ОТДЕЛ имеет множество экземпляров или значений: ОПТ, ОГМ и т.д. Однако каждому экземпляру сущности присваивается только одно значение атрибута.

Атрибут имеет следующие характеристики:

• Наименование - уникальное имя атрибута.
  
• Описание - повествовательное изложение смысла атрибута.
  
• Роль - конкретное использование атрибута. Атрибут может быть использован в любой роли, описанной ниже.
  

Наиболее часто встречающейся ролью атрибута является описание свойства сущности. Другой важной ролью является идентификация сущности, когда атрибут может использоваться для однозначного распознавания экземпляров сущности. Например, атрибут ТАБЕЛЬНЫЙ-НОМЕР, имеющий уникальный набор значений, позволяет отличать друг от друга экземпляры сущности СЛУЖАЩИЙ, даже если несколько служащих имеют одну и ту же фамилию. Среди других ролей атрибута необходимо отметить:

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

Сущности соотносятся в предметной области между собой, а механизм связей используется для отображения этого соответствия в модели. Более подробно связи были рассмотрены ранее в разд. 1.5.