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

ЛИЧНЫЙ КАБИНЕТ 

 

Здравствуйте гость!

 

Логин:

Пароль:

 

Запомнить

 

 

Забыли пароль? Регистрация

Повышение уникальности

Предлагаем нашим посетителям воспользоваться бесплатным программным обеспечением «StudentHelp», которое позволит вам всего за несколько минут, выполнить повышение уникальности любого файла в формате MS Word. После такого повышения уникальности, ваша работа легко пройдете проверку в системах антиплагиат вуз, antiplagiat.ru, etxt.ru или advego.ru. Программа «StudentHelp» работает по уникальной технологии и при повышении уникальности не вставляет в текст скрытых символов, и даже если препод скопирует текст в блокнот – не увидит ни каких отличий от текста в Word файле.

Результат поиска


Наименование:


Лекции Лекции по "Информационные системы"

Информация:

Тип работы: Лекции. Добавлен: 27.06.2012. Сдан: 2011. Страниц: 18. Уникальность по antiplagiat.ru: < 30%

Описание (план):


Курс  лекций по дисциплине «Информационные  системы»

  Введение. Понятие о информационных технологиях и информационных системах (ИС).

Информация, данные, знания.

   Информация (от лат. Informatio – объяснение) - любые сведения о каком - либо событии, сущности, процессе и т.п., являющиеся объектом некоторых операций: восприятия, передачи, преобразования, хранения и использования, для которых существует содержательная интерпретация. Следовательно, для восприятия информации необходима некоторая воспринимающая система, которая может интерпретировать ее, в том числе преобразовывать, определять соответствие определенным правилам и т.п.
   Информация  используется во всех областях человеческой деятельности; любая взаимосвязь  и координация действий возможны только благодаря информации. 
   Данные относятся к способу представления, хранения и элементарным операциям обработки информации. Прежде всего, данные - это носитель информации. Образно говоря, данные - это текст в некотом алфавите, а информация - это рассказ (сообщение, информация), имеющая определенный смысл. Для определения понятия данных представим некоторую абстрактную ситуацию:
Имеются:
    некоторая система (событие, процесс), информация о которой представляет интерес;
    наблюдатель, способный воспринимать состояния системы и в определенной форме фиксировать их в своей памяти;
   Тогда говорят, что в памяти наблюдателя  находятся “данные”, описывающие  состояние системы. В общем случае таким наблюдателем является информационная система.
   Т.о. “данные” можно определить как информацию, фиксированную в определенной форме, пригодной для последующей обработки, хранения и передачи информационной системой. 
   Кроме информации и данных существуют также  знания. Знания - это такая информация, к которой применяются алгоритмы логического вывода, позволяющие получить новую информацию. Например, Вы разговариваете с Вашей девушкой, и ее ИС сообщает вам следующую информацию:
      Она завтра совершенно свободна;
      Ей скучно;
      На улице отличная погода.
   А далее Вы, используя эту информацию (как знания!) генерируете новую информацию, которая зависит от той информации, которая хранится в Вашей ИС. В результате логического анализа Вы делаете вывод, что она не прочь где-нибудь погулять с Вами и на основе другой, имеющейся у Вас информации предлагаете шашлыки на природе в веселой компании.
Существуют  три аспекта работы с данными (д): 
    определение д,
    манипулирование (обработка) д,
    управление д (администрирование д).
   
   Под информационной технологией (ИТ) будем понимать некоторый процесс, который схематически (в нотации международного стандарта IDEF0) можно представить так:

Рис. 1. 
   Т.е. как на входе так и на выходе ИТ мы имеем не материю или энергию, а информацию ( от лат. Informatio – объяснение). Технология же происходит от греческого Techno – мастерство, искусство.
   В уже достаточно долгой истории компьютерной индустрии (в 1997г. был 50-летний юбилей) всегда можно было выделить два основных направления: вычисления и накопление и поиск информации. Как известно, возникновение компьютеров главным образом стимулировалось необходимостью проведения трудоемких расчетов для создания ядерного оружия и ракетной техники. Объемы требуемых вычислений просто не позволяли произвести их в приемлемое время традиционным коллективом расчетчиков. Итак, первыми пользователями компьютеров и разработчиками компьютерных программ стали вычислительные математики. До сих пор многие представители старшего поколения программистов предпочитают называть себя математиками (или прикладными математиками), даже если в последние 20-30 лет им не пришлось написать хотя бы одну вычислительную программу, не говоря уже о разработке методов и алгоритмов компьютерных вычислений.
   Однако  почти сразу на появление компьютеров  обратили внимание бизнесмены. Как правило, в экономике не требуются массивные расчеты. В распространенных видах гражданского бизнеса (банковское дело, биржевые операции, системы резервирования билетов или мест в гостиницах) основной проблемой всегда являлись объемы информации, которые необходимо собирать, надежно хранить и оперативно обрабатывать. Появление информационных систем, основным назначением которых является решение отмеченной проблемы, явилось ответом компьютерной индустрии в основном на требования мира бизнеса.
   Наш курс посвящен именно вопросам хранения, поиска, организации данных и информации в автоматизированных информационных системах, а не вычислениям.

Особенности информационных систем

   В зависимости от конкретной области  применения информационные системы  могут сильно различаться по своим функциям, архитектуре, реализации. Однако можно выделить, по крайней мере, два свойства, которые являются общими для всех информационных систем.
   Во-первых, любая информационная система предназначена для сбора, хранения и обработки информации. Поэтому в основе любой информационной системы лежит среда хранения и доступа к данным. Среда должна обеспечивать уровень надежности хранения и эффективность доступа, соответствующие области применения информационной системы. Заметим, что в вычислительных программных системах наличие такой среды не является обязательным. Основным требованием к программе, выполняющей численные расчеты (если, конечно, говорить о решении действительно серьезных задач), является ее быстродействие. Нужно, чтобы программа произвела достаточно точные результаты за установленное время. При решении серьезных вычислительных задач даже на суперкомпьютерах это время может измеряться неделями, а иногда и месяцами. Поэтому программисты-вычислители всегда очень скептически относятся к хранению данных во внешней памяти, предпочитая так организовывать программу, чтобы в течение как можно более долгого времени обрабатываемые данные помещались в основной памяти компьютера. Внешняя память обычно используется для периодического (нечастого) сохранения промежуточных результатов вычислений, чтобы в случае сбоя или перерыва в работе компьютера можно было продолжить работу программы от сохраненной контрольной точки.
   Во-вторых, информационные системы ориентируются на конечного пользователя, например банковского клерка. Такие пользователи могут быть далеки от мира компьютеров. Для них терминал, персональный компьютер или рабочая станция представляют собой всего лишь орудие их собственной профессиональной деятельности. Поэтому информационная система обязана обладать простым, удобным, легко осваиваемым интерфейсом, который должен предоставить конечному пользователю все необходимые для его работы функции, но в то же время не дать ему возможность выполнять какие-либо лишние действия. Сейчас очень популярны графические интерфейсы, и, как мы увидим в следующих частях курса, многие современные средства разработки информационных приложений прежде всего ориентированы на разработку графических интерфейсов.
   И снова заметим, что вычислительные программные системы не обязательно обладают развитыми интерфейсами. Конечно, это зависит от степени отчуждаемости программного продукта. Если система предназначена для продажи, то она должна обладать хорошим интерфейсом хотя бы в целях маркетинга. Но, как правило, серьезные вычислительные программы практически уникальны. Расчеты выполняются либо разработчиками программ, либо людьми из того же окружения. Для них гораздо важнее быстродействие вычислений, чем удобство запуска программы, а наличие развитого интерфейса предполагает существенный расход компьютерных ресурсов. Как профессионалы компьютерного мира, эти люди могут справиться с некоторыми неудобствами при работе со слабым интерфейсом.
   В-третьих, ИС создаются коллективно, т.к. один специалист в приемлемые сроки не в состоянии создать более-менее крупную систему в силу ее объема и в силу того, что она содержит много проблемных областей, с которыми необходимо подробно ознакомиться.
   В-четвертых, ИС создаются итерационно, т.е. очередями, сначала небольшой пусковой комплекс (1-ая очередь), затем новая итерация - 2-ая очередь и т.д. Следовательно, информационная система эволюционирует.
   В-пятых, ИС эксплуатируются долго (часто системы "живут" десятки лет) и стоят дорого (стоимость разработки + стоимость хранимой информации). Поэтому проектировать их надо качественно, тщательно готовить документацию на них. А в процессе эксплуатации соблюдать все меры предосторожности, чтобы не запортить и не потерять накопленную информацию.

Задачи, решаемые информационными  системами

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

Файл, запись, поле

   Файл - это любой набор данных, состоящих из элементов одинаковой структуры - записей. В свою очередь запись - представляет собой структуру, состоящую из полей. Поле - это минимальная поименованная структура данных. Пример файл "Кадры"; запись - "Личное дело"; поле - "ФИО".

Файловые  информационные системы.

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

Идея  СУБД. Отличие от ФИС

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

Определение банка данных. Требования к БНД

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

Понятие о корпоративных  и распределенных системах

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

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

Общая технология создания ИС. Структурный подход к созданию ИС

Системная и задачная технология создания ИС

Сущность  структурного подхода к разработке ИС заключается в ее декомпозиции (разбиении) на автоматизируемые функции: система разбивается на функциональные подсистемы, которые в свою очередь делятся на подфункции, подразделяемые на задачи и так далее. Процесс разбиения продолжается вплоть до конкретных процедур. При этом автоматизируемая система сохраняет целостное представление, в котором все составляющие компоненты взаимоувязаны.
При разработке системы "снизу-вверх" от отдельных  задач ко всей системе целостность  теряется, возникают проблемы при  информационной стыковке отдельных  компонентов. Однако, в отдельных  случаях такая технология может оказаться целесообразной:
    Срочность;
    Эксперимент и адаптация заказчика.
В структурном  анализе используются в основном две группы средств, представляющих функции, выполняемые системой и отношения между данными. Каждой группе средств соответствуют определенные виды моделей (диаграмм), наиболее распространенными среди которых являются следующие:
    SADT (Structured Analysis and Design Technique) модели и соответствующие функциональные диаграммы (подраздел 2.2);
    DFD (Data Flow Diagrams) диаграммы потоков данных (подраздел 2.3);
    ERD (Entity-Relationship Diagrams) диаграммы "сущность-связь" (подраздел 2.4).
   Модели  жизненного цикла  ПО
Под моделью ЖЦ понимается структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач, выполняемых на протяжении ЖЦ. Модель ЖЦ зависит от специфики ИС и специфики условий, в которых последняя создается и функционирует
Стандарт ISO/IEC 12207 не предлагает конкретную модель ЖЦ и методы разработки ПО. Его регламенты являются общими для любых моделей ЖЦ, методологий и технологий разработки. Стандарт ISO/IEC 12207 описывает структуру процессов ЖЦ ПО, но не конкретизирует в деталях, как реализовать или выполнить действия и задачи, включенные в эти процессы.
К настоящему времени  наибольшее распространение получили следующие две основные модели ЖЦ:
    каскадная модель (70-85 г.г.);
    спиральная модель (86-90 г.г.).
В изначально существовавших однородных ИС каждое приложение представляло собой  единое целое. Для разработки такого типа приложений применялся каскадный способ. Его основной характеристикой является разбиение всей разработки на этапы, причем переход с одного этапа на следующий происходит только после того, как будет полностью завершена работа на текущем (рис. 1.1). Каждый этап завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков.
Положительные стороны применения каскадного подхода  заключаются в следующем [2]:
    на каждом этапе формируется законченный набор проектной документации, отвечающий критериям полноты и согласованности;
    выполняемые в логичной последовательности этапы работ позволяют планировать сроки завершения всех работ и соответствующие затраты.

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

Рис. 1.2. Реальный процесс разработки ПО по каскадной схеме
Основным  недостатком каскадного подхода  является существенное запаздывание с получением результатов. Согласование результатов с пользователями производится только в точках, планируемых после завершения каждого этапа работ, требования к ИС "заморожены" в виде технического задания на все время ее создания. Таким образом, пользователи могут внести свои замечания только после того, как работа над системой будет полностью завершена. В случае неточного изложения требований или их изменения в течение длительного периода создания ПО, пользователи получают систему, не удовлетворяющую их потребностям. Модели (как функциональные, так и информационные) автоматизируемого объекта могут устареть одновременно с их утверждением.
Для преодоления  перечисленных проблем была предложена спиральная модель ЖЦ [10] (рис. 1.3), делающая упор на начальные этапы ЖЦ: анализ и проектирование. На этих этапах реализуемость  технических решений проверяется  путем создания прототипов. Каждый виток спирали соответствует созданию фрагмента или версии ПО, на нем уточняются цели и характеристики проекта, определяется его качество и планируются работы следующего витка спирали. Таким образом углубляются и последовательно конкретизируются детали проекта и в результате выбирается обоснованный вариант, который доводится до реализации.
Разработка  итерациями отражает объективно существующий спиральный цикл создания системы. Неполное завершение работ на каждом этапе  позволяет переходить на следующий  этап, не дожидаясь полного завершения работы на текущем. При итеративном способе разработки недостающую работу можно будет выполнить на следующей итерации. Главная же задача - как можно быстрее показать пользователям системы работоспособный продукт, тем самым активизируя процесс уточнения и дополнения требований.
Основная  проблема спирального цикла - определение  момента перехода на следующий этап. Для ее решения необходимо ввести временные ограничения на каждый из этапов жизненного цикла. Переход  осуществляется в соответствии с планом, даже если не вся запланированная работа закончена. План составляется на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков.

Рис 1.3. Спиральная модель ЖЦ ИС
Одним из возможных подходов к разработке ПО в рамках спиральной модели ЖЦ является получившая в последнее время  широкое распространение методология  быстрой разработки приложений RAD (Rapid Application Development). Под этим термином обычно понимается процесс разработки ПО, содержащий 3 элемента:
    небольшую команду программистов (от 2 до 10 человек);
    короткий, но тщательно проработанный производственный график (от 2 до 6 мес.);
    повторяющийся цикл, при котором разработчики, по мере того, как приложение начинает обретать форму, запрашивают и реализуют в продукте требования, полученные через взаимодействие с заказчиком.
Жизненный цикл ПО по методологии RAD ( и по ГОСТу  тоже) состоит из четырех фаз:
    фаза определения требований и анализа;
    фаза проектирования;
    фаза реализации;
    фаза внедрения.
Последовательность  этапов создания ИС на фазе определения  требований и анализа:
    Описание предметной области, структура организации, задачи, решаемые подразделениями, ДПД для существующей информационной технологии.
    Назначение ИС.
    Построение начальной контекстной диаграммы потоков данных (DFD).
    Формирование матрицы списка событий (ELM) и таблицы потоков данных.
    Построение иерархии контекстных диаграмм.
    Диаграмма структур данных.
На  стадии проектирования ИС модели расширяются, уточняются и дополняются диаграммами, отражающими структуру программного обеспечения: архитектуру ПО, структурные схемы программ и диаграммы экранных форм.
Результатами  проектирования архитектуры являются:
    модель процессов (диаграммы архитектуры системы (SAD) и миниспецификации на структурированном языке);
    модель данных (ERD и подсхемы ERD);
    модель пользовательского интерфейса (классификация процессов на интерактивные и неинтерактивные функции, диаграмма последовательности форм (FSD - Form Sequence Diagram), показывающая, какие формы появляются в приложении и в каком порядке. На FSD фиксируется набор и структура вызовов экранных форм. Диаграммы FSD образуют иерархию, на вершине которой находится главная форма приложения, реализующего подсистему. На втором уровне находятся формы, реализующие процессы нижнего уровня функциональной структуры, зафиксированной на диаграммах SAD.

Инфологическое  проектирование. Модель "сущность-связь"

 
     Понятие модели данных (МД)
     Под моделью данных М будем понимать пару:
     М=<F, O>, где F - множество допустимых форматов данных; а  О - множество  выполняемых над ними операций.
     Каждая  ЭВМ обладает определенной МД. С  помощью этой исходной модели могут  быть построены другие, более сложные МД, т.е. может быть выполнен переход к некоторой абстрактной машине с более удобной МД для представления исходных данных и решения прикладных задач.
     Примером  таких абстрактных машин являются интерпретаторы (или трансляторы) с алгоритмических языков программирования (ЯП) высокого уровня. Каждый ЯП обладает своей МД, независимой от машинной. Например, МД ФОРТРАНа оказывается удобной для представления как отдельных числовых величин (переменные), так и однородных совокупностей чисел (массивы, но не для работы с символьной информацией. Совокупность операторов любого алгоритмического языка (АЯ) может быть разбита на две основные группы: операторы декларативного типа и операторы процедурные. МД АЯ формально описывает множество допустимых логических структур данных, которые могут быть приняты, обработаны и выданы программами, составленными на этом АЯ.
     С позиций систем обработки данных все МД можно разделить на сильноструктурированные МД и слабоструктурированные МД. В сильноструктурированных МД. К сильноструктурированным МД относятся реляционная МД, объектная МД, семантическая сеть;  к слабоструктурированным МД относятся модели данных поиска и обработки документов, которые рассматриваются неструктурированно в виде символьных строк.
     Все сказанное о сильноструктурированных МД относится к МД любой программной системы обработки данных и, в частности к МД, поддерживаемой конкретной СУБД. Поэтому можно сказать, что совокупность языка описания данных (ЯОД) и языка манипулирования данными (ЯМД) определяет МД, поддерживаемую СУБД (т.е. совокупность методов и средств для определения логической структуры БД и динамического моделирования в БД состояний предметной области (ПО)).
     Выбор модели данных осуществляется проектировщиком  с точки зрения “прямого” моделирования понятий, сформулированных в инфологической модели ПО.
     Пусть МД оперирует понятиями
     “поле”, “запись”, “БД”, которые определяют ее понятийный базис;
     поле - поименованное элементарное данное;
     запись - поименованная совокупность полей;
     БД - поименованная совокупность записей.
     Тогда прямое моделирование может быть выполнено для следующих типов  понятий инфологической модели ПО:
    атрибут сущности - поле;
       значение атрибута - значение поля;
    тип сущности моделируется схемой записи.
     Пример: тип сущности СЛУЖАЩИЙ, описывается атрибутами ТАБЕЛЬНЫЙ-НОМЕР, ФАМИЛИЯ, ГОД-РОЖДЕНИЯ, ОБРАЗОВАНИЕ, может быть смоделироан схемой: СЛУЖАЩИЙ (Т-Н, Ф, Г-Р, О)
     или в терминах ЯОД:
     01 СЛУЖАЩИЙ
     02 ТАБЕЛЬНЫЙ-НОМЕР; ШАБЛОН 9999 /число/; КЛЮЧ /поле является первичным  ключом записи/
     02 ФАМИЛИЯ; ШАБЛОН А (25) /символьное  поле/;
     02 ГОД-РОЖДЕНИЯ; ШАБЛОН 9999
     02 ОБРАЗОВАНИЕ; ШАБЛОН А (10)
    экземпляр сущности - экземпляр записи;
    набор ЭС одного типа моделируется одной БД.
     Пример: БД СЛУЖАЩИЕ = совокупность записей  типа СЛУЖАЩИЙ.
     В данном примере нельзя выполнить прямое моделирование связей между сущностями, следовательно, их приходится моделировать косвенным образом. Для этого необходимо рассматривать каждую связь как отдельную сущность, атрибутами которой являются идентифицирующие атрибуты сущностей, входящих в связь.
     Пример: Связь РАБОТАЕТ-В между сущностями СЛУЖАЩИЙ, ОТДЕЛ представлен следующей  схемой записи:
     01 РАБОТАЕТ-В
     02 ТАБЕЛЬНЫЙ-НОМЕР; ШАБЛОН 9999; КЛЮЧ
     02 ШИФР-ОТДЕЛА; ШАБЛОН 9999; КЛЮЧ
     Набор экземпляров сущностей этого  типа моделируется отдельной БД. Другой вариант - представление связи в виде атрибута сущности СЛУЖАЩИЙ и модификация схемы записи добавлением:
     02 ШИФР-ОТДЕЛА; ШАБЛОН 99
     В развитых моделях велико число косвенных  путей моделирования.
     Чем большее количество конструкций инфологической модели ПО может быть представлено прямым моделированием при датологическом проектировании БД, тем более удачной считается МД.
     Кроме анализа возможностей прямого моделирования  проектировщик оценивает и другие свойства МД СУБД:
    сложность модели (для изучения пользователем);
    простота (минимальное число типов базовых структур и правил композиции);
    наглядность (представление СД в наглядной форме);
    трудоемкость написания программ для манипулирования СД.
 

Структуры, операции, ограничения МД

           В качестве основных компонентов модели данных рассматривают структуры, операции и ограничения.
           Структуры данных. Например, для файловой информационной системы (ФИС): поле - наименьшая поименованная единица данных; запись - поименованная совокупность полей; файл и т. п.). В этой модели агрегация используется для композиции полей в запись, а обобщение - для представления множества экземпляров записей одного типа одной структуры более высокого уровня - файлом. Т. о. структуризация данных базируется на использовании концепций “агрегации” и “обобщения”.
           Для обозначения  типов структур данных широко используется терминология, предложенная CODASYL (The Conference on Data Systems Languages) - ассоциацией по языкам СОД.
           Схема (рис. 1) определяет порядок композиции структур данных.
     
     Рис 1
           Элемент данных (ЭД) - наименьшая поименованная единица данных (аналог “поля” в ФИС), к которой СУБД может адресоваться непосредственно, и с помощью которой выполняется построение всех остальных структур. ЭД имеет имя и значение.
           Агрегат данных (АД) - поименованная совокупность ЭД внутри записи, которую можно рассматривать как единое целое. АД может быть простым (рис. 2) или составным (рис. 3). 

     

     Рис. 2 

     

     Рис. 3
           АД, повторяющийся  компонент которого является просто ЭД, называется вектором. АД, компонент которого представлен совокупностью данных (рис. 4), называется повторяющейся группой.
           
     Рис. 4
           Запись - поименованная совокупность ЭД и агрегатов. Запись это АД, не входящий в состав никакого другого АД. Запись может иметь сложную иерархическую структуру, так как допускается многократное применение агрегации.
           Набор - поименованная совокупность записей, образующих двухуровневую иерархическую структуру. Каждый тип набора представляет собой отношение (связь) между двумя или несколькими типами записей. Для каждого типа набора один тип записи может быть объявлен “владельцем набора”, тогда остальные типы записи объявляются “членами набора”. Каждый экземпляр набора должен содержать только один экземпляр записи типа “владелец набора”. Основное предназначение набора - представление связей между записями. В схеме набора задаются типы составляющих его записей, определяется тип записи-владельца и типы записей-членов, присваивается имя набору.
           База  данных - поименованная совокупность экземпляров записей различного типа, содержащая ссылки между записями, представленные экземплярами наборов. Описание структуры БД задается ее схемой.
           Операции  над данными. Динамические свойства модели данных выражаются множеством операций, которые определяют допустимые действия над некоторой реализацией БД для перевода ее из одного состояния в другое (ЯМД).
           Селекция данных предшествует любой конкретной операции над данными. Условие селекции специфицируется в виде некоторого критерия отбора данных, над которыми должно быть произведено действие. Селекция может выполняться с использованием позиции данного, значений данного, связей между данными.
           Использование для  селекции логической позиции данного базируется на упорядоченности данных в памяти системы. Можно выполнить селекцию данного, находящегося на первой, последней, предыдущей, следующей или n-ой позиции.
           При селекции по значениям данных критерий может определять простые или булевы условия отбора. Простое условие имеет вид
     “имя  атрибута_оператор условия_значение атрибута”
     оператор  условия: =, >, <, На основе простых условий можно построить булевы: AND, OR, NOT, например
     ОБРАЗОВАНИЕ = высшее AND СТАЖ 1.
           Пример селекции данных по связям: выполнить селекцию описаний всех отделов, в которых работают служащие, являющиеся молодыми специалистами.
           По характеру  производимого действия различают  следующие виды операций:
    идентификация данного и нахождение его позиции в БД;
    выборка (чтение) данного из БД;
    включение (запись) данного в БД;
    удаление данного из БД;
    модификация (изменение) данного в БД.
           По характеру  способа получения результата различают  навигационные и спецификационные операции. Если результат операции получается путем прохождения по связям, реализованным в структуре БД, то операции называются навигационными. Результат такой операции - это единичный объект БД (например экземпляр записи). Навигация в БД основывается на манипулировании значениями текущих.
           Если в операции определяются только требования к результату, но не задается способ получения, то такие  операции называются спецификационными. Спецификация требований может выполняться, например, с использованием формул исчисления предикатов, что имеет место в реляционной МД. Результатом такой операции является некоторое множество объектов БД.
           Процедура БД - последовательность операций, позволяющих реализовать алгоритм обработки данных. Главная особенность ПБД (как отдельной операции) - неделимость ее действия (макрооперация). Выполнение ПБД не может быть прервано другой операцией до окончания работы ПБД.
           Ограничения целостности (ОЦ) - логические ограничения, накладываемые на данные СУБД. ОЦ должны обеспечивать непротиворечивость данных заданным ограничениям при переводе базы из одного состояния в другое. Различают “внутренние” и "внешние" (“явные”) ограничения целостности (ОЦ).
           Внутренние  ОЦ представлены в МД правилами композиции допустимых структур данных и в конкретной схеме БД находят свое отражение в структурных спецификациях и в правилах выполнения операций. Нарушение таких ОЦ устанавливается транслятором или интерпретатором СУБД. Например, должна выполняться уникальность первичного ключа.
           Явные ОЦ специфицируются в семах БД явным образом с помощью специальных конструкций ЯОД и, как правило, отражают ограничения связанные с самой предметной областью. Пример, температура не может быть меньше , чем минус 273С.
           СУБД проверяет  непротиворечивость системы ограничений  и обеспечивает целостность данных в БД по отношению к заданным ограничениям в процессе функционирования.

Модель  “сущность - связь”

Модель  “сущность - связь” (МСС) (entity - relation diagram - ERD) является неформальной моделью предметной области (ПО) и используется на этапе инфологического проектирования БД. Моделируются объекты ПО и их взаимоотношения.
Достоинства МСС:
      относительная простота;
      однозначность;
      применение естественного языка;
      доступность для понимания.
Основное  назначение МСС - семантическое описание ПО и представление информации для обоснования выбора видов моделей и структур данных, которые в дальнейшем будут использованы в информационной системе.
Для построения МСС используются три основных конструктивных элемента для представления составляющих ПО - сущность, атрибут и связь. Информация о проекте представляется с использованием графических диаграмм.
“Время” в составе конструктивных элементов  отсутствует, но может быть представлено в модели посредством атрибутов (напр.: ГОД-РОЖДЕНИЯ-ПОЛУЧЕНО-В-ИЮНЕ,...).
Сущность - собирательное понятие, некоторая абстракция реально существующего объекта, процесса или явления, о котором необходимо хранить информацию в системе.  
 
 

Примеры сущностей:
материальные: нематериальные:
-предприятие; -описание явления;
-изделие; -рефераты научных  статей;
-сотрудники; -описание структур  данных;
В моделях  МСС каждая рассматриваемая сущность является основным местом сбора информации об этой сущности.
Тип сущности” определяет множество однородных объектов, а “экземпляр сущности” - конкретный объект из множества.
Каждая  сущность должна иметь имя. Например, сущность "СТУДЕНТ".
Атрибут” (А) - поименованнная характеристика сущности. При помощи атрибутов моделируются свойства сущностей: (сущность: КНИГА, атрибуты: НАЗВАНИЕ, АВТОР, ГОД-ИЗДАНИЯ).
Основная  роль атрибутов - описание свойств сущности. Другая роль - идентификация экземпляра сущности. То есть каждый экземпляр  сущности должен иметь уникальное имя. В качестве имени выступает один или несколько атрибутов. Например, "НОМЕР ЗАЧЕТНОЙ КНИЖКИ" или "НОМЕР" и "СЕРИЯ ПАСПОРТА".
Связь” - средство представления отношений между сущностями в модели ПО. Тип связи рассматривается между типами сущностей, например, между сущностями СТУДЕНТ и ГРУППА может быть связь УЧИТЬСЯ. То есть введение связи между двумя сущностями отражает семантику некоторого предложения. В данном случае, это СТУДЕНТ УЧИТСЯ В ГРУППЕ. Конкретный экземпляр связи данного типа существует между конкретными экземплярами данных типов сущностей. Например, ИВАНОВ УЧИТСЯ КМ-31.
В модели "сущность-связь" поддерживаются бинарные связи. В общем  случае в ПО могут быть n - арные  связи между сущностями.

Построение  глобальной инфологической модели

Так как  работа над проектом ИС ведется по функциональным подсистемам и многими разработчиками, то в результате анализа и проектирования получается множество локальных инфологических моделей (ЛИМ), предназначенных для обеспечения решения задач конкретного пользователя. Каждая ЛИМ является проекцией общей глобальной инфологической модели, которая доступна полностью только администратору базы данных. Поэтому нужно согласовать ЛИМ и произвести сборку глобальной модели.
При объединении  локальных моделей следует руководствоваться  следующими принципами:
      Поскольку локальные модели разрабатывались автономно, то после семантического (смыслового) анализа необходимо устранить синонимы и омонимы путем переименования атрибутов, связей и сущностей.
      Более общее представление поглощает менее общее Например, в одной ЛИМ "начальник отдела" может существовать как атрибут сущности "отдел", а в другой ЛИМ как экземпляр сущности "сотрудник". В этом случае атрибут удаляется, а устанавливается связь "быть начальником" между сущностями "отдел" и "сотрудник". Два локальных представления одной и той же сущности в глобальной модели объединяются с сохранением полного множества атрибутов. Так представления сущности "студент" для деканата и поликлиники отличаются. В глобальной модели, естественно будет одна сущность "студент" с полным набором атрибутов;
      Устраняются возникшие в результате объединения композиции связей;
      Обобщаются ограничения целостности и бизнес-правила;
      Проводится нормализация глобальной модели;
      Корректируются локальные модели в соответствии с глобальной.
Начинающий  проектировщик (коим и является студент!), познакомившийся лишь с лекционным материалом и выполнив начальный этап создания ИС- построение логической модели данных, не сможет правильно воспринять и оценить те советы и рекомендации по построению хорошей инфологической модели, которые десятилетиями формировались крупнейшими специалистами в области обработки данных. Для этого надо, по крайней мере, реализовать хотя бы один проект информационной системы, внедрить его и побыть администратором базы данных и приложений столь долго, чтобы возникла необходимость расширения и модификации системы, особенно силами других программистов (пресловутых эскимосов!). Опыт автора показывает, что любые теоретические рекомендации воспринимаются по-настоящему лишь после нескольких безрезультатных попыток сопровождения и модификации или восстановления неудачно спроектированных систем. (Хотя есть и такие проектировщики, которые продолжают верить, что смогут реанимировать умирающий проект с помощью изменения программ, а не инфологической модели БД).
При проектировании инфологической модели следует в первую очередь заботиться о надежности хранения данных, оставив на время вопрос о эффективности манипулирования данными, что в первую очередь заботит прикладного программиста, разрабатывающего приложения. Это связано с абсолютно различающимися требованиями к базе данных прикладных программистов и администратора базы данных. Первые хотели бы иметь в одном месте (например, в одной таблице) все данные, необходимые им для реализации запроса из прикладной программы или с терминала. Вторые же заботятся о целостности хранимых данных при вводе, обновлении или удалении информации. Для этого администратор удаляет из базы данных дубликаты и нежелательные функциональные связи, разбивая базу данных на множество таблиц, проводя так называемую нормализацию БД (см. ниже). Недостатки проекта невозможно устранить любыми ухищрениями в программах приложений, поэтому опытные проектировщики не позволяют себе идти навстречу прикладным программистам (даже тогда, когда они сами являются таковыми).
Итак, проектировщики баз данных должны помнить:
      ИС "живут" долго и стоят дорого;
      ИС являются плодом коллективной работы многих людей, только часть из которых доступны для контакта с нынешними админами и программистами. Поэтому главные задача проектировщика и администратора БД - поддержание целостности, а уж потом все остальное в том числе и эффективность.
      Как правило, база данных является информационной основой не одного, а нескольких приложений, поэтому как пользователь так и программист видит только проекцию БД (часть слона!), и не должен выступать в роли эскимоса, сочиняющего инструкцию для жителей Африки;
      Плохой проект базы данных не может быть исправлен с помощью любых (даже самых изощренных) приложений;
      четко разграничивать такие понятия как структурирование данных, манипулирование данными (ввод, изменение и удаление) и администрирование данных.

Датологическое  проектирование. Реляционная  модель данных. Сетевая  и иерархическая  МД

Общая характеристика реляционной  модели данных

Основы  реляционной модели данных были впервые изложены в статье Е.Кодда в 1970 г. Эта работа послужила стимулом для большого количества статей и книг, в которых реляционная модель получила дальнейшее развитие. Наиболее распространенная трактовка реляционной модели данных принадлежит К.Дейту. Согласно Дейту, реляционная модель состоит из трех частей:
    Структурной части.
    Целостной части.
    Манипуляционной части.
Структурная часть описывает, какие объекты рассматриваются реляционной моделью. Постулируется, что единственной структурой данных, используемой в реляционной модели, являются нормализованные n-арные отношения.
Целостная часть описывает ограничения специального вида, которые должны выполняться для любых отношений в любых реляционных базах данных. Это целостность сущностей и целостность внешних ключей.
Манипуляционная часть описывает два эквивалентных способа манипулирования реляционными данными - реляционную алгебру и реляционное исчисление.
Сначала рассмотрим структурную часть реляционной  модели.
Основными понятиями реляционных баз данных являются: тип данных, домен, атрибут, кортеж, первичный ключ и отношение.
Тип данных
Понятие тип данных в реляционной модели данных полностью адекватно понятию типа данных в языках программирования. Обычно в современных реляционных БД допускается хранение:
      символьных,
      числовых данных,
      битовых строк,
      специализированных числовых данных (таких как "деньги"),
      а также специальных "темпоральных" данных (дата, время, временной интервал).
Достаточно  активно развивается подход к  расширению возможностей реляционных систем абстрактными типами данных.
Важно! Реляционная модель требует, чтобы типы используемых данных были простыми (атомарными).
Конечно, понятие атомарности довольно относительно. Так, строковый тип данных можно  рассматривать как одномерный массив символов, а целый тип данных - как набор битов. Важно лишь то, что при переходе на такой низкий уровень теряется семантика (смысл) данных. Если строку, выражающую, например, фамилию сотрудника, разложить в массив символов, то при этом теряется смысл такой строки как единого целого.
Собственно, для реляционной модели данных тип  используемых данных не важен. Требование, чтобы тип данных был простым, нужно понимать так, что в реляционных операциях не должна учитываться внутренняя структура данных. Конечно, должны быть описаны действия, которые можно производить с данными как с единым целым, например, данные числового типа можно складывать, для строк возможна операция конкатенации и т.д.
С этой точки зрения, если рассматривать  массив, например, как единое целое и не использовать поэлементных операций, то массив можно считать простым типом данных. Более того, можно создать свой, сколь угодно сложных тип данных, описать возможные действия с этим типом данных, и, если в операциях не требуется знание внутренней структуры данных, то такой тип данных также будет простым с точки зрения реляционной теории.
Домен
Наиболее  правильной интуитивной трактовкой понятия домена является понимание  домена как допустимого потенциального множества значений данного типа. Например, можно ввести домен "цвет". Для предметной области "Правила перехода улицы" домен "цвет" будет принимать значения: "красный", "желтый", "зеленый". Никакие другие значения для данного домена СУБД не пропустит.
Домен - это семантическое понятие. Домен можно рассматривать как подмножество значений некоторого типа данных имеющих определенный смысл. Домен характеризуется следующими свойствами:
    Домен имеет уникальное имя (в пределах базы данных).
    Домен определен на некотором простом типе данных или на другом домене.
    Домен может иметь некоторое логическое условие, позволяющее описать подмножество данных, допустимых для данного домена.
    Домен несет определенную смысловую нагрузку.
Кортеж, отношение
Кортеж, соответствующий данной схеме отношения, - это множество пар {имя атрибута, значение}, которое содержит одно вхождение каждого имени атрибута, принадлежащего схеме отношения. "Значение" является допустимым значением домена данного атрибута (или типа данных, если понятие домена не поддерживается). Попросту говоря, кортеж - это набор именованных значений заданного типа.
Отношение - это множество  кортежей, соответствующих одной схеме отношения. На самом деле, понятие схемы отношения ближе всего к понятию структурного типа данных в языках программирования.
Отношение обычно записывается в виде:
,

или короче
.

Число атрибутов в отношении называют степенью (или -арностью) отношения.
Мощность  множества кортежей отношения называют мощностью отношения.
Реляционной базой данных называется набор отношений.
Обычным пользовательским представлением отношения является таблица, заголовком которой является схема отношения, а строками - кортежи отношения-экземпляра; в этом случае имена атрибутов именуют столбцы этой таблицы. Поэтому иногда говорят "столбец таблицы", имея в виду "атрибут отношения". Этой терминологии придерживаются в большинстве коммерческих реляционных СУБД.
Схема отношения, схема  базы данных
Схема отношения - это именованное множество пар {имя атрибута, имя домена (или типа, если понятие домена не поддерживается)}. Степень или "арность" схемы отношения - мощность этого множества. Схема БД (в структурном смысле) - это набор именованных схем отношений. Например, схема отношения "лампочка" схема выглядит так: лампочка( (имя, var char(10)), (мощность, dec ), (напряжение, vol ), (тип цоколя,cok ). При этом ранее должны быть заданы домены vol с областью значений (110,220) и cok с областью значений (обычный, миньон).
Схема БД - это поименованная совокупность схем, входящих в нее отношений.
Как видно, основные структурные понятия реляционной  модели данных (если не считать понятия домена) имеют очень простую интуитивную интерпретацию, хотя в теории реляционных БД все они определяются абсолютно формально и точно.
Фундаментальные свойства отношений:
Остановимся теперь на некоторых важных свойствах  отношений, которые следуют из приведенных ранее определений:
Отсутствие  кортежей-дубликатов
То свойство, что отношения не содержат кортежей-дубликатов, следует из определения отношения  как множества кортежей. В классической теории множеств по определению каждое множество состоит из различных элементов.
Из этого  свойства вытекает наличие у каждого  отношения так называемого первичного ключа - набора атрибутов, значения которых  однозначно определяют кортеж отношения. Понятие первичного ключа является исключительно важным в связи с понятием целостности баз данных.
Забегая вперед, заметим, что  во многих практических реализациях РСУБД  допускается нарушение  свойства уникальности кортежей для промежуточных  отношений, порождаемых  неявно при выполнении запросов. Такие отношения являются не множествами, а мультимножествами, что в ряде случаев позволяет добиться определенных преимуществ, но иногда приводит к серьезным проблемам.
Отсутствие  упорядоченности  кортежей
Свойство  отсутствия упорядоченности кортежей отношения также является следствием определения отношения-экземпляра как множества кортежей. Отсутствие требования к поддержанию порядка на множестве кортежей отношения дает дополнительную гибкость СУБД при хранении баз данных во внешней памяти и при выполнении запросов к базе данных. Это не противоречит тому, что при формулировании запроса к БД, например, на языке SQL можно потребовать сортировки результирующей таблицы в соответствии со значениями некоторых столбцов. Такой результат, вообще говоря, не отношение, а некоторый упорядоченный список кортежей.
Отсутствие  упорядоченности  атрибутов
Атрибуты  отношений не упорядочены, поскольку  по определению схема отношения  есть множество пар {имя атрибута, имя домена}. Для ссылки на значение атрибута в кортеже отношения  всегда используется имя атрибута. Это свойство теоретически позволяет, например, модифицировать схемы существующих отношений не только путем добавления новых атрибутов, но и путем удаления существующих атрибутов. Однако в большинстве существующих систем такая возможность не допускается, и хотя упорядоченность набора атрибутов отношения явно не требуется, часто в качестве неявного порядка атрибутов используется их порядок в линейной форме определения схемы отношения.

Атомарность значений атрибутов

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

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

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

Целостность сущности и ссылок

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

Базисные  средства манипулирования  реляционными данными

Третья  часть реляционной модели, манипуляционная часть, утверждает, что доступ к реляционным данным осуществляется при помощи реляционной алгебры или эквивалентного ему реляционного исчисления.
В реализациях  конкретных реляционных СУБД сейчас не используется в чистом виде ни реляционная алгебра, ни реляционное исчисление. Фактическим стандартом доступа к реляционным данным стал язык SQL (Structured Query Language). Язык SQL представляет собой смесь операторов реляционной алгебры и выражений реляционного исчисления, использующий синтаксис, близкий к фразам английского языка и расширенный дополнительными возможностями, отсутствующими в реляционной алгебре и реляционном исчислении. Вообще, язык доступа к данным называется реляционно полным, если он по выразительной силе не уступает реляционной алгебре (или, что то же самое, реляционному исчислению), т.е. любой оператор реляционной алгебры может быть выражен средствами этого языка. Именно таким и является язык SQL.
Как отмечалось выше, в манипуляционной составляющей определяются два базовых механизма манипулирования реляционными данными - основанная на теории множеств реляционная алгебра и базирующееся на математической логике (точнее, на исчислении предикатов первого порядка) реляционное исчисление. В свою очередь, обычно рассматриваются два вида реляционного исчисления - исчисление доменов и исчисление предикатов.
и т.д.................


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


Скачать работу с онлайн повышением уникальности до 90% по antiplagiat.ru, etxt.ru или advego.ru


Смотреть полный текст работы бесплатно


Смотреть похожие работы


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