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

Логические модели представления знаний реализуются средствами логики предикатов.

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

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

ДАТЬ (МИХАИЛ, ВЛАДИМИРУ, КНИГУ);

($x) (ЭЛЕМЕНТ (x, СОБЫТИЕ-ДАТЬ) ? ИСТОЧНИК (x, МИХАИЛ) ? АДРЕСАТ? (x, ВЛАДИМИР) ОБЪЕКТ(x, КНИГА).

Здесь описаны два способа записи одного факта: «Михаил дал книгу Владимиру».

Логический вывод осуществляется с помощью силлогизма (если из A следует B, а из B следует C, то из A следует C).

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

S = ,

где B - счетное множество базовых символов (алфавит) теории S;

F - подмножество выражений теории S, называемые формулами теории (под выражениями понимаются конечные последовательности базовых символов теории S);

A - выделенное множество формул, называемые аксиомами теории S, то есть множество априорных формул;

R - конечное множество отношений {r 1 , …, r n } между формулами, называемые правилами вывода .

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

Покажем метод резолюций.

В методе используется несколько понятий и теорем.

Понятие тавтологии , логической формулы, значением которой будет «истина» при любых значениях входящих в них атомов. Обозначается?, читается как «общезначимо» или «всегда истинно».

Теорема 1. А?В тогда и только тогда, когда?А В.

Теорема 2. А1, А2, ..., Аn ? В тогда и только тогда, когда? (A1?A2?A3?…?An) В.

Символ? читается как «верно, что» или «можно вывести».

В основе метода лежит доказательство тавтологии

? (X ? A) ?(Y ? ? A)?(X ? Y ) .

Теоремы 1 и 2 позволяют записать это правило в следующем виде:

(X ? A), (Y ? ? A) ? (X ? Y ),

что дает основания утверждать: из посылок и можно вывести .

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

1. Устраняются операции эквивалентности и импликации:

2. Операция отрицания продвигается внутрь формул с помощью законов де Моргана:

3. Логические формулы приводятся к дизъюнктивной форме: .

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

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

1.Приведение посылок к дизъюнктивной форме:
, , .

2.Построение отрицания выводимого заключения . Полученная конъюнкция справедлива, когда и одновременно истинны.

3.Применение правила резолюции:

(противоречие или «пустой дизъюнкт»).

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

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

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

Алгоритм унификации предикатных логических формул включает следующие шаги.

После выполнения всех шагов описанного алгоритма унификации можно применять правило резолюции, Обычно при этом осуществляется отрицание выводимого заключения, и алгоритм вывода можно кратко описать следующим образом: Если задано несколько аксиом (теория Тh) и предстоит сделать заключение о том, выводима ли некоторая формула Р из аксиом теории Тh, строится отрицание Р и добавляется к Тh, при этом получают новую теорию Тh1. После приведения и аксиом теории к системе дизъюнктов можно построить конъюнкцию и аксиом теории Тh. При этом существует возможность выводить из исходных дизъюнктов дизъюнкты - следствия. Если Р выводимо из аксиом теории Тh, то в процессе вывода можно получить некоторый дизъюнкт Q, состоящий из одной литеры, и противоположный ему дизъюнкт . Это противоречие свидетельствует о том, что Р выводимо из аксиом Тh. Вообще говоря, существует множество стратегий доказательства, нами рассмотрена лишь одна из возможных - нисходящая.

Пример: представим средствами логики предикатов следующий текст:

«Если студент умеет хорошо программировать, то он может стать специалистом в области прикладной информатики».

«Если студент хорошо сдал экзамен по информационным системам, значит, он умеет хорошо программировать».

Представим этот текст средствами логики предикатов первого порядка. Введем обозначения: X - переменная для обозначения студента; хорошо - константа, соответствующая уровню квалификации; Р(Х) - предикат, выражающий возможность субъекта X стать специалистом по прикладной информатике; Q (Х, хорошо) - предикат, обозначающий умение субъекта X программировать с оценкой хорошо ; R (Х, хорошо) - предикат, задающий связь студента X с экзаменационной оценкой по информационным системам.

Теперь построим множество правильно построенных формул:

Q(Х, хорошо) .

R (Х, хорошо) Q (Х, хорошо).

Дополним полученную теорию конкретным фактом
R (иванов, хорошо) .

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

Доказательство

1. Выполним преобразование исходных формул теории в целях приведения к дизъюнктивной форме:

(Х, хорошо) Р(Х);

(Х,хорошо) (Х,хорошо);

R (иванов , хорошо).

2. Добавим к имеющимся аксиомам отрицание выводимого заключения

(иванов).

3. Построим конъюнкцию дизъюнктов

(Х, хорошо) Р(Х) ? ? P (иванов, хорошо) ? ? Q (иванов, хорошо), заменяя переменную X на константу иванов .

Результат применения правила резолюции называют резольвентой . В данном случае резольвентой является (иванов).

4. Построим конъюнкцию дизъюнктов с использованием резольвенты, полученной на шаге 3:

(Х, хорошо) (Х, хорошо) (иванов, хорошо) (иванов, хорошо).

5. Запишем конъюнкцию полученной резольвенты с последним дизъюнктом теории:

(иванов, хорошо) (иванов, хорошо) (противоречие).

Следовательно, факт Р(иванов ) выводим из аксиом данной теории.

Для определения порядка применения аксиом в процессе вывода существуют следующие эвристические правила:

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

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

Аннотация

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

Введение 3

1.Предметная область 4

2.Концептуальная модель 5

3.Логическая модель базы данных 7

4.Модель физической организации данных 9

5.Реализация баз данных в Oracle 9

6.Создание таблиц 10

7.Создание запросов 16

8.Заключение 27

Список литературы 28

Введение

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

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

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

Предметная область

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

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

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

Концептуальная модель

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

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

Самой популярной моделью концептуального проектирования является модель «сущность-связь» (ER-модель), она относится к семантическим моделям.

Основными элементами модели являются сущности, связи между ними и их свойства (атрибуты).

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

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

Атрибут – характеристика (параметр) не которой сущности.

Домен – множество значений (область определения атрибутов).

У сущностей выделяются ключевые атрибуты – ключ сущности – это один или более атрибутов, уникально определяющих данную сущность.

Набор сущностей для центральной больницы (в скобках указаны атрибуты сущностей, подчёркнуты ключевые атрибуты):

ПАЦИЕНТЫ (Код пациента , фамилия, имя, дата рождения, номер страхового полиса, код отделения);

ЛЕЧЕНИЕ (Код больного , диагноз, дата выписки, код врача, стоимость);

ОТДЕЛЕНИЯ(Код отделения , название отделения, количество палат);

ПОСТУПЛЕНИЯ (Код больного, дата поступления, код палаты);

ПАЛАТЫ (Код палаты , кол-во мест, код отделения);

ВРАЧИ (Код врача, фамилия, имя, дата рождения, номер личного дела, код отделения);

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

Логическая модель базы данных

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

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

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

Атрибут (поле) – любой столбец в таблице.

Кортежи (записи) – строки таблицы.

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

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

В реляционных базах данных логическое проектирование приводит к разработке схемы данных, которая представлена на рисунке 2.

Рис.2.
4. Модель физической организации данных

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

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

©2015-2019 сайт
Все права принадлежать их авторам. Данный сайт не претендует на авторства, а предоставляет бесплатное использование.
Дата создания страницы: 2016-04-26

Логические модели реализуются средствами так называемой логики предикатов.

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

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

Константы логики предикатов служат для именования объектов предметной области.

Логические выражения (или высказывания) образуют атомарные (простейшие) формулы.

Интерпретация предикатов – множество всех допустимых связываний переменных с константами. При этом связывани я – подстановка констант вместо переменных.

Высказывание логически следует из заданных посылок. Оно истинно всегда, когда истинны посылки.

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

Основу исчисления высказываний составляют правила образования сложных высказываний из атомарных.

Пример сложных высказываний.

А – истинно и В – ложно.

А и В истинно.

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

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

Предикаты: clear (a), clear (c), ontable (a), ontable (c), on (c,b), cube(a), cube(b), pyram.de(c).

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

М = {Т, Р, А, П}

Т – множество базовых элементов (алфавит)

Р – множество синтаксических правил, на которых можно строить синтаксически корректные предложения

А – множество аксиом или несколько синтаксически правильных предложений, заданных априорно

П – правила продукций (правило вывода или семантическое правило, с помощью которого можно расширить множество А, добавляя в него синтаксически правильные предложения

Главное преимущество логических моделей: возможность непосредственно запрограммировать механизм вывода логически правильных предложений. Однако, с помощью правил, задающих синтаксис языка, нельзя установить истинность или ложность того или иного высказывания. Это распространяется на все языки программирования, реализующие логику предикатов.

Высказывание может быть построено синтаксически правильно, но оказаться совершенно бессмысленным.

Логические модели представления и манипулирования знаний были особенно популярны в 70-х годах 20 века, особенно с появлением языка пролог.

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

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

ФРЕЙМ

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

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

Структура фрейма – характеристика описываемой стереотипной ситуации и их значения, которые называются слотами и заполнителями слотов .

Структура:

(Имя фрейма: Имя слота 1 (значение слота 1); Имя слота 2 (значение слота2); . . . Имя слота N (значение слотаN))

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

В качестве значения слота может быть значение слота более низкого уровня, что позволяет реализовать «принцип матрешки».

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

Фрейм можно представить в виде своеобразной таблицы.

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

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

Существует несколько способов получения слотом значения во фрейм экземпляре:

1) по умолчанию от фрейма образца;

2) через наследование свойств от фрейма указанного в слоте АКО;

