39013

Информационные системы в управлении

Шпаргалка

Информатика, кибернетика и программирование

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

Русский

2013-09-30

444 KB

31 чел.

1. Место информационной системы в контуре управления.

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

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

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

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

Определим место экономической информационной системы в системе управления объектом.

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

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

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

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

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

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

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

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

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

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

  1.  некоторые виды информации трудно поддаются количественной оценке (склонность к нововведениям);
  2.  ИС способны учитывать только формальные информационные связи и отношения, в то время, как важное значение имеют неформальные контакты.


2. Понятие информации; ценность и полезность информации.

Термин информация происходит от латинского слова informatio, что означает «сведения, разъяснения, изложение».

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

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

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

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

Свойства информации: достоверность, полнота, точность, ценность, своевременность, понятность, доступность, краткость и т. д.

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

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

Точность информации определяется степенью ее близости к реальному состоянию объекта, процесса, явления и т. п.

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

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

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

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

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


3. Существующие подходы к оценке информации; динамические свойства информации.

ДИНАМИЧЕСКИЕ СВОЙСТВА ИНФОРМАЦИИ

  1.  Рост. В результате деятельности людей информация об определенном объекте способна увеличиваться.
  2.  Повторяемость. Информация способна многократно распространяться.
  3.  Старение. С течением времени интенсивность использования информации уменьшается.
  4.  Рассеиваемость. Информация способна рассредотачиваться по различным источникам. Одна и та же информация может быть отражена в различной форме в отчете, в статье, в тезисах.


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


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

Сформулируем главные принципы файловых систем:

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

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

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

Для просмотра данных файла применялись последовательный или произвольный методы доступа.

Ограничения, присущие файловым системам:

1.Разделение и изоляция данных.

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

2.Дублирование данных.

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

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

3.Зависимость от данных.

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

4.Несовместимость файлов.

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

5.Фиксированные запросы / быстрое увеличение числа приложений.

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

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

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

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

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


6. Роль информации и знаний в процессе принятия управленческих решений; сравнение свойств элементов цепочки «данные – информация – знания».


7. Основные положения концепции баз данных; система баз данных; администрирование баз данных.

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

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

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

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

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

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

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

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

Система баз данных (database system) – система специальным образом организованных данных – базы данных, программных, технических, языковых и организационно-методических средств, предназначенных для централизованного накопления и коллективного использования данных.

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

Должностная инструкция.

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

Администратор баз данных: классические подходы.

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

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

Третья группа - администратор приложений (администратор внешних схем) - обеспечивает поддержку базы данных для различных групп пользователей механизма внешнего уровня архитектуры СУБД.

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

Администратор базы данных - это:

управляющий данными, а не хозяин;

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

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


8. Модели данных как инструмент описания предметной области; обобщенная структура модели данных.

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


9. Оценка качества модели данных.

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

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

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

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

Легкость разработки и сопровождения  базы  данных 

Скорость выполнения операций обновления данных (вставка, обновление, удаление кортежей)

Скорость выполнения операций выборки данных

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

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

Состояние базы  данных в каждый момент времени должно соответствовать состоянию предметной области.

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

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

Легкость разработки и сопровождения  базы данных

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

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

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

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

Скорость операций обновления данных.

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

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

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

Скорость операций выборки данных

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


10. Предметная область, построение моделей предметной области.


11. Планирование баз данных; жизненный цикл систем баз данных.

Планирование базы данных.

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

Планирование базы данных обладает существенными достоинствами, которые можно сформулировать следующим образом:

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

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

Жизненный системы баз данных.

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

Фаза анализа и проектирования:

  1.  Формулирование и анализ требований.
  2.  Концептуальное проектирование.
  3.  Проектирование реализации.
  4.  Физическое проектирование.

Фаза реализации и функционирования базы данных:

  1.  Реализация базы данных.
  2.  Анализ функционирования и поддержка.
  3.  Модификация и адаптация.

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

Наиболее трудоемкой и плохо формализуемой является первая фаза ЖЦСБД, которая и будет рассмотрена дальше.

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


12. Определение общих параметров проектируемой системы: цели, критерии.


13. Методика коллективного описания предметной области.

Методика выполнения коллективного анализа и описания предметной области

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

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

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

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

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

Рис. 1. Классическая схема анализа предметной области

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

Определение общих параметров системы

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

Цель процесса разработки является наиболее важным фактором в определении границ применения системы и критериев ее оценки.

Цель – фактор или набор факторов, обуславливающих необходимость реализации данного проекта.

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

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

