
- •Владимир Николаевич Петров Юрий Избачков Информационные системы
- •Аннотация
- •Юрий Сергеевич Избачков, Владимир Николаевич Петров Информационные системы: Учебник для вузов Введение
- •Информационные системы
- •База данных
- •Case‑средства
- •Средства разработки
- •Для кого предназначена эта книга
- •Как составлена книга
- •Часть I. Анализ и проектирование информационных систем
- •Часть II. Delphi – система быстрой разработки приложений
- •Часть III. Выборка данных и отображение ее результатов
- •Часть IV. Компоновка приложения и управление проектом
- •Часть V. Технология com
- •Часть VI. Программирование для Интернета
- •Факторы, влияющие на развитие корпоративных информационных систем
- •Развитие методик управления предприятием
- •Развитие общих возможностей и производительности компьютерных систем
- •Развитие подходов к технической и программной реализации элементов информационных систем
- •Основные составляющие корпоративных информационных систем
- •Соотношение между составляющими информационной системы
- •Классификация информационных систем
- •Классификация по масштабу
- •Классификация по сфере применения
- •Классификация по способу организации
- •Области применения и примеры реализации информационных систем
- •Бухгалтерский учет
- •Управление финансовыми потоками
- •Управление складом, ассортиментом, закупками
- •Управление производственным процессом
- •Управление маркетингом
- •Документооборот
- •Оперативное управление предприятием
- •Предоставление информации о фирме
- •Требования, предъявляемые к информационным системам
- •Гибкость
- •Надежность
- •Эффективность
- •Безопасность
- •Глава 2 Жизненный цикл информационных систем
- •Общие сведения об управлении проектами
- •Понятие проекта
- •Классификация проектов
- •Основные фазы проектирования информационной системы
- •Концептуальная фаза
- •Подготовка технического предложения
- •Проектирование
- •Разработка
- •Ввод системы в эксплуатацию
- •Процессы, протекающие на протяжении жизненного цикла информационной системы
- •Основные процессы жизненного цикла
- •Разработка
- •Эксплуатация
- •Сопровождение
- •Вспомогательные процессы жизненного цикла
- •Организационные процессы
- •Структура жизненного цикла информационной системы
- •Начальная стадия
- •Стадия уточнения
- •Стадия конструирования
- •Стадия передачи в эксплуатацию
- •Модели жизненного цикла информационной системы
- •Каскадная модель жизненного цикла информационной системы
- •Основные этапы разработки по каскадной модели
- •Основные достоинства каскадной модели
- •Недостатки каскадной модели
- •Спиральная модель жизненного цикла
- •Итерации
- •Преимущества спиральной модели
- •Недостатки спиральной модели
- •Глава 3 Методология и технология разработки информационных систем
- •Методология rad
- •Основные особенности методологии rad
- •Объектно‑ориентированный подход
- •Визуальное программирование
- •Событийное программирование
- •Фазы жизненного цикла в рамках методологии rad
- •Фаза анализа и планирования требований
- •Фаза проектирования
- •Фаза построения
- •Фаза внедрения
- •Ограничения методологии rad
- •Профили открытых информационных систем
- •Понятие профиля информационной системы
- •Принципы формирования профиля информационной системы
- •Структура профилей информационных систем
- •Профиль прикладного программного обеспечения
- •Профиль среды информационной системы
- •Профиль защиты информации
- •Профиль инструментальных средств
- •Стандарты и методики
- •Виды стандартов
- •Методика cdm фирмы Oracle
- •Общая структура
- •Особенности методики cdm
- •Международный стандарт iso/iec 12207: 1995‑08‑01
- •Общая структура
- •Основные и вспомогательные процессы жизненного цикла
- •Особенности стандарта iso 12207
- •Универсальный язык моделирования
- •Предшественники uml
- •Структура uml
- •Глава 4 Реляционные базы данных
- •Общие сведения о базах данных
- •Основные функции систем управления базами данных
- •Непосредственное управление данными во внешней памяти
- •Управление буферами оперативной памяти
- •Управление транзакциями
- •Протоколирование
- •Поддержка языков баз данных
- •Эволюция систем управления базами данных
- •Субд первого поколения
- •Реляционные субд
- •Объектно‑ориентированные субд
- •Реляционная модель данных
- •Базовые понятия реляционной модели данных
- •Тип данных
- •Атрибуты, схема отношения, схема базы данных
- •Пустые значения
- •Ключи отношения
- •Связанные отношения
- •Внешние ключи отношения
- •Условия целостности данных
- •Типы связей между таблицами
- •Конец ознакомительного фрагмента.
Связанные отношения
В реляционной модели данные представляются в виде совокупности взаимосвязанных таблиц. Подобное взаимоотношение между таблицами называется связью (relation). Таким образом, еще одним важным понятием реляционной модели является связь между отношениями.
Для анализа связанных отношений воспользуемся рассмотренным ранее примером – отношением СТУДЕНТЫ (см. табл. 4.1). Данное отношение может быть связано с отношением УСПЕВАЕМОСТЬ, в котором содержатся сведения об успеваемости студентов по разным предметам. Фрагмент такого отношения может выглядеть так, как показано в табл. 4.2.
Таблица 4.2. Фрагмент отношения УСПЕВАЕМОСТЬ, связанного с отношением СТУДЕНТЫ
Атрибут №_студенческого_билета таблицы УСПЕВАЕМОСТЬ содержит идентификатор студента (в данном примере в качестве такого идентификатора используется номер студенческого билета). Если нужно узнать имя студента, соответствующее строкам в таблице УСПЕВАЕМОСТЬ, то следует поискать это же значение идентификатора студента в поле №_студенческого_билета таблицы СТУДЕНТЫ и в найденной строке прочесть значение поля Имя. Таким образом, связь между таблицами СТУДЕНТЫ и УСПЕВАЕМОСТЬ устанавливается по атрибуту №_студенческого_билета.
При рассмотрении связанных таблиц важное значение имеет понятие внешнего ключа. Рассмотрим его более подробно.
Внешние ключи отношения
В базах данных одни и те же имена атрибутов часто используются в разных отношениях. В рассматриваемом примере атрибут №_студенческого_билета присутствует как в отношении СТУДЕНТЫ, так и в отношении УСПЕВАЕМОСТЬ. В этом примере атрибут №_студенческого_билета иллюстрирует понятие внешнего ключа (foreign key).
Внешний ключ – это атрибут (или множество атрибутов) одного отношения, являющийся ключом другого (или того же самого) отношения.
Внешние ключи используются для установления логических связей между отношениями. Связь между двумя таблицами устанавливается путем присваивания значений внешнего ключа одной таблицы значениям ключа другой.
Так же как и любые другие ключи, внешние ключи могут быть простыми либо составными.
Часто связь между отношениями устанавливается по первичному ключу, то есть значениям внешнего ключа одного отношения присваиваются значения первичного ключа другого отношения. Однако это не является обязательным – в общем случае связь может устанавливаться и с помощью вторичных ключей. Кроме того, при установлении связей между таблицами необязательно требование уникальности ключа, по которому устанавливается связь.
Примечание.
Атрибуты внешнего ключа не обязательно должны иметь те же имена, что атрибуты ключа, которым они соответствуют. Например, в нашем примере можно было дать атрибуту №_студенческого_билета таблицы УСПЕВАЕМОСТЬ другое имя, например Студенческий_билет.
Внешний ключ может ссылаться на ту же таблицу, к которой он принадлежит; в этом случае внешний ключ называется рекурсивным.
Условия целостности данных
Чтобы информация, хранящаяся в базе данных, была однозначной и непротиворечивой, в реляционной модели устанавливаются некоторые ограничительные условия. Ограничительные условия – это правила, определяющие возможные значения данных. Они обеспечивают логическую основу для поддержания корректных значений данных в базе. Такие ограничения целостности позволяют свести к минимуму ошибки, возникающие при обновлении и обработке данных.
Важнейшими ограничениями целостности данных являются:
• категорийная целостность;
• ссылочная целостность.
Ограничение категорийной целостности заключается в следующем. Кортежи отношения представляют в базе данных элементы определенных объектов реального мира или, в соответствии с терминологией реляционных СУБД, категорий. Например, строка таблицы СТУДЕНТЫ представляет конкретного студента. Первичный ключ таблицы однозначно определяет каждый кортеж и, следовательно, каждый элемент категории. Таким образом, для извлечения данных, содержащихся в строке таблицы, или для манипулирования этими данными необходимо знать значение ключа для этой строки. Поэтому строка не может быть занесена в базу данных до тех пор, пока не будут определены все атрибуты ее первичного ключа. Это правило называется правилом категорийной целостности и кратко формулируется следующим образом: никакой атрибут первичного ключа строки не может быть пустым.
Рассмотрим теперь понятие ссылочной целостности.
Если две таблицы связаны между собой, то внешний ключ таблицы должен содержать только значения, уже имеющиеся среди значений ключа, по которому осуществляется связь. Если корректность значений внешних ключей не контролируется СУБД, то может нарушиться ссылочная целостность данных. Это можно пояснить на рассматриваемом примере следующим образом. Если удалить из таблицы СТУДЕНТЫ строку (например, при отчислении студента), имеющую хотя бы одну связанную с ней строку в таблице УСПЕВАЕМОСТЬ, то это приведет к тому, что в таблице УСПЕВАЕМОСТЬ останутся записи об успеваемости студента, который уже отчислен. Такая же ситуация будет наблюдаться и в том случае, если внешнему ключу таблицы УСПЕВАЕМОСТЬ ошибочно будет присвоено значение, отсутствующее в значениях ключа связанной таблицы.
Ограничения категорийной и ссылочной целостности должны поддерживаться СУБД. Для соблюдения целостности сущности достаточно гарантировать отсутствие в любом отношении кортежей с одним и тем же значением первичного ключа. Что же касается ссылочной целостности, то здесь обеспечение целостности выглядит несколько сложнее. При обновлении ссылающегося отношения (при вставке новых кортежей или модификации значения внешнего ключа в существующих кортежах) достаточно следить за тем, чтобы не появлялись некорректные значения внешнего ключа. А вот при удалении кортежа из отношения, на которое ведет ссылка, можно использовать один из трех подходов, обеспечивающих ссылочную целостность:
• запрещается производить удаление кортежа, на который существуют ссылки, то есть сначала нужно либо удалить ссылающиеся кортежи, либо соответствующим образом изменить значения их внешнего ключа;
• при удалении кортежа, на который имеются ссылки, во всех ссылающихся кортежах значение внешнего ключа должно автоматически становиться неопределенным;
• при удалении кортежа из отношения, на которое ведет ссылка, из ссылающегося отношения должны автоматически удаляться все ссылающиеся кортежи (это называется каскадным удалением).
В развитых реляционных СУБД обычно можно выбрать способ поддержания ссылочной целостности для каждой отдельной ситуации определения внешнего ключа. Конечно, для принятия такого решения необходимо анализировать требования конкретной прикладной области.
Примечание.
Хотя большинство современных СУБД обеспечивает ссылочную целостность данных, все же следует помнить, что существуют реляционные СУБД, в которых такая целостность не поддерживается. Это, как правило, ранние разработки локальных реляционных СУБД – FoxPro версии 2.6 и ниже, версии dBase для DOS.