3) по формуле, указанной в слоте;

4) через присоединяющуюся процедуру;

5) явно из диалога с пользователем;

6) из БД.

Важнейшим свойством теории фреймов является так называемое наследование свойств. Это наследование происходит по АКО – связям. A KIND OF (AKO)

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

В сети фреймов на рисунке понятие «ученик» наследует свойства фреймов «ребенок» и «человек», которые находятся на более высоком уровне иерархии. Так, на вопрос «любят ли ученики сладкое», следует ответ «да», так как этим свойством обладают все дети, что указано во фрейме «ребенок».

Наследование может быть частичным, так как возраст учеников не наследуется из фрейма «ребенок», так как указан явно в своем собственном фрейме.

Различают статические и динамические системы фреймов.

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

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

Фрейм может быть представлен в виде списка свойств, а если использовать средства БД, то в виде записи.

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

Во фреймовых системах данные о родовидовых связях хранятся явно как и значения других типов.

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

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

Недостатки фреймовых систем: относительно высокая сложность.

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

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

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

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

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

Отношение называется нормализованным или приведенным к первой нормальной форме (1НФ), если все его атрибуты простые или атомарные (далее – неделимые). Отношение, находящееся в первой нормальной форме, будет иметь следующие свойства:

■ в отношении нет одинаковых кортежей;

■ кортежи не упорядочены;

■ атрибуты не упорядочены и различаются по наименованиям;

■ все значения атрибутов атомарные.

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

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

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

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

Множество атрибутов X называется детерминантом функциональной зависимости , а множество атрибутов У – зависимой частью.

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

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

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

Отношение находится во второй нормальной форме (2НФ), если оно находится в первой нормальной форме (1НФ) и нет неключевых атрибутов, зависящих от части составного ключа.

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

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

Отношение находится в третьей нормальной форме (ЗНФ), если оно находится в 2НФ и все неключевые атрибуты взаимно независимы.

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

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

Алгоритм разработки включает в себя три этапа.

Этап I. Приведение к 1НФ. Здесь необходимо определить и задать отношения, отображающие понятия предметной области. Все отношения автоматически находятся в 1НФ.

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

. Ключ– сложный ключ.

– зависимость всех атрибутов от ключа отношения;

– зависимость некоторых атрибутов от части сложного ключа.

– оставшаяся часть исходного отношения;

– новое отношение.

Этап III. Приведение к 3НФ. Если в некоторых отношениях обнаружена зависимость одних неключевых атрибутов от других нсключевых атрибутов, то проводится декомпозиция этих отношений: неключевые атрибуты, которые зависят от других неключевых атрибутов,

образуют отдельное отношение. В новом отношении ключом становится детерминант функциональной зависимости.

Пусть, например, исходное отношение –. К – ключ.

Тогда функциональные зависимости имеют следующий вид:

После декомпозиции отношения получим:

На практике достаточно редко разработка логической модели БД производится по приведенному алгоритму. Чаще используют различные варианты ER-диаграмм, поддерживаемые соответствующими CASE-средствами. Основные понятия ER-диаграмм излагаются в стандартах IDEF1 и IDEF1X. Однако приведенный алгоритм полезен как иллюстрация проблем, которые могут возникать при определении на первых этапах проектирования слабо нормализованных отношений. Понимание этих проблем особенно важно при проведении модификаций и доработок БД, когда вводятся новые сущности, появляются новые зависимости и т.п.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

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

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

18 Февраля, 2015