В чем заключается концептуальное проектирование для конкретной предметной области
Концептуальное проектирование
Концептуальное проектирование оперирует информацией, независимой от любой фактической реализации (т.е. от любой конкретной системы технического или программного обеспечения). Цель концептуального проектирования именно в том состоит, чтобы представить информацию в доступной пользователю форме, не зависящей от спецификации системы, но реализуемой несколькими системами.
Этап концептуального проектирования связан с описанием и синтезом разнообразных информационных требований пользователей в первоначальный проект БД. Результатом этого этапа является высокоуровневое представление информационных требований, например, такое как диаграмма «сущность – связь». Основу этой диаграммы составляет набор сущностей, который представляет или модернизирует определенную совокупность сведений, специфицированную в требованиях. Сущности могут быть описаны атрибутами, позволяющими детализировать свойства сущности. Один или несколько атрибутов могут служить идентификатором для обозначения отдельных экземпляров сущности. Связи между сущностями отображают функциональные аспекты информации, представленной сущностями.
В большинстве случаев пользователи описывают свои информационные требования в терминах сущностей, атрибутов и связей (диаграмма типа «сущность – связь» или ER-диаграммы) или в терминах записей, элементов и наборов, используя языки описания данных СУБД.
Таким образом, концептуальное проектирование можно рассматривать с двух точек зрения – обычного представления и моделирования сущностей, указанных на рисунке.
Первый подход включает формулирование, определение и интеграцию объектов высокого уровня, используемых для построения модели. Основное внимание при этом уделяется интеграции понятий (концепции), представляющих объекты. Основными вопросами, решаемыми при этом подходе, являются следующие. Что понимать под объектами? Каковы контекстное содержание этих объектов, описательные и идентификационные свойства каждого объекта.
Второй подход к концептуальному проектированию моделирование сущностей – заключается в моделировании и интеграции представлений пользователей в терминах диаграмм сущностей. Техника построения диаграмм сущностей, являясь в основном неформализованной, имеет конечным результатом спецификацию сущностей, атрибутов и связей. Этот подход является наиболее широко известным и практикуемым из всех подходов. Он берет свое начало со времени первых попыток использования систем управления БД в середине 60-х годов. В связи с этим следует рассмотреть данный подход более подробно.
Для представления информации в модели «сущность – связь» конструктивными элементами модели служат сущности, атрибуты и связи. Основным конструктивным элементом является сущность. Пользователь описывает интересующие его объекты предметной области с помощью сущностей, затем определяет свойства сущностей, используя атрибуты, и, наконец, описывает соответствия между сущностями, используя связи.
Сущность представляет собой основное содержание того явления или процесса, о котором необходимо собрать информацию, она является узловой точкой сбора информации. В качестве сущности может выступать личность, место или вещь, информацию о которых нужно хранить. Необходимо различать такие понятия, как тип сущности и экземпляр сущности. Понятие тип сущности относится к набору однородных предметов или вещей, выступающему как целое. Экземпляр сущности относится к конкретной вещи в наборе. Например, типом сущности может быть СЛУЖАЩИЙ, а экземпляром сущности – Петров В.М., Сидоров А.Г., Терентьев М.С. и т.д.
Средством, с помощью которого определяются свойства сущностей, являются атрибуты. Атрибут – это поименованная характеристика сущности. Его наименование должно быть уникальным для конкретного типа сущности, но может быть одинаковым для различных типов сущностей (например, ЦВЕТ может быть определен для многих сущностей). Хотя сущности существуют сами по себе, атрибуты используются для определения того, какая информация должна быть собрана о сущности. Примерами атрибутов для сущности СЛУЖАЩИЙ являются ИМЯ. АДРЕС. ОТДЕЛ и т.д. Здесь также существует основное различие между типом и экземпляром. Тип атрибута ОТДЕЛ имеет множество экземпляров или значений: ОПТ, ОГМ и т.д. Однако каждому экземпляру сущности присваивается только одно значение атрибута.
Атрибут имеет следующие характеристики:
— Наименование – уникальное имя атрибута.
— Описание – повествовательное изложение смысла атрибута.
— Роль – конкретное использование атрибута. Атрибут может быть использован в любой роли, описанной ниже.
Наиболее часто встречающейся ролью атрибута является описание свойства сущности. Другой важной ролью является идентификация сущности, когда атрибут может использоваться для однозначного распознавания экземпляров сущности. Например, атрибут ТАБЕЛЬНЫЙ-НОМЕР, имеющий уникальный набор значений, позволяет отличать друг от друга экземпляры сущности СЛУЖАЩИЙ, даже если несколько служащих имеют одну и ту же фамилию. Среди других ролей атрибута необходимо отметить:
1. представление связей между сущностями:
2. использование в процессе получения других выводимых величин:
3. обеспечение информацией, которая используется в особых случаях, например диапазон значений домена, количество экземпляров, единица измерения.
Сущности соотносятся в предметной области между собой, а механизм связей используется для отображения этого соответствия в модели. Более подробно связи были рассмотрены ранее в разд. 1.5.
Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет
Конспект по дисциплине Информационные технологии на тему «Концептуальное проектирование БД»
Выполняется построение информационной модели предметной области, данные о которой должны отображаться в БД.
Информационный объект – это идентифицируемый (т. е. такой, который можно выделить в предметной области) объект реального мира, понятие, процесс или явление. В роли информационных объектов могут выступать люди, изделия, счета и т. д.
Если задаться конкретным студентом как экземпляром информационного объекта, то характеристики приобретают значения. Например (в порядке перечисления характеристик), Иванов, 4.
Для нашего примера элементами данных являются (в каждой строке представлен элемент данных):
фамилия (Иванов; Федоров; Петров);
средний балл (4, 5, 4).
Подобные данные привычнее (и удобнее) представлять таблицей:
Здесь элементом данных является каждый столбец. Видно, что структура каждого столбца единообразна: есть заголовок – суть имя характеристики информационного объекта, а также имеется множество значений данной характеристики – под заголовком.
Запись об объекте – совокупность значений элементов данных, которые описывают конкретный экземпляр объекта.
Для нашего примера, представленного таблицей, запись об объекте – это одна из строк таблицы со значениями, например,
Для различения экземпляров объектов применяется идентификатор – элемент данных (или совокупность элементов данных), используемый для выделения одного или группы экземпляров объектов.
Идентификация может быть уникальной (или однозначной), когда идентификатору сопоставим один экземпляр объектов, и неуникальной (многозначной), когда идентификатору сопоставимо множество (возможно, одноэлементное) экземпляров объекта.
Так, в нашем примере характеристики «фамилия» и «телефон» могут служить однозначным идентификатором – каждое значение соответствующей характеристики определяет только один экземпляр. В то же время характеристика «средний балл» является примером многозначного идентификатора – одинаковые результаты сдачи сессии принадлежат разным студентам.
При концептуальном проектировании осуществляется выявление информационных объектов, их характеристик, связей между объектами, определение идентификаторов.
Для формального представления концептуальной модели при проектировании структуры данных используется ER[9]-модель. Она применяет следующие базовые понятия и их обозначения:
атрибут сущности (свойство, характеризующее объект);
ранее – характеристика информационного объекта
ключевой атрибут;
ранее – идентификатор информационного объекта
связь, именуется, как правило, глаголом или
Объект и его атрибуты соединяются ненаправленными дугами:
Связи между объектами могут быть 3-х типов:
Если связь соединяет две сущности, она называется бинарной. Связь может соединять более двух сущностей, например, связь, соединяющая три сущности, называется тернарной:
Пусть, например, требуется разработать концептуальную модель данных, описывающую организационную структуру кафедр вуза. Тогда кафедры являются предметной областью для задачи. Данная предметная область характеризуется следующими сущностями и их атрибутами:
сотрудник – ФИО, ученая степень, научное звание, контактные данные;
кафедра – название, шифр в вузе;
должность – название, образование.
Сформируем ER-диаграммы, описывающие сущности и связи между ними:
Определим, какие атрибуты могут играть роль ключевых:
§ для сущности кафедра оба атрибута однозначно определяют объект, поскольку не бывает в рамках одного вуза разных кафедр с одинаковыми названиями или шифрами. Для выбора следует ориентироваться на то, какой атрибут, скорее всего, будет использоваться при поиске нужной записи в БД. Очевидно, пользователю удобнее применять название кафедры, поэтому данный атрибут определим как ключевой;
§ для сущности сотрудник дело обстоит гораздо сложнее. Предметная область такова, что в реальной ситуации ни один из указанных атрибутов не может служить ключевым. В самом деле, в вузе возможны сотрудники с одинаковыми ФИО. Гораздо меньше вероятность полных тезок и однофамильцев в рамках одной кафедры. Тогда в качестве ключевых атрибутов следует использовать совокупность идентификаторов сотрудников и кафедр.
Особенности концептуального моделирования предметной области
Я продолжаю серию статей, посвященных особенностям концептуального моделирования предметных областей. В прошлой статье я показал. как возможно связать объект с классом объектов семантической связью. В статье я рассказал о том, что понимается под термином класс в ООП. Сегодня я расскажу, почему я предпочитаю строить концептуальные модели в виде ER диаграмм.
Пусть нам надо смоделировать тезис, о том, что на каждом автомобиле стоит по 4 колеса. Не группа из четырех колес, а именно, — 4 колеса.
В терминах ER модели принято говорить, что есть автомобиль, есть колесо и есть связь между автомобилем и колесом. Связь эта называется «колесо-автомобиль» и имеет отношение один ко четырем. Связь, читаемая от колес, называется: «стоит на», связь, читаемая от автомобиля, называется: «имеет».
В терминах ООП говорят так: есть класс ООП автомобилей и есть класс ООП колес. Между этими классами ООП есть связь один к четырем. Связь называется: «автомобиль-колесо». Связь, читаемая от колес, называется: «стоит на», связь, читаемая от автомобиля, называется: «имеет».
Посмотрим внимательно на предметную область и напишем, как будет выглядеть представление модели предметной области в терминах логической парадигмы.
В логической парадигме есть термин класс ТМ, который совпадает с определением класса в математике. Это определение очень похоже на определение множества, а множество, в свою очередь – есть группа объектов. Итак, у нас есть множество автомобилей и множество колес. С каждым автомобилем связано 4 колеса семантическими связями «автомобиль-колесо». Таким образом, на каждый автомобиль приходится 4 колеса и 4 семантических связи. Семантическая связь в логической парадигме записывается в виде кортежа: (Автомобиль №123; колесо №234). Все кортежи принадлежат классу, или множеству кортежей. Объединяет это множество семантика: «На автомобиле стоит колесо». Между конкретным колесом и автомобилем, на котором установлено это колесо, установлена только одна семантическая связь. Эта связь имеет отношение один к одному. Как же тогда сказать, что на одном автомобиле установлено 4 колеса? В логической парадигме это произносится так: для каждого автомобиля найдется 4 связи с колесами в классе семантических связей под названием «Автомобиль имеет колесо», для каждого колеса существует только одна такая связь в этом классе.
Таким образом, для моделирования одного автомобиля нам понадобилось 4 связи между автомобилем с колесом, а не одна, как в случае с ER моделью, и не одна, как в случае с диаграммой классов. Это и логично: у одного автомобиля 4 колеса. На диаграмме стрелочками обозначена связь «классификация».
А есть ли семантическая связь между классом ТМ автомобилей и классом ТМ колес? В такой постановке задачи – нет. Есть класс связей между автомобилями и колесами, но нет связи между классом ТМ автомобилей и классом ТМ колес.
Рассмотрим теперь другую задачу. Пусть надо смоделировать тот факт, что автомобили имеют группу колес. Не колеса, а именно группу. В математике за определение группы отвечает термин множество. На математическом языке мы должны сказать: автомобиль имеет множество (группу) колес. Это значит, что мы постулировали возможность связать семантической связью объект и класс объектов. Как смоделировать этот тезис в логической парадигме?
Для этого из класса ТМ колес мы выделяем такие классы колес, каждый из которых относится к одной машине. Так мы связываем машину и группу колес, относящихся к данной машине. В модели это будет выглядеть так:
Стрелки по-прежнему обозначают связь классификация, но кружочек обозначает связь специализация, или «множество- подмножество».
На этой диаграмме мы видим, что объект автомобиль связан с классом колес семантической связью «имеет».
Такая модель уже не представима в виде диаграммы классов или в виде ER модели. Кроме того, ни один современный онтологический стандарт не имеет возможности моделировать такие отношения. Причина проста: трудность в реализации таких отношения на ООП языках программирования.
Заметим, что диаграммы классов не моделируют классы объектов: прямоугольники на диаграммах классов моделируют типы объектов.
И эта модель приближает нас к модели классов ТМ. Однако, связи между классами ТМ на самом деле не существует, а есть связи между объектами класса ТМ, и читаются они так: для каждого автомобиля найдется 4 связи с колесами в классе семантических связей под названием «Автомобиль имеет колесо», для каждого колеса существует только одна такая связь в этом классе.
Вывод: концептуальное моделирование в виде ER много ближе к логической парадигме, чем моделирование в виде диаграммы классов. Но ни тот ни другой метод моделирования не позволяет моделировать семантические отношения между объектами и классами объектов. Это является существенным ограничением современных моделлеров, которое необходимо устранять.
Первая стадия концептуального проектирования базы данных (концептуальное моделирование)
Цель лекции: показать, как описывается предметная область при концептуальном моделировании (с помощью каких понятий, средств представления и приемов построения) и как обеспечивается достоверность информации в базе данных за счет ограничений целостности концептуальной модели.
5.1. Описание информационного представления предметной области. ER-диаграмма
Введем основные понятия, с помощью которых описывается предметная область.
Сущность (Entity) или объект – то, о чем будет накапливаться информация в информационной системе (нечто такое, за чем пользователь хотел бы наблюдать).
Если в системе обрабатывается информация о факультетах, сущностью будет являться факультет, если о студентах, сущность – студент и т.п.
Имя сущности при ER-моделировании, как правило, записывается заглавными буквами. Каждая сущность обладает определенным набором свойств (рассматриваем только свойства, представляющие интерес для пользователей в рамках проводимого исследования), которые запоминаются в информационной системе. Так, например, в качестве свойств сущности ФАКУЛЬТЕТ можно указать номер факультета, название факультета, в качестве свойств сущности СТУДЕНТ можно указать фамилию, дату рождения, место рождения, в качестве свойств сущности ЭКЗАМЕН – предмет, дату проведения экзамена, экзаменаторов.
Для информационного описания сущности вводится понятие атрибута.
Пример класса сущностей СТУДЕНТ и конкретного экземпляра сущности показан на рис. 5.1
Числа, описывающие типы бинарных связей ( 1:1, 1:M, M:N ), обозначают максимальное количество сущностей на каждой стороне связи. Эти числа называются максимальными кардинальными числами, а соответствующая пара чисел называется максимальной кардинальностью.
Напомним, что каждый экземпляр сущности должен уникально идентифицироваться (иметь уникальный идентификатор ). Так как могут быть несколько студентов с одинаковой фамилией, введем дополнительный атрибут «код студента». У сущностей ФАКУЛЬТЕТ и СПЕЦИАЛЬНОСТЬ атрибут «номер» является уникальным идентификатором.
Проектирование систем на основе концептуального моделирования предметной области
Особенности проектирования ИС
Эволюция информационных систем от пакетной, массовой технологии обработки данных к системам, использующим базы данных, выявила три класса наиболее перспективных методологий проектирования. Первый из них ориентирован на концептуальное моделирование предметной области и технологию баз данных, второй — на выявление требований и спецификацию информационной системы через ее макетирование, третий — на системную архитектуру программных средств, поддерживаемую инструментальными средствами CASE (Computer Aided System Engineering) — технологии.
Методология проектирования информационных систем на основе концептуального (понятийного) моделирования предметной области (ПО) — одна из наиболее часто используемых. Она представляет собой структурированный процесс создания систем, который обычно разбивается на следующие шаги: анализ, проектирование, программирование, тестирование и внедрение.
При концептуальном моделировании ПО и применении технологии БД наиболее сложной задачей является выявление информационных и функциональных (динамических) связей между объектами реального мира.
Информационная структура ПО содержит все объекты и их связи, которые необходимы для построения ИС, а функциональная структура определяет, каким образом используются и обрабатываются эти объекты. Информационная и функциональная структуры совместно обеспечивают полную спецификацию информационной системы.
Концептуальный подход к проектированию предполагает четыре этапа проектирования:
— сбор и анализ информационных потребностей пользователей, системный анализ предметной области;
— построение концептуальной (понятийной) модели предметной области;
— создание концептуальной модели базы данных;
— разработку системы с помощью инструментальных средств выбранной СУБД.
Первый очень важный этап разработки системы — анализ требований может быть определен как этап понимания задач приложений. Именно здесь пользователи будущей системы должны сформулировать, а разработчики понять, что должна делать система, какие у нее особенности, какие понятия используются в задачах, какие ситуации предметной области должны моделироваться в базе данных.
На втором этапе разработчики системы должны определить устойчивые свойства данных и описать информационные и технологические процессы, использующие данные, их взаимосвязь и характеристики. Иногда эту работу определяют как построение концептуальной (инфологической) модели предметной области, содержащей описание понятий, не ориентированное ни на какую конкретную даталогическую модель.
Концептуальная модель предметной области ориентирована на восприятие человека (пользователя и разработчика), а не на обработку данных в ЭВМ. Именно с помощью этой модели разработчики ИС (да и сами пользователи) достигают высокого уровня понимания существа информационных потребностей пользователей. В настоящее время для построения концептуальной модели предметной области обычно используют два подхода. При первом подходе модель ПО строится на основе интеграции спецификаций информационных потребностей, а при втором — на основе непосредственного анализа самой ПО.
В первом случае более широко применяются инструментальные средства системных программных продуктов, которые интегрируются в единую программную систему, обеспечивающую обработку доступной информации, как на этапе анализа, так и на этапе проектирования прикладной системы.
В проектировании, основанном на непосредственном создании концептуальной модели предметной области, главной задачей является получение формального (независимого от СУБД) описания предметной области, которая должна моделироваться в БД. При этом система проектирования и методология проектирования должны поддерживать как получение от пользователей знаний о свойствах предметной области, так и отображение этих упорядоченных и организованных знаний в набор предварительных описаний, составляющих собственно концептуальную модель предметной области.
Концептуальная модель включает описание понятий предметной области и информационных процессов, протекающих в ней, т. е. содержит всю необходимую для проектирования системы информацию. Информации должно быть достаточно, чтобы принимать правильные решения при проектировании не только БД, но и программной реализации задач.
Заключительный этап проектирования тесно связан с возможностями инструментальных средств конкретных СУБД.
Данный этап в свою очередь разбивают на следующие шаги:
— логическое проектирование БД;
— физическое проектирование БД;
В соответствии с вышеизложенным методология проектирования ИС на основе концептуального моделирования ПО может быть представлена в виде последовательности этапов, изображенных на рис. 1.10.
Такая стратегия проектирования обычно гарантирует разработку удовлетворительной системы при условии, что требования к системе фиксируются и их изменение не допускается до тех пор, пока система не предъявляется пользователям. Однако в этом случае ошибки проектирования могут быть обнаружены только на последних стадиях проектирования (либо при тестировании системы, либо во время проведения ее испытаний), что требует пересмотра всех спецификаций проекта и ведет к значительным трудозатратам.
Однако возможность повышения производительности проектирования ИС при данном подходе остается ограниченной, так как на этапе внедрения часто выясняется, что важные требования к ИС остались неучтенными в созданной системе, а исправление допущенных ошибок требует больших трудозатрат.
Рис. 1.10. Этапы проектирования ИС на основе концептуального моделирования ПО.
Структурные свойства описываются с помощью абстракций типизации, агрегации, обобщения и ассоциации, а для описания поведенческих аспектов чаще всего употребляется концепция события.
Абстракции обеспечивают четкое, структурированное представление об объектах предметной области, их классах и взаимосвязях между объектами и классами объектов.
События, отражая факт изменения происшедшего в одном или нескольких объектах, позволяют адекватно учесть динамические процессы, происходящие в ПО.