Критерии могут быть разработаны в одной из следующих формулировок:

  1.  требования, выраженные в единицах изменения (например, если цель - уменьшение времени формирования счета клиента в 2 раза, то критерий – это обеспечении времени формирования счета клиента в течение 5 мин. (по сравнению с 10 мин. до построения системы баз данных);
  2.  критерии, определяемые внешним окружением связаны с вычислительной системой (ОС, СУБД, ПП, с которыми придется взаимодействовать в процессе проектирования; в редких случаях проект по созданию базы данных начинается с «нуля»); кроме этого важно оценить объем обрабатываемых данных как «чистый» объем данных, так и динамику его приращения; фактором оценки критериев этого класса является число пользователей системы (для каждой группы требуются индивидуальные функции со стороны поддержки системы);
  3.  основные направление разработки (например, повысить точность ввода данных, и где это возможно - использовать не прямой ввод данных, а через систему списков). Это критерий невозможно выразить количественно, но игнорировать его также нецелесообразно.

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


14. Методология проектирования баз данных и характеристика ее компонент; основные этапы проектирования баз данных, анализ информационных требований:
UP- и ISP – информация.

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

Целью применения методологии проектирования баз данных является:

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

В отношении проектирования БД созданы и интегрированы методы выполнения таких проектных этапов:

  •  анализ потребностей и описание предметной области (ПрО) с использованием «процессного» и «непроцессного» подходов);
  •  выбор языка представления, так называемой «семантической» модели для фиксации сведений и ПрО, их последующего анализа и синтеза модели БД;
  •  анализ собранных сведений о Про: классификация, формализация и интеграция структурных элементов описания Пр., формализация структурных и процессных ограничений целостности элементов в будущей модели ПрО, определение динамики объектов ПрО;
  •  синтез концептуальной модели базы данных: проектирование модели данных на выбранном языке семантического моделирования;
  •  выбор конкретной модели данных и СУБД для реализации БД;
  •  проектирование логической модели схемы БД;
  •  разработка физической структуры БД, включая размещение БД по узлам в случае распределенной БД;
  •  разработка технологии  и процедур начального создания и заполнения БД;
  •  разработка технологии сопровождения БД;
  •  разработка процедур доступа к данным и интерфейса пользователей;
  •  информационное обеспечение разработки конкретных программ обработки данных: обеспечение метаинформацией и т.д.;
  •  получение обратной связи от пользователей системы, тестирование системы.

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

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

Для достижения указанных выше целей и выполнения задач методология должна включать следующие компоненты:

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

ISP и UP информация.

На этапе описания предметной области необходимым является разделение информационных требований, используемых в процессе проектирования, на два класса:

  1.  информация, касающаяся концептуального структурного представления (ISP -information structure perspective) - описывающаяся реально существующие связи всех данных предметной области и отражающая прообразы реального мира в сущности и связи; приведем пример ISP-информации:

описание объекта (наименование, мощность);

описание атрибута (наименование, длина, диапазон значений, вероятность существование);

описание связи (наименование, определяемые сущности, мощность, отображение, вероятность существования).

  1.  информация, отнесенная к прикладному представлению (UP - usage perspective) - определяющая требования к процедурам обработки данных, актуальным на момент проектирования базы данных; приведем пример UP - информации:

описание процесса (наименование, частота применения, вероятность применения, требуемые данные, объем данных, приоритет);

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

Принято считать, что элементы данных, входящие в UP -информацию, являются подмножеством элементов данных, входящих в ISP - информацию.  База данных, спроектированная на основе ISP - информации, значительно отличается от базы данных, полученной  исходя из требований тип UP. Использование ISP-информации гарантирует, что структура данных обеспечит поддержку любых текущих и перспективных приложений, т.е. обеспечит основу для обработки неформализованных, изменяющихся и неизвестных запросов и приложений. Применение этого подхода обеспечивает гибкость и адаптивность  разрабатываемой информационной системы.  UP- информация иначе воздействует на проектируемую систему: применяя при разработке  характеристики текущих и предполагаемых приложений, позволяет достичь высокоэффективного решения, отражая наиболее часто используемые пути доступа. Применение UP-подхода обеспечивает  эффективность разрабатываемой базы данных, которая может быть реально оценена и измерена. На практике наиболее применяемым подходом является разумное сочетание ISP и UP: IPS -информация используется для построения первоначальной информационной структуры, а UP-информация применима для ее совершенствования с целью повышения эффективности обработки данных.


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


16. Этап концептуального проектирования базы данных; моделирование локальных представлений; принцы объединения локальных представлений.

Концептуальное проектирование. Моделирование и объединение локальных представлений.

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

Моделирование представлений.

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

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

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

 Типами представления являются:

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

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

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

Моделирование проектных представлений состоит из последовательности шагов и завершается построением модели локального представления.

Шаг 1: Идентификация локального представления.

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

Шаг 2:Формулирование сущностей.

Для каждого локального представления происходит определение сущностей, требуемых для описания. На этом этапе необходимо четко сформулировать выделение сущности как конструктивного элемента локального представления и определиться с возможность появления различных категорий сущности. Определение сущностей может выполняться на основе одного из следующих подходов: 1) изучение спецификации по выполнению конкретных функций пользователей, из них извлекаются базовые существительные, объединяемые затем в глобальные понятия (например, номер_сотрудника, фамилия_сотрудника преобразуются в сущность «Сотрудник»); 2) поиск объектов, существующих в предметной области независимо от других. На этом шаге должно быть четко сформулировано наименование сущности и определено общее количество сущностей (правило о 7 информационных кластерах, которыми одновременно может управлять человек).

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

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

Шаг 3:. Выбор идентифицирующего атрибута для каждой сущности.

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

Шаг 4: Спецификация связей.

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

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

Шаг 5: Добавление описательных атрибутов к сущностям.

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

Документирование: описание выделенных атрибутов – имя атрибута, синонимы, тип и размерность атрибута, свойства атрибута (простой или составной, производный и т.п.).

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

Объединение представлений.

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

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

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

 


17. Процедура объединения локальных представлений; реализация этой процедуры средствами
ER Win 4.0

Объединение представлений.

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

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

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

Понятия и принципы объединения:

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

Идентичность.

Говорят, что два элемента идентичны, если они имеют одинаковое семантическое значение.  Способом описания отношения идентичности является объединения двух или более элементов синонимами. Например, «Участник договора», «Клиент» в локальных представлениях могут иметь одинаковую семантическую окраску; в этом случае, необходимо прийти к выбору решения о подборе синонима для глобальной концептуальной модели, который будет заменять эти понятия в локальных представлениях.

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

Агрегация.

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

Обобщение.

В то время как агрегация может быть представлена в виде составных частей, образующих некоторое целое, обобщение связано только с целыми понятиями. Оно относится к абстракции, к которой  группы подобных элементов воспринимаются как родовой объект, а отдельные различия между элементами опускаются. Например, «Ценная бумага» может включать в себя «Акции», «Векселя», «Облигации»;  в этом случае «Ценная бумага» – это обобщение всей группы.  Понятия агрегации и обобщения легко спутать, поскольку элемент может быть одновременно использован как в агрегации, так и в обобщении.

       

  

Рис. 1 Иллюстрация процедуры  объединения на основе обобщения

Типы объединения локальных представлений.

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

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

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

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

Объединение идентичности.

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

Пользователь 1

Пользователь 2

Объединенный результат

А(Х)

В(Х)

F (AB)

где А(Х)=В(Х)=F(AB) – глобальный интегрированный объект.

Объединение агрегации.

Агрегация может встретить в одном из двух своих проявлений:

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

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

Пользователь 1

Пользователь 2

Объединенный результат

А(1), A(2)…A(N)

В(X)

F (B)=F(A(1)),..,F(A(N))

A(1),A(2)…A(N)

B(1),B(2)…B(M)

F(AB)=F(A(1)),..F(A(2)),

F(B(1)),..,F(B(M))

Объединение обобщений.

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

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

Пользователь 1

Пользователь 2

Объединенный результат

А(1), A(2)…A(N)

В(X)

F(B)=ТИП=F(A(1)),..,

F(A(N))

A(1),A(2)…A(N)

B(1),B(2)…B(M)

F(AB)=ТИП=F(A(1)),..F(A(2)),

F(B(1)),..,F(B(M))

Процесс объединения.

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

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

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

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

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

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


18. Этап логического проектирования базы данных и его реализация в
ER Win 4.0; алгоритм перехода от ER-модели к реляционной модели; генерация схем баз данных.


19.
ER – модель в нотации П. Чена; нотация IDEF1X в среде ER Win 4.0.

Предназначение   IDEF1X   

Метод IDEF1, разработанный Т.Рэмей (T.Ramey), также основан на подходе П.Чена и позволяет построить модель данных, эквивалентную реляционной модели в третьей нормальной форме. В настоящее время на основе совершенствования методологии IDEF1 создана ее новая версия - методология  IDEF1X .  IDEF1X  разработана с учетом таких требований, как простота изучения и возможность автоматизации.  IDEF1X -диаграммы используются рядом распространенных CASE-средств (в частности, ERwin, Design/IDEF).  

IDEF1X   является методом для разработки реляционных баз данных и использует условный синтаксис, специально разработанный для удобного построения концептуальной схемы. Концептуальной схемой мы называем универсальное представление структуры данных в рамках коммерческого предприятия, независимое от конечной реализации базы данных и аппаратной платформы. Будучи статическим методом разработки,   IDEF1X   изначально не предназначен для динамического анализа по принципу "AS IS", тем не менее, он иногда применяется в этом качестве, как альтернатива методу IDEF1. Использование метода   IDEF1X   наиболее целесообразно для построения логической структуры базы данных после того, как все информационные ресурсы исследованы (скажем с помощью метода IDEF1) и решение о внедрении реляционной базы данных, как части корпоративной информационной системы, было принято. Однако не стоит забывать, что средства моделирования   IDEF1X   специально разработаны для построения реляционных информационных систем, и если существует необходимость проектирования другой системы, скажем объектно-ориентированной, то лучше избрать другие методы моделирования.

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

Концепция и семантика IDEF1X  

Сущности в   IDEF1X   и их атрибуты.

Хотя терминология   IDEF1X  практически совпадает с терминологией IDEF1, существует ряд фундаментальных отличий в теоретических концепциях этих методологий. Сущность в   IDEF1X  описывает собой совокупность или набор экземпляров похожих по свойствам, но однозначно отличаемых друг от друга по одному или нескольким признакам. Каждый экземпляр является реализацией сущности. Таким образом, сущность в   IDEF1X   описывает конкретный набор экземпляров реального мира, в отличие от сущности в IDEF1, которая представляет собой абстрактный набор информационных отображений реального мира. Примером сущности   IDEF1X  может быть сущность "СОТРУДНИК", которая представляет собой всех сотрудников предприятия, а один из них, скажем, Иванов Петр Сергеевич, является конкретной реализацией этой сущности. В примере, приведенном на рис. 1, каждый экземпляр сущности СОТРУДНИК содержит следующую информацию: ID сотрудника, имя сотрудника, адрес сотрудника и т.п. В   IDEF1X   модели эти свойства называются атрибутами сущности. Каждый атрибут содержит только часть информации о сущности.

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

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

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

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

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

Рис. 1. Мощность связи

Ниже приведен ряд примеров связи между сущностями:

Отдел <состоит из> нескольких Сотрудников

Самолет <перевозит> нескольких Пассажиров.

Сотрудник <пишет> разные Отчеты.

Рис. 2 Пример отображения связи в ERWin

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

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

Идентификация сущностей. Представление о ключах.

Сущность описывается в диаграмме  IDEF1X  графическим объектом в виде прямоугольника. На рис.3 приведен пример   IDEF1X   диаграммы. Каждый прямоугольник, отображающий собой сущность, разделяется горизонтальной линией на часть, в которой расположены ключевые поля и часть, где расположены неключевые поля. Верхняя часть называется ключевой областью, а нижняя часть областью данных. Ключевая область объекта СОТРУДНИК содержит поле "Уникальный идентификатор сотрудника", в области данных находятся поля "Имя сотрудника", "Адрес сотрудника", "Телефон сотрудника" и т.д.

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

Рис.3 Пример IDEF1X диаграммы

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

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

Например, для того, чтобы корректно использовать сущность СОТРУДНИК в  IDEF1X   модели данных (а позже в базе данных), необходимо иметь возможность уникально идентифицировать записи. Правила, по которым вы выбираете первичный ключ из списка предполагаемых ключей, очень строги, однако могут быть применены ко всем типам баз данных и информации. Правила устанавливают, что атрибуты и группы атрибутов должны:

  •  Уникальным образом идентифицировать экземпляр сущности.
  •  Не использовать NULL значений.
  •  Не изменяться со временем. Экземпляр идентифицируется при помощи ключа. При изменении ключа, соответственно меняется экземпляр.
  •  Быть как можно более короткими для использования индексирования и получения данных. Если вам нужно использовать ключ, являющийся комбинацией ключей из других сущностей, убедитесь в том, что каждая из частей ключа соответствует правилам.

Для наглядного представления о том, как целесообразно выбирать первичные ключи, приведем следующий пример - выберем первичный ключ для знакомой нам сущности "СОТРУДНИК":

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

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

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

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

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

Рис. 4  Примеры внешних ключей

Классификация сущностей в  IDEF1X. Зависимые и независимые сущности.

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

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

Зависимые сущности далее классифицируются на сущности, которые не могут существовать без родительской сущности и сущности, которые не могут быть идентифицированы без использования ключа родителя (сущности, зависящие от идентификации). Сущность СОТРУДНИК принадлежит ко второму типу зависимых сущностей, так как сотрудники могут существовать и без отдела.

Напротив, существуют ситуации в которых сущность зависит от существования другой сущности. Рассмотрим две сущности: ЗАПРОС, используемый для отслеживания запросов покупателей, и ПОЗИЦИЯ ЗАПРОСА, который отслеживает отдельные элементы в ЗАПРОСе. Связь между этими двумя сущностями может быть выражена в виде ЗАПРОС <содержит> один или несколько ПОЗИЦИЙ ЗАПРОСА. В этом случае, ПОЗИЦИЯ ЗАПРОСА зависит от существования ЗАКАЗА.

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

Типы связей между сущностями. Идентифицирующие и неидентифицирующие связи.

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

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

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

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

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

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

Так как переданные ключи в неидентифицирующей связи не являются составной частью первичного ключа дочерней сущности, то этот вид связи не проявляется ни в одной идентифицирующей зависимости. В этом случае и ОТДЕЛ, и СОТРУДНИК рассматриваются как независимые сущности.

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

Преимущества  IDEF1X 

Основным преимуществом  IDEF1X , по сравнению с другими многочисленными методами разработки реляционных баз данных, такими как ER и ENALIM является жесткая и строгая стандартизация моделирования. Установленные стандарты позволяют избежать различной трактовки построенной модели, которая, несомненно, является значительным недостатком ER.


20. Логические модели данных; сетевая и иерархическая модели данных.


21. Характеристика реляционной модели; оценка положительных и отрицательных свойств.

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

Преимущества реляционного подхода.

«Реляционная технология до некоторой степени упрощает задачу обработки и хранения информации в трех различных направлениях»:

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

Можно выделить и другие несомненные достоинства реляционного подхода:

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

Проблемы реализации реляционного подхода.

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


22. Структура данных и ограничения целостности и операции над данными в реляционной модели.

 

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

 Отношение на доменах состоит из заголовка  (heading) и тела (body). Заголовок состоит из фиксированного множества атрибутов такого, что каждому атрибуту соответствует в точности один домен. Тело состоит из меняющегося со временем конечного множества кортежей.

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

Полное описание реляционной базы данных задается реляционной схемой, состоящей из одной или нескольких схем отношений.

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

Фундаментальные свойства отношений.

отсутствие дубликатов-кортежей, что вытекает из определения первичного ключа отношения;

отсутствие упорядоченности кортежей - является следствием определения отношения как множества кортежей;

отсутствие упорядоченности атрибутов - поскольку по определению схема есть множество пар «имя атрибута, имя домена»;

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

Ограничения целостности.

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

  1.  Уникальность. Для всякой пары кортежей отношения R найдется хотя бы один атрибут из множества К, значения которого в этой паре  кортежей различны.

Минимальность. Ни один из Ai, Aj, .., Ak не может быть удален из К без нарушения требования уникальности.

 Правила целостности.

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

Целостность согласования (целостность по ссылкам) (referential integrity). Если отношение R2 включает внешний ключ FK, соответствующий первичному ключу PK базового отношения  R1, то каждое значение FK в R2 должно быть равным значению PK в некотором кортеже R1, либо быть полностью пустым. Существуют три подхода, обеспечивающие поддержку целостности по согласованию (ссылкам):

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

Операции над данными в реляционных отношениях.

Основу средств манипулирования реляционными данными составляет набор операторов, известных под общим названием реляционная алгебра.

Название операции

Обозначение операции

Определение операции

Условия реализации

Объединение

R=R1 R2

Множество кортежей, принадлежавших R1 и R2, либо им обоим

Одинаковая арность R1 и R2; отношение итоговое (R) той же арности

Разность

R=R1 \ R2

Множество кортежей, принадлежащих R1, но не принадлежащих R2

то же

Пересечение

R=R1 R2

Множество кортежей, принадлежащих R1 и R2

то же

Декартово произведение

R=R1 R2

R- множество кортежей арности (k1+k2), причем первые k1 элементов образуют кортеж из R1, последние k2 – из R2

при k1- арность R1, k2R2

Проекция

R= Пi1,…,ik (R1),

где i1,…, ik -номера столбцов R1

Выборка из отношения указанных столбцов и компановка их в указанном порядке

Частное

R=R1 R2

Подмножество кортежей P-арности (k1-k2) таких, что для всех кортежей n-арности k2, принадлежащих R2, кортеж Pn принадлежит R1

при k1- арность R1, k2 – арность R2,

k1>k2, k2>0

Селекция

R= f (R1) *

Подмножество кортежей R1, для которых значения выделенных атрибутов определены f

Соединение

R=R1 ><R2

Комбинация двух отношений по общим атрибутам

R1 R2


23. Нормализация отношений: критерии соответствия, методика выполнения процедуры нормализации.

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

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

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

Атомарное значение атрибута – значение, не являющееся множеством значений или повторяющейся группой.

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

Поставки (П#, Товар, Количество)

Цена товара (Товар, Цена)

Третья нормальная форма (3НФ). 

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

Хранение (Фирма,  Склад)

С _ Объем (Склад, Объем)

Нормальная форма Бойса-Кодда (НФБК). 

Отношение находится в нормальной форме Бойса-Кодда тогда и только тогда, когда для любой нетривиальной зависимости XY между атрибутами отношения R, множество атрибутов Х .

Четвертая нормальная форма (4НФ).  Отношение находится в 4НФ, если оно находится в НФ Бойса-Кодда, но в нем отсутствуют многозначные зависимости, которые не являются функциональными.

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


24. Критерии оценки нормализованных и ненормализованных моделей данных; декомпозиция без потерь.

Критерий

Отношения слабо нормализованы
(1НФ, 2НФ)

Отношения сильно нормализованы
(3НФ)

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

ХУЖЕ (-)

ЛУЧШЕ (+)

Легкость разработки и сопровождения базы данных

СЛОЖНЕЕ (-)

ЛЕГЧЕ (+)

Скорость выполнения вставки, обновления, удаления

МЕДЛЕННЕЕ (-)

БЫСТРЕЕ (+)

Скорость выполнения выборки данных

БЫСТРЕЕ (+)

МЕДЛЕННЕЕ (-)

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

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


25. Проблемы реализации реляционного подхода; будущее реляционной модели представления данных.

Проблемы реализации реляционного подхода.

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

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

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

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

Будущее реляционной технологии.

Скорее всего, реляционные базы данных сохранят свои позиции, хотя время формирует новые тенденции в управлении информацией. Представители компаний Informix, Ingres, IBM и Oracle, которые одними из первых начали разрабатывать технологии реляционных баз данных, обсудили перспективы и исторические тенденции в области управления данными, нашедшие отражение в работе Э. Кодда, отца реляционного исчисления.

Все большее распространение будет приобретать управление бизнес-процессами. Как отметил Роджер Сиппл, основатель Informix, сейчас Web-службы представляют собой надстройку над бизнес-логикой, но они кардинальным образом изменят структуру бизнес-процессов.

«Я думаю, что для этого будет создана простая и мощная модель, — сказал Сиппл. — Она окажет серьезное влияние на реляционную базу данных».

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

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

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

«Вы можете делать практически все в реляционной модели, и дополнения к ней не нужны, — уверен Дейт. — Мне кажется, что бизнес-правила полностью совместимы с реляционной моделью».

Подчеркивая важность реляционной технологии, Майкл Стоунбрейкер, основатель компаний Ingres и Illustra, занимавший также руководящие посты в корпорации Informix, сказал: «Модели, сравнимые с предложениями Кодда, появляются далеко не каждый день.

М. Стоунбрейкер также предостерег тех, кто считает, что Web-службы станут доминирующей технологией в области интеграции данных. «Сейчас все буквально поклоняются Web-службам, но я бы посоветовал всерьез задуматься о том, действительно ли Web-службы покорят мир», — заметил Стоунбрейкер. По его словам, распространению Web-служб будут препятствовать пока не решенные вопросы, в частности семантика записей. Например, запись о зарплате на одном предприятии может быть определена иначе, чем на другом.

«Вопросы семантики моментально докажут неполноту механизма Web-служб, как только вы выйдете за границы обычной электронной почты, которая, по существу, базируется на простых текстах», — отметил Стоунбрейкер.

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


26. Место СУБД в системе информационного обслуживания управленческой деятельности; эволюция развития СУБД; функциональная структура СУБД.

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

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

К числу функций СУБД принято относить следующее:

  1.  управление данными во внешней памяти;
  2.  управление буферами оперативной памяти;
  3.  управление транзакциями;
  4.  журнализация и восстановление базы данных после  сбоев;
  5.  поддержание языков баз данных.

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

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

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

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

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


27. Общая характеристика языковых средств СУБД; характеристика языков
QBE и SQL; характеристика основных стандартов языка SQL.

Общая характеристика языков баз данных.

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

Языковые средства используются для выполнения следующих функций:

  1.  для описания представления базы данных на управляемых уровнях архитектуры системы;
  2.  для инициирования выполнения операций манипулирования данными;
  3.  для управления  данными.

Первая из этих функций обеспечивается языком описания данных (ЯОД)- Shema Definition Language. Его часто называют языком определения данных. Описание данных средствами ЯОД называют схемой базы данных.  Оно включает описание логической структуры данных и налагаемых на нее ограничений целостности в рамках тех правил, которые регламентированы моделью данных используемой СУБД.

 Язык манипулирования данными  (ЯМД)- Shema Manipulation Language позволяет запрашивать предусмотренные в системе операции над данными из базы данных, т.е. содержит набор операторов манипулирования данными, позволяющий заносить данные, удалять, модифицировать или выбирать их.

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

Язык QBE (Query-By-Example).

В QBE фундаментальными являются две концепции: 1) программирование осуществляется посредством двумерных таблиц-шаблонов;  это достигается заполнением соответствующих полей таблицы в примере решения; 2) проводится различие между постоянным элементом и элементом примера.   

Язык SQL  - фактический стандарт для реляционных  СУБД.

Сами по себе данные в компьютерной форме не представляют интерес для пользователя, если отсутствуют средства доступа к ним. Доступ осуществляется в виде запросов, которые формулируются на стандартном языке запросов. Сегодня для большинства СУБД таким языком является SQL.

Основные операторы языка SQL.

Data Definition Language (DDL).

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

Data Manipulation Language (DML).

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

Transaction Control Language (TCL).

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

Data Control Language (DCL).

Операторы Data Control Language применяются для осуществления административных функций, присваивающих или отменяющих право (привилегию) использовать базу данных, таблицу базы данных, а также выполнять те или иные операторы SQL.


28. Схема обработки стандартного запроса в СУБД; особенности обработки распределенного запроса в СУБД.

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

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

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

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

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

Современные тенденции в технологии оптимизации запросов.

Рассмотренный ранее метод, получивший название «метода затрат» обеспечивал выполнение операций поиска в реляционных СУБД с минимальным использованием компьютерных ресурсов за счет определения наиболее эффективных методов и маршрутов доступа. В настоящее время реализуется проект, получивший название Learning Optimizer (LEO)(корпорация IBM), который должен перевести оптимизацию на некоторый качественно новый уровень.

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


29. Общая характеристика управления транзакциями в многопользовательских СУБД.

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

Транзакции и целостность баз данных.

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

Если же в процессе работы случилось нечто, что делает выполнение транзакции невозможным, база данных возвращается в исходное состояние. Откат транзакции (roll back)- это действие, обеспечивающее аннулирование всех изменений данных, которые были сделаны операторами SQL в теле текущей незавершенной транзакции.

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

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

Параллельное выполнение транзакций.

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


30. Сериализация транзакций и тупиковые ситуации.

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

Данная дисциплина опирается на следующие правила:

  1.  В процессе выполнения транзакции программа «видит» только согласованные состояния базы данных; пользователь никогда не может получить доступ к незафиксированным изменениям в данных, достигнутым в результате действия другой программы;
  2.  Если две транзакции А и В выполняются параллельно, то СУБД полагает, что результат будет такой же, как если бы: - транзакция А выполнялась бы первой, а за ней - выполнялась другая транзакция В, т.е. последовательно.

Методы сериализации транзакций.

Существует два базовых подхода к сериализации транзакций: подход, метод, основанный на синхронизационных захватах (блокировках) объектов базы данных, и подход, основанный на использовании временных меток.

Синхронизационные блокировки.

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

Основными режимами синхронизационных захватов (блокировок) являются:

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

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

Тупиковые ситуации (dead-locks).

Одним из наиболее чувствительных недостатков метода сериализации транзакций на основе синхронизационных захватов является возникновение тупиков (взаимных блокировок) (dead - locks) между транзакциями.

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

Метод временных меток.

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

Основная идея метода состоит в следующем: если транзакция Т1 началась раньше транзакции Т2, то система обеспечивает такой режим выполнения, как если бы Т1 была целиком выполнена да начала Т2.

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


31. Понятие информационной безопасности в СУБД; средства управления доступом в СУБД.

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

Защита баз данных предусматривает предотвращение любых преднамеренных и непреднамеренных угроз с использованием компьютерных и некомпьютерных средств контроля. Следует также защищать:

современные информационные системы;

глобальную связанность (выход в Internet);

разнородность (различные платформы);

технологию «клиент-сервер».

Программно-технический аспект информационной безопасности.

1. аутентификация и идентичность;

2. управление доступом;

3. поддержка целостности;

4. протоколирование и аудит;

5. защита коммуникаций между клиентом и сервером;

  1.  отражение угроз, специфичных для СУБД.

Аутентификация и идентичность.

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

Управление доступом.

После получения права доступа к СУБД пользователь автоматически получает привилегии, связанные с его идентификатором.

Привилегии в СУБД могут быть разделены на две категории: привилегии безопасности и привилегии доступа. Привилегии безопасности позволяют выполнять административные действия, привилегии доступа  определяют права доступа субъектов к определенным объектам.

Привилегии доступа выделяются пользователям, ролям, группам ил всем посредством оператора  GRANT (привилегии отменяются оператором REVOKE); как правило, эти привилегии присваивает владелец соответствующих объектов.

Оператор GRANT позволяет реализовать следующие виды ограничений доступа:

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

Управление доступом базируется на реализации следующего минимального набора действий:

произвольное управление доступом;

обеспечение безопасности повторного использования объектов;

использование меток безопасности;

принудительное управление доступом.

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

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

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

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


32. Обеспечение целостности системы баз данных; триггеры и хранимые процедуры в СУБД.

Поддержка целостности.

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

ограничения;

правила.

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

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

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

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

 

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

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


33. Критерии выбора СУБД.

Важным этапом жизненного цикла приложений баз данных является выбор СУБД.

Основные мероприятия при выборе СУБД:

  1.  определение области компетенции проводимого изучения;
  2.  сокращение списка претендентов до двух-трех продуктов;
  3.  оценка продуктов;
  4.  проведение обоснованного выбора и подготовка отчета.

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

Сокращение списка претендентов до 2-3 продуктов.

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

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


36. Технология хранилищ данных: основные положения и допущения. Модели данных для хранилищ данных.

Понятие хранилищ данных

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

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

7. Свойства хранилищ данных

(1) Предметная ориентация

В отличие от БД в традиционных OLTP-системах, где данные подобраны в соответствии с конкретными приложениями, информация в DW ориентирована на задачи поддержки принятия решений. Для системы поддержки принятия решений требуются "исторические" данные - факты продаж за определенные интервалы времени. Хорошо спроектированные структуры данных DW отражают развитие всех направлений бизнеса компании во времени.

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

(2) Интегрированность данных

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

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

(3) Инвариантность во времени

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

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

(4) Неразрушаемость - cтабильность информации

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

(5) Минимизация избыточности информации

Поскольку информация в DW загружается из OLTP-систем, возникает вопрос, не ведет ли это к чрезмерной избыточности данных? Нет, утверждает Билл Инмон. На самом деле избыточность минимальна (около 1%!), что объясняется следующими причинами:

  •  при загрузке информации из OLTP-cистем в DW данные фильтруются. Многие из них вообще не попадают в DW, поскольку лишены смысла с точки зрения использования в системах поддержки принятия решений;
  •  информация в OLTP-системах носит, как правило, оперативный характер, и данные, потеряв актуальность, удаляются. В DW, напротив, хранится историческая информация, и с этой точки зрения перекрытие содержимого DW данными OLTP- систем оказывается весьма незначительным;
  •  в DW хранится некая итоговая информация, которая в базах данных OLTP-систем вообще отсутствует;
  •  во время загрузки в DW записи сортируются, очищаются от ненужной информации и приводят к единому формату. После такой обработки это уже совсем другие данные.
  •  


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

Системы баз знаний – системы, которые имитируют человеческий интеллект.

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

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

Когнитивное моделирование – методика моделирования человеческого процесса познания.

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

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

Знания имеют разные уровни:

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

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

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

Мышление, решение задач и рассуждение – пути развития применения человеческих знаний.

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

Решение задач – переход из первоначального состояния в желаемое.

При решении задачи человек использует 4 вида рассуждений:

  1.  Рассуждение с привлечением здравого смысла – основано на индивидуально опыте и фактах, усвоенных человеком за его жизнь; базы знаний не работают с таким видом рассуждений из-за его сложности; исключение составляет эвристический поиск, разновидность эмпирических правил, с помощью которого можно исключить наименее вероятные альтернативы.
  2.  Рассуждение с привлечением аналогий – современные базы знаний не используют этот вид рассуждений, поскольку они основаны на сравнении рассматриваемой задачи с уже известными и принятым стандартом поведения в аналогичной ситуации; поведение аналогий связано со способностью распознавать сходство ситуации с прошлым опытом.
  3.  Дедуктивное рассуждение - в основе лежат логические цепочки, построенные на предпосылках, ведущих к заключениям; при дедуктивном рассуждении вывод идет от общего к частному; предпосылки состоят из истинных утверждений и правил. Используя общие факты, человек приходит к какому-то заключению или выбирает направление деятельности.
  4.  Индуктивное рассуждение – идет от частного к общему; при интерпретации логики, которая описывает имевшие место факты, индукция основывается на подходе наилучшей догадки.

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


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

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

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

Большинство экспертных систем имеют 3 общих компонента:

  1.  базу знаний
  2.  механизм выработки решений
  3.  управляющую программу.

База знаний – основной элемент, состоит из декларативных и процедурных знаний.

Управляющая программа – процедура, контролирующая процесс рассуждения, проводимый на базе знаний.

Механизм выработки решения – пользовательский интерфейс и средства объяснения хода рассуждения.

ЭС нашли применение и уже активно используются в следующих отраслях:

  1.  бухгалтерский учет и управление финансами – разрешение на предоставлении кредитов, консультации по вопросам налогообложения и инвестиций.
  2.  стратегия – консультация юристов по поводу планирования приобретений; планирование проекта; анализ результатов.
  3.  производство - процессы мониторинга и контролирования качества продукции; анализ неисправностей в больших системах; планирование размещения оборудования.
  4.  HRM - обучение в отдельных областях; определение квалификации кандидатов на получение должности.
  5.  маркетинг – определение приемлемых скидок для покупателей, выбор модели долгосрочного прогнозирования сбыта.


41. База знаний: структура, состав хранимых знаний, свойства знаний.

База знаний – обязательная составляющая любой экспертной системы.

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

Структура знаний ЭС:

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

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

Интерпретируемые знания (управляющий компонент не способен интерпретировать) можно разделить на следующие виды:

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

Основные свойства базы знаний ЭС:

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

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


42. Управляющий компонент экспертных систем.

Общая схема управляющего компонента ЭС (интерпретатора, механизма вывода):

Задача механизма вывода – определить на основании текущего состояния рабочей памяти (РП) какой модель и с какими данными будет работать.

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

Этапы работы интерпретатора в каждом цикле

  1.  Выборка.
  2.  Сопоставление.
  3.  Разрешение конфликтов.
  4.  Выполнение.

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

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

Выборка – определение подмножества РП и БЗн, которые будут участвовать в текущем цикле работы системы.

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

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

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

Стратегии:

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


44. Методы приобретения знаний: сравнительный анализ.

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

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

Обучение без выводов.

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

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

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

Приобретение знаний на метауровне

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

Приобретение знаний из примеров.

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

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

1. Параметрическое обучение

2. Обучение по аналогии

3. Обучение по индукции.

Параметрическое обучение.

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

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

Метод обучения по индукции.

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

Обучение по аналогии.

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

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


46. Модели представления знаний: сравнительный анализ.

Production rules – Представление знаний, основанное на продукционных правилах

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

ЕСЛИ  условие (событие)

  ТО действие (событие))

Семантические сети

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

Фреймы.

Фрейм - это структурированный набор информации о свойствах, характеристиках и возможностях объекта, акта или события. Фрейм выступает в роли шаблона для хранения связанных наборов данных. Эти данные обычно хранятся в ячейках. Ячейки это простые атрибуты объекта.

Логическое представление

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

Схема представления

Преимущества

Недостатки

Правила представления

Модульность, гибкость, хорошо подходит для описания многих областей знаний.

Сложности с естественным представлением описательных знаний. Трудности в разделении предметных знаний и проблеморазрешающих знаний

Логики

Точность. Заключение гарантированно верно если утверждение верно. Позволяет программам бытьдекларативными, напр. PROLOG

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

Семантические сети

Представление основано на объектах и поддерживает механизм наследования

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

Фреймы

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

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


47. Методология разработки экспертных систем.

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

Этап идентификации

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

Этап концептуализации

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

Этап формализации

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

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

Этап выполнения

Цель этого этапа — создание одного или нескольких прототипов ЭС, решающих требуемые задачи. Затем на данном этапе по результатам тестирования и опытной эксплуатации создается конечный продукт, пригодный для промышленного использования.

Этап тестирования

В ходе данного этапа производится оценка выбранного способа представления знаний в ЭС в целом.

Этап опытной эксплуатации

На этом этапе проверяется пригодность ЭС для конечного пользователя.

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


49. Эвристический поиск в экспертных системах.

Методы поиска в глубину / ширину называют «слепым» поиском, т.к. в них не определен порядок раскрытия вершины, и этот порядок не зависит от расположения цели. Стремление к уменьшению времени поиска привело к формулированию эвристик, т.е. использованию некой информации о предметной области, сужающей пространство поиска в графе G c целью выбора только тех путей, которые с максимальной вероятностью приводят к цели.

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


Данные

Рабочая память

Интерпретатор

Память состояний

Образцы

Модули (правила)

Модели поиска

В одном пространстве состояний

В иерархических пространствах

При неточных и неполных данных

Использующие несколько моделей

Поиск в пространстве состояний

Поиск методом редукции

Эвристический поиск

Поиск «генерация-проверка»

Поиск в факторизованном пространстве

Поиск в фиксированном пространстве

Поиск в изменяющемся множестве иерархических пространств

Метапространства в иерархии пространств

ринцип наименьших свершений

Методы приобретения знаний

Обучение без выводов

Обучение на примерах

Приобретение знаний на метауровне

Эмитент

Построение концептуальной модели предметной области

Построение, анализ и преобразование функциональной модели

Номинальная стоимость

Ценная бумага

Облигация

Акция


 

А также другие работы, которые могут Вас заинтересовать

46932. Профессиональные риски в СР. Проблемы профессионального здоровья специалиста, пути его сохранения и совершенствования 37.5 KB
  Проблемы профессионального здоровья специалиста пути его сохранения и совершенствования. Важнейшая задача органов управления в ведении которых находятся социальные службы и учебные центры осуществляющие подготовку и переподготовку социальных работников не столько содействие им в профессиональном развитии и продвижении по службе а сохранение здоровья социальных работников профилактика их профессиональных заболеваний проведение консультаций относительно профессиональных рисков в социальной работе. Важную роль в освоении профессии...
46935. ДОСЛІДЖЕННЯ ПРОГРАМИ ФІЗИЧНОГО ВИХОВАННЯ ДЛЯ 5-9 КЛАСІВ СПЕЦІАЛЬНОГО ЗАГАЛЬНОГО ЗАКЛАДУ ДЛЯ СЛІПИХ ДІТЕЙ 240.5 KB
  Розглянути особливості проведення занять з дітьми з особливими потребами. Вивчити особливості корекційних занять з дітьми з особливими потребами. Узагальнити дані науково-дослідницької роботи по впровадженню корекційних вправ в процесі фізичного виховання дітей шкільного віку. Проаналізувати особливості фізичного виховання дітей-інвалідів.
46937. Сущность экологических проблем. Причины возникновения, пути решения 37.93 KB
  Рост потребления природных ресурсов сопровождается с одной стороны истощением природы с другой увеличением масштабов образования отходов. тонн только твердых отходов в том числе 80 млрд. Особую тревогу вызывает рост складируемых токсичных отходов количество которых достигло 2 млрд. тонн ежегодно образующихся токсичных отходов используется и обезвреживается только одна треть.
46938. Информационная война 38.52 KB
  Informtion wr термин имеющий два значения. Воздействие на гражданское население и или военнослужащих другого государства путём распространения определённой информации. Целенаправленные действия предпринятые для достижения информационного превосходства путём нанесения ущерба информации информационным процессам и информационным системам противника при одновременной защите собственной информации информационных процессов и информационных систем. Шварценберг уточняет что процесс передачи политической информации происходит от одной...
46939. Современная книгоиздательская система России: структура, основные виды издательств, федеральные ведомства в структуре издательского дела 38 KB
  На современном этапе издательская система включает в себя: Государственные структуры управления: Министерство культуры и массовых коммуникаций РФ Федеральное агентство по печати и массовым коммуникациям РКП Предприятия: Издательства Полиграфические Торговли и распространения издательской продукции Библиотеки Общественные организации: Издательские Полиграфические Торговли и распространения издательской продукции Библиотечные Книголюбов Основные виды издательств. Федеральные ведомства в структуре издательского дела Отрасль...