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

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

Основными компонентами логической модели являются:

Сущности;

Атрибуты сущности;

Связи между сущностями.

Сущность.

Сущность моделирует структуру однотипных информационных объектов (документов, хранилищ данных, таблиц базы данных). В пределах модели данных сущность имеет уникальное имя, выраженное существительным. Например: студент, счет-фактура, справочник_товаров.

Сущность является шаблоном на основании которого создаются конкретные экземпляры сущности. Например: экземпляр сущности студент – Иванов Иван Иванович.

Сущность обладает следующими свойствами:

Каждая сущность имеет уникальное имя, и к одному и тому же имени должна применятся одинаковая интерпретация;

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

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

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

На диаграмме сущность обычно изображается квадратом разделенным на две части рис.

Рис. 40 Сущность модели данных.

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

Зависимая сущность изображается прямоугольником со скругленными углами рис. (сущность льгота зависимая от сущности житель_бийска)

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

Атрибут может быть либо обязательным, либо необязательным (рисунок 2.23). Обязательность означает, что атрибут не может принимать неопределенных значений (null values). Атрибут может быть либо описательным (т.е. обычным дескриптором сущности), либо входить в состав уникального идентификатора (первичного ключа).

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

Атрибуты входящие в состав ключа должны быть обязательными и не изменятся во времени. Атрибуты входящие в состав ключа должны быть обязательными и не изменятся в времени. Например: имеем сущность Житель_Бийска.

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

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

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

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

Например, связь продавца с контрактом может быть выражена следующим образом:

• продавец может получить вознаграждение за 1 или более контрактов;
• контракт должен быть инициирован ровно одним продавцом.

Связь может дополнительно определяться с помощью указания степени или мощности (количества экземпляров сущности-потомка, которое может существовать для каждого экземпляра сущности-родителя). В IDEF1X могут быть выражены следующие мощности связей:

• каждый экземпляр сущности-родителя может иметь ноль, один или более связанных с ним экземпляров сущности-потомка;
• каждый экземпляр сущности-родителя должен иметь не менее одного связанного с ним экземпляра сущности-потомка -P;
• каждый экземпляр сущности-родителя должен иметь не более одного связанного с ним экземпляра сущности-потомка - Z;
• каждый экземпляр сущности-родителя связан с некоторым фиксированным числом экземпляров сущности-потомка.

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

Идентифицирующая связь изображается сплошной линией,

Рис. 43

Неидентифицирующая изображается штриховой линией.

Рис.44.

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

Рис. 45 Идентифицирующая связь.

Рис. 46 Неидентифицирующая связь.

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

Рис. 47 Связь многие ко многим.

В процессе моделирования данных, могут быть выявлены сущности часть атрибутов и связей которых одинаковы. Для моделирования таких случаев используется иерархия категорий. Все общие атрибуты выделяются в сущность называемую супертипом. Оставшиеся атрибуты помещаются в сущности называемые подтипоми. И они связываются с супертипом связью называемой ДИСКРИМИНАНТ.

Например:

Рис. 48 Пример иерархии категорий.

1.1 Логические модели

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

Пример. Возьмем утверждение: "Инфляция в стране превышает прошлогодний уровень в 2 раза". Это можно записать в виде логической модели: r(InfNew, InfOld, n), где r(x,y) - отношение вида "x=ny", InfNew - текущая инфляция в стране, InfOld - инфляция в прошлом году. Тогда можно рассматривать истинные и ложные предикаты, например, r(InfNew, InfOld, 2)=1, r(InfNew, InfOld, 3)=0 и т.д. Очень полезные операции для логических выводов - операции импликации, эквиваленции.

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

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

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

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

Описания предметных областей, выполненные в логических языках, называются логическими моделями. Логические модели, построенные с применением языков логического программирования, широко применяются в базах знаний и экспертных системах.

1.2 Продукционные модели

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

Продукция – это выражение, содержащее ядро, интерпретируемое фразой «Если А, то В», имя, сферу применения, условие применимости ядра и постусловие, представляющее собой процедуру, которую следует выполнить после успешной реализации ядра. Все части, кроме ядра, являются необязательными.

Взаимосвязанный набор продукций образует систему. Основная проблема вывода знания в системе продукций является выбор для анализа очередной продукции. Конкурирующие продукции образуют фронт.

Продукции (наряду с сетевыми моделями) являются наиболее популярными средствами представления знаний в системах ИИ. Импликация может истолковываться в обычном логическом смысле как знак логического следования B из истинного А. Возможны и другие интерпретации продукции, например А описывает некоторое условие, необходимое, чтобы можно было совершить действие B.

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

В состав системы продукций входит база правил (продукций), глобальная база данных и система управления. База правил - это область памяти, которая содержит совокупность знаний в форме правил вида ЕСЛИ - ТО. Глобальная база данных - область памяти, содержащая фактические данные (факты). Система управления формирует заключения, используя базу правил и базу данных. Существуют два способа формирования заключений - прямые выводы и обратные выводы.

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

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

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

М. Нострадамусом пророчеств: выходит издание большинства его центурий. Обращает на себя внимание взаимосвязанность этих Книг, а также Авесты. Если в Библии Заратуштра говорит о приходе в будущем пророка М. Нострадамуса, то в Пророчествах самого М. Нострадамуса мы многократно обнаруживаем его обращение к учению Заратуштры. В этом отношении весьма характерен катрен 83 центурии 8 (цитируется по...

ЛЕКЦИЯ

Логические модели данных.

Иерархические, сетевые, реляционные модели данных.

Принципы построения.

Преимущества и недостатки

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

11.1. О понятии «модель данных»

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

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

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

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

Итак, модель данных – модель логического уровня проектирования БД. Ее можно рассматривать как сочетание трех компонентов (слайд 2 ):

1. Структурный компонент, т.е. набор правил, по которым может быть построена БД.

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

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

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

Существуют три основных типа логических моделей данных на основе записей ( слайд 3 ):

- реляционная модель данных (relational data model );

- сетевая мо дель данных (network data model );

- иерархическая модель данных (hierarchical data model ).

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

11.2. Реляционная модель данных

Реляционная модель данных основана на понятии математических отношений. В реляционной модели данные и связи представлены в виде таблиц, каждая из которых имеет несколько столбцов с уникальными именами. На слайде (слайд 4 ) показан пример реляционной схемы, содержащей сведения о кафедрах ВУЗа и кадровом составе. Например, из таблицы «Кадровый состав» видно, что сотрудник Иванов И.И. работает в должности заведующего кафедрой 22, которая, согласно данным из таблицы «Структура», расположена в корпусе А, в комнате 322. Здесь важно отметить, что между отношениями «Кадровый состав» и «Структура» существует следующая связь: сотрудник работает на кафедре. Однако между этими двумя отношениями нет явно заданной связи: ее существование можно заметить, только зная, что атрибут Каф в отношении «Кадровый состав» эквивалентен атрибуту Каф в отношении «Структура».

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

На слайдах (слайды 5, 6 ) представлена реляционная модель данных для ПрО «сотрудники-проекты-детали-поставщики».

11.3. Сетевая модель данных

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

Самой популярной сетевой СУБД является система IDMS / R фирмы Computer Associates .

На слайдах (слайды 8, 9 ) представлены варианты сетевой модели данных для ПрО «сотрудники-проекты-детали-поставщики».

11.4. Иерархическая модель данных

Иерархическая модель является ограниченным подтипом сетевой модели. В ней данные также представлены как коллекции записей, а связи – как наборы. Однако в иерархической модели узел может иметь только одного родителя. Иерархическая модель может быть представлена как древовидный граф с записями в виде узлов (которые также называются сегментами) и множествами в виде ребер (слайд 6 ). На слайде приведен пример иерархической схемы для тех же наборов данных, которые показаны в предыдущих моделях.

Самой распространенной иерархической СУБД является система IMS корпорации IBM , хотя она обладает также некоторыми другими неиерархическими чертами.

На слайдах (слайды 11, 12 ) представлена варианты иерархической модели данных для ПрО «сотрудники-проекты-детали-поставщики».

11.5. Преимущества и недостатки моделей

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

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

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

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

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

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

11.6. Документальные системы и интеграция моделей

Приведенные выше положения разрабатывались и действительно широко используются для баз данных хорошо структурированной информации. Однако уже сегодня одной из важнейших проблем становится обеспечение интеграции неоднородных информационных ресурсов, и в частности слабоструктурированных данных. Необходимость ее решения связывается со стремлением к полноценной интеграции систем баз данных в среду Web-технологий. При этом уже недостаточно простого обеспечения доступа к базе данных традиционным способом “из-под” HTML-форм. Нужна интеграция на модельном уровне. И в этом случае проблема семантической интероперабельности информационных ресурсов сводится к задаче разработки средств и технологий, предусматривающих явную спецификацию метаданных для ресурсов слабоструктурированных данных на основе традиционных технологий моделирования из области баз данных.

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

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

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

Что иллюстрирует логическая модель

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

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

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

Взаимоотношения между сущностями иллюстрируются с помощью связей. Правила и ограничения взаимоотношений описываются с помощью свойств связей. Обычно связи определяют либо зависимости между сущностями, либо влияние одной сущности на другую.

Пример: Заказ пиццы

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

Основные требования

Основные требования к содержанию модели

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

2. Все объекты модели (и сущности, и связи) должны быть именованы. Именование сущностей и связей должно выполняться в терминах предметной области.

3. Для связей должна быть указана кратность (один — многие).

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

Пример: на модель добавлены наименования связей, их размерности и направление чтения.

5. Для сущностей должны быть указаны как минимум основные атрибуты.

Пример: для сущностей указаны основные атрибуты

Основные требования к качеству модели:

<Сущность 1> — <отношение / влияние> — <Сущность 2>.

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

Клиент может существовать без заказа. Однако заказ невозможно зарегистрировать без указания клиента. Один клиент может оформить неограниченное количество заказов

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

2. Модель должна быть структурирована, сущности должны быть сгруппированы по логическому смыслу.

3. Крайне желательно избегать пересечения связей.

4. Расположение объектов модели должно быть таким, чтобы ее удобно было читать.

Есть одно наблюдение — если на модель смотреть приятно, то скорее всего она выполнена качественно.

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

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

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

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

Как правило, ответ на этот вопрос вытекает из понимания стоящей перед бизнес-аналитиком задачи.

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

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

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

• В ходе анализа осуществляется выявление и отображение на модели сущностей и связей.

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

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

Заключение

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

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

Сергей Калинов

Ведущий бизнес-аналитик

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

1) Создание концептуальной модели бд.

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

2) Создание логической модели бд.

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

Для описания схемы базы данных на логическом уровне проектирования служит диаграмма “сущности-связи” (Entity-Relationship diagram или ER‑diagram). Существуют различные варианты диаграмм “сущности-связи”. Способы изображения элементов ER-диаграмм стали называть нотациями. На них одни и те же элементы графически изображаются по-разному. Известны нотация Мартина, нотация IDEF1X и др. Кроме того, различные программные средства, реализующие одну и ту же нотацию, могут отличаться своими возможностями. Все варианты диаграмм “сущность-связь” исходят из одной идеи – рисунок всегда нагляднее текстового описания. Все такие диаграммы используют графическое изображение сущностей предметной области, их свойств (атрибутов ), и взаимосвязей между сущностями .

3) Создание физической модели бд.

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

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

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

1) Создание концептуальной модели БД

Любое помещение характеризуется следующими параметрами: информация о корпусе, в котором расположено помещение; номер помещения; этаж, на котором оно расположено; краткое описание расположения помещения в корпусе; размеры помещения (ширина, длина и высота потолка в метрах).

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

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

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

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

2) Создание логической модели БД

Выделим основные информационные объекты, информацию о которых будет храниться в базе данных, атрибуты этих объектов и связи между объектами. Логическую модель представим в виде диаграммы «сущности-связи» в нотации IDEF1X (рис.1).

Рис. 1. Логическая модель БД

3) Создание физической модели БД

Выбрав СУБД Oracle в качестве целевой, преобразуем логическую модель в физическую (рис. 2).

Рис. 2. Физическая модель БД