Справочник от Автор24
Поделись лекцией за скидку на Автор24

Базы данных в структуре информационных систем. Инфологический подход к проектированию баз данных. Архитектура БД

  • 👀 681 просмотр
  • 📌 619 загрузок
Выбери формат для чтения
Статья: Базы данных в структуре информационных систем. Инфологический подход к проектированию баз данных. Архитектура БД
Найди решение своей задачи среди 1 000 000 ответов
Загружаем конспект в формате doc
Это займет всего пару минут! А пока ты можешь прочитать работу в формате Word 👇
Конспект лекции по дисциплине «Базы данных в структуре информационных систем. Инфологический подход к проектированию баз данных. Архитектура БД» doc
ВВЕДЕНИЕ В БАЗЫ ДАННЫХ Базы данных в структуре информационных систем Автоматизированная информационная система представляет собой совокупность информации, математических методов и моделей, технических, программных, технологических средств и специалистов, предназначенную для обработки информации и принятия управленческих решений. АИС относятся к большим системам и требуют деления на отдельные части и элементы: подсистемы, набор задач, отдельные задачи. Подсистема - относительно самостоятельная часть системы выделенная по определенному признаку. Подсистемы могут выделяться по функциональному или структурному признаку. Принято выделять две группы подсистем в структуре АИС: • функциональные подсистемы • обеспечивающие подсистемы. Функциональные подсистемы составляют содержательную часть автоматизированной системы. Именно в функциональных подсистемах сосредотачиваются задачи, реализующие конкретные функции информационных систем. Автоматизированные задачи объединяются в функциональные подсистемы исходя из принципа однотипности относительно реализуемых функций. Так в рамках АСУ предприятием чаще всего выделяют следующие функциональные подсистемы: технической подготовки производства, технико-экономического планирования, оперативного планирования и управления, материально-технического снабжения, бухгалтерского учета, управления сбытом, управления кадрами, управления качеством, управления финансами, управления вспомогательным производством. В рамках функциональных подсистем, как правило, выделяют подсистемы более низкого уровня. Таким образом реализуется иерархичность системы управления. Обеспечивающие подсистемы создают условия для работы функциональных подсистем. Выделяют следующие обеспечивающие подсистемы: • информационное обеспечение, • программное обеспечение, • техническое обеспечение, • организационно-правовое обеспечение. Информационное обеспечение – это совокупность системы классификации и кодирования, системы технико-экономической информации, языков записи данных, унифицированных систем документации и массивов информации используемых в АИС. Программное обеспечение (ПО) – совокупность программ, позволяющая организовать решение задач на компьютере. Важнейшими классами ПО являются системное и специальное (прикладное), представленное, в частности, пакетами прикладных программ (ППП). Системное программное обеспечение организует процесс обработки информации в компьютере. Главную его часть составляет операционная система (ОС). ОС и средства, расширяющие ее возможности, включают: планировщики - программы, организующие распределение ресурсов вычислительной системы и связь с пользователем; супервизор, который обеспечивает организацию процессов обработки программ на ПК; сервисные обслуживающие программы, позволяющие рационально организовать процесс обработки программ (программных модулей). Прикладное ПО предназначено для решения функциональных задач и работы пользователей. Пакеты прикладных программ - комплекс программ, предназначенных для решения определенного класса задач, для оснащения АРМ и решения функциональных комплексов НС. Техническое обеспечение представлено совокупностью взаимосвязанных единым управлением автономных технических средств сбора, накопления, обработки, передачи, вывода и представления информации, средств обработки документов и оргтехники, а также средств связи для осуществления информационнoгo обмена между различными техническими средствами. Таким образом, можно сказать, что функциональные подсистемы представляют комплекс математических моделей и методов для решения задач управления, а обеспечивающие подсистемы представляют собой комплекс технических средств, носителей информации, программ и различных инструктивно-методических документов, необходимых для реализации соответствующих функциональных подсистем. Информационное обеспечение Под информацией понимается совокупность различных сообщений об изменении, происходящих в системе и окружающей среде. Процесс управления включает сбор, обработку и передачу информации для выработки управленческих решений. Информация является предметом труда и одновременно средством и продуктом труда в управленческой деятельности. Управленческая информация всегда имеет целевое назначение и содержит либо управленческое воздействие, либо сведения о состоянии управляемого объекта. Совокупность различных экономических, технических, социологических и других данных, используемых в процессе управления объектом, представляет собой систему технико-экономической информации, являющейся частью информационного обеспечения. Информационное обеспечение – это совокупность системы классификации и кодирования, системы технико-экономической информации, языков записи данных, унифицированных систем документации и массивов информации используемых в АИС. Целью информационного обеспечения (ИО) является своевременная выдача необходимой и достоверной информации для выработки и принятия управленческих решений. К основным задачам ИО относится: Классификация, формирование оптимального перечня и состава информации, ее кодирование; Разработка классификаторов; Создание информационной модели объекта автоматизации; Формирование информационной справочно-нормативной базы управления. Информационное обеспечение включает: Состав информации, т.е. перечень информационных единиц или информационных совокупностей – показателей, констант, переменных, документов и других сообщений необходимых для решения комплекса задач системы; Структуру информации и закономерности ее преобразования, т.е. правила построения показателей, документов, агрегации и декомпозиции информационных единиц; Характеристики движения информации, т.е. количественные оценки потоков информации (объем, интенсивность), определение маршрутов движения документов, построение схем документооборота, временные характеристики функционирования источников информации, получения первичных данных, использования исходных данных, продолжительн6ость хранения, старения и обновления данных; Характеристики качества информации, т.е. систему количественных оценок полезности, значимости, полноты, своевременности информации; Способы преобразования информации, т.е. методы отбора, распределения информации, схемы обеспечения информацией подразделений системы управления. ИО должно быть организовано в соответствии со следующими требованиями: Представление информации о состоянии объекта по всем управляемым параметрам; Представление необходимой, достоверной и достаточной информации; Обеспечение защиты данных; Обеспечение своевременного сбора и передачи информации для обработки; Установление определенной периодичности поступления информации в соответствии с режимом управления; Применение совершенных носителей, способов нанесения и обработки информации с использованием современных технических средств; Использование интегрированных систем обработки информации; Обеспечение сжатия информации при переходе от низших уровней управления к высшим. Информационное обеспечение ИС включает два комплекса: внемашинное информационное обеспечение (классификаторы технико-экономической информации, документы, методические инструктивные материалы); внутримашинное информационное обеспечение (макеты/экранные формы для ввода первичных данных в ЭВМ или вывода результатной информации, структуры информационной базы: входных, выходных файлов, базы данных). Таким образом, являясь неотъемлемой часть информационной системы, базы данных ориентированы на конкретную предметную область, являющуюся объектов автоматизации. Понятие баз данных Предметная область, ПрО – часть реального мира, подлежащая изучению с целью организации управления процессами и объектами для получения результата. Предметная область может быть разделена (декомпозирована) на фрагменты: например, предприятие – это дирекция, плановые отделы, бухгалтерия, цеха, отделы маркетинга, логистики и продаж, клиенты, поставщики и т. д. Каждый фрагмент предметной области характеризуется множеством объектов и процессов, использующих объекты, а также множеством пользователей, характеризуемых различными взглядами на предметную область и данными, которые описывают указанные составляющие предметной области. Эти данные отражают динамичную внешнюю и внутреннюю среды предприятия, поэтому в специальных разделах информационной системы необходимо создавать динамически обновляемые модели отражения внешнего мира с использованием единого хранилища - базы данных. Под базой данных (БД, Data Base) понимается «совокупность данных, организованных по определённым правилам, предусматривающим общие принципы описания, хранения и манипулирования данными, независимая от прикладных программ. Эти данные относятся к определённой предметной области и организованы таким образом, что могут быть использованы для решения многих задач многими пользователями». Другими словами: База данных – структурированный организованный набор данных, объединенных в соответствии с некоторой выбранной моделью и описывающих характеристики какой-либо физической или виртуальной системы. Рисунок 1 – Общая схема базы данных База данных является информационной моделью предметной области и к ней предъявляются требования адекватности (отражение основных свойств и характеристик процессов реализуемых в предметной области) и актуальности (обновление БД в соответствии с изменением состояния ПО). База данных – это некоторая целевая модель предметной области (ПО), т.е. в базе данных находят отражение только те факты о ПО, которые необходимы для функционирования автоматизированной системы, в состав которой входит БД. При проектировании БД проектировщик должен выделить и описать эти ожидаемые факты, тем самым определяются границы ПО, затем необходимо выполнить интерпретацию описание этих фактов с помощью допустимых конкретной СУБД структур данных. Предметная область БД определена, если известны существующие в ней объекты, их свойства и отношения. При проектировании БД начинают с предварительной структуризации предметной области: объекты реального мира подвергают классификации, фиксируют совокупность объектов, подлежащих отображению в БД. Для каждого типа объектов фиксируется совокупность свойств, посредством которых описываются конкретные объекты этого типа, виды отношений (взаимосвязей) между этими объектами. Затем решается вопрос о том, какая информация об этих объектах должна быть представлена в БД и как ее представить с помощью данных. С базами данных работают различные категории пользователей: прикладные программисты, конечные пользователи, администраторы базы данных. Конечные пользователи – это основная категория пользователей. Конечные пользователи работают с базами данных через рабочую станцию или терминал, используя при этом либо приложения, либо интерфейс СУБД. В зависимости от особенностей создаваемой базы данных круг конечных пользователей может существенно различаться . Конечным пользователем может быть, например, клиент компьютер- ной фирмы, просматривающий каталог продукции или услуг, или начальник отдела, анализирующий перспективы её развития. Прикладные программисты разрабатывают внешние приложения, которые позволяют выполнять над данными все стандартные операции: выборку, удаление и изменение существующей информации, вставку новой информации. Администратор базы данных (АБД) – под этим понятием подразумевается лицо (или группа лиц, возможно, целое штатное подразделение), на которое возложено управление средствами базы данных организации. В его функции входит: − координировать все действия по проектированию, реализации и ведению базы данных; учитывать перспективные и текущие требования пользователей; следить, чтобы база данных удовлетворяла актуальным информационным потребностям; − анализировать существующие программные средства и возможность их использования в базе данных, разрабатывать программно-технические мероприятия по развитию базы данных; − разрабатывать и реализовывать меры по обеспечению защиты данных от некомпетентного их использования, от сбоев технических средств, по обеспечению секретности определённой части данных и разграничению доступа к данным; − выполнять работы по ведению словаря данных; контролировать избыточность и противоречивость данных, их достоверность; − следить за тем, чтобы БД отвечала заданным требованиям по производительности, т.е. чтобы обработка запросов выполнялась за приемлемое время; выполнять при необходимости изменения методов хранения данных, путей доступа к ним, связей между данными, форматов данных; определять степень влияния изменений в данных на всю БД; координировать вопросы технического обеспечения системы аппаратными средствами исходя из требований, предъявляемых БД к оборудованию; − координировать работы системных программистов, разрабатывающих дополнительное программное обеспечение для улучшения эксплуатационных характеристик системы; − координировать работы прикладных программистов, разрабатывающих новые приложения и выполнять проверку и включение прикладных программ в состав программного обеспечения системы; − работать с конечными пользователями, в том числе и по вопросам обучения и консультирования и т.п. Программное обеспечение включает, прежде всего, систему управления базами данных (СУБД) – комплекс программных средств, «предназначенный для создания и хранения базы данных на основе некоторой модели данных, обеспечения логической и физической целостности содержащихся в ней данных, надёжного и эффективного использования ресурсов (данных, пространства памяти, вычислительных ресурсов), предоставления к ней санкционированного доступа для приложений и конечных пользователей, а также для поддержки функций администратора баз данных». Рассмотрим функции СУБД подробнее: − СУБД должна предоставлять пользователям и программам два типа языков: язык описания данных (для описания логической структуры данных) и язык манипулирования данными (для выполнения запросов пользователя на выборку, изменение, удаление данных); − СУБД должна контролировать пользовательские запросы и следить за выполнением правил безопасности и целостности, определённых АБД; − В СУБД должен быть предусмотрен механизм восстановления данных; − СУБД должна обеспечить функцию словаря данных. Словарь данных содержит «данные о данных», так называемые метаданные. Метаданные словаря предоставляются в виде, удобном для восприятия человеком, и характеризуют состав и структуру пользовательских данных в базе данных. Словарь данных предназначен для документирования разработки системы базы данных, справочного обслуживания её пользователей, а также для персонала АБД. СУБД является важнейшим, но не единственным компонентом программного обеспечения. Другие программные компоненты: средства разработки приложений, средства проектирования, утилиты, генераторы отчётов и т.д. ИНФОЛОГИЧЕСКИЙ ПОДХОД К ПРОЕКТИРОВАНИЮ БАЗ ДАННЫХ. АРХИТЕКТУРА БД База данных – это некоторая целевая модель предметной области (ПрО), т.е. в базе данных находят отражение только те факты о ПрО, которые необходимы для функционирования автоматизированной системы, в состав которой входит БД. При проектировании БД проектировщик должен выделить и описать эти ожидаемые факты, тем самым определяются границы ПрО, затем необходимо выполнить интерпритацию описание этих фактов с помощью допустимых конкретной СУБД структур данных. Предметная область БД определена, если известны существующие в ней объекты, их свойства и отношения. При проектировании БД начинают с предварительной структуризации предметной области: объекты реального мира подвергают классификации, фиксируют совокупность объектов, подлежащих отображению в БД. Для каждого типа объектов фиксируется совокупность свойств, посредством которых описываются конкретные объекты этого типа, виды отношений (взаимосвязей) между этими объектами. Затем решается вопрос о том, какая информация об этих объектах должна быть представлена в БД и как ее представить с помощью данных. Сущность инфологического подхода к проектированию информационных систем заключается в установлении соответствия между состоянием ПрО , его восприятием и представлением в БД. В настоящее время при описании ПрО данные представляются в виде трехуровневой схемы1: • Внешнее ( с точки зрения конечного пользователя и прикладного программиста); • Концептуальное (с точки зрения администратора БД); • Внутреннее (с точки зрения системного программиста). Внешнее представление данных является совокупностью требований к данным некоторой конкретной задачи или программы. Оно определяет совокупность внешних представлений, соответствующих отдельным задачам и перекрывающих друг друга по некоторым данным. С точки зрения конечного пользователя внешнее представление является совокупностью требований к данным, определенными функциональными спецификациями (реальными форматами) и отражает конкретные информационные потребности. С точки зрения прикладного программиста внешнее представление заключается в наборе элементов данных и их взаимосвязи для обеспечения конкретной задачи. Различия между этими представлениями: • Для пользователя многие сведения определяются путем обработки данных в представлении системного программиста; • Представления программиста могут содержать много дополнительной информации. Концептуальное представление данных связано с отображением знаний о ПрО. Структура данных на концептуальном уровне называется концептуальной схемой. Под концептуальным представлением понимается интегральное определение данных, которое основано на объединении всех внешних представлений для всей совокупности приложений. Другими словами, концептуальное представление данных является совокупностью всех требований к данным полученным из пользовательских внешних представлений. Существует и другой подход, по которому концептуальное представление формируется в результате непосредственного анализа ПрО с учетом информационных потребностей пользователей. Элементарными единицами концептуального представления являются : • Элементы (объекты, предметы, процессы); • Связи элементов; • Свойства элементов. Схема концептуального моделирования приведена на рис. 2. В этой схеме предусмотрено построение концептуальной модели путем объединения информационного описания ПрО (ПрО-информации) и информационных требований прикладных программ (ПП-информация). ПрО-Информация отображает объекты, процессы и предметы реального мира как составные части ПрО, их существенные свойства, а также взаимосвязи этих элементов. Эта информация не связана ни с конкретными приложениями, ни с конкретными способами обработки, а описывает естественные концептуальные связи всех данных в базе данных. Пример ПрО-информации: • Описание элемента ПрО: Наименование - СТУДЕНТ Количество - 25 • Описание атрибутов элементов ПрО: Наименование - НОМЕР ЗАЧ. КНИЖКИ Длина - десятичных знаков Диапазон изменения - 000001-999999 • Описание связей элементов ПО: Наименование - УЧИТСЯ В Определяемые элементы - СТУДЕНТ, ГРУППА Количество - 25 Отображение - 1:1 ПП-информация описывает данные и связи, используемые в приложениях. Она отображает требования конечных пользователей к обработке используемых текущих приложений и предполагаемые требования планируемых в будущем приложений. Пример ПП-информации: • Описание процесса: Наименование - Экземпляр ведомости Частота применения - 2 раза в год Требуемые данные - СТУДЕНТ, НОМЕР ЗАЧ. КНИЖКИ ГРУППА ПРЕПОДАВАТЕЛЬ Объем данных - 25 • Оператор: Наименование - найти Критерий поиска - СТУДЕНТ Кол-во поисковых образов - все Используемые ассоциации – успеваемость Рисунок 2 – Общая схема концептуального моделирования Внутреннее (физическое) представление выражает представление данных системными программистами и связано с организацией хранения данных на физических носителях информации. Практически внутреннее представление интегрированная база данных. Элементами внутреннего представления являются: • Физические блоки; • Хранимые записи; • Указатели; • Данные переполнения; • Межблочные промежутки. Рисунок 3 – Трехуровневое представление данных Согласно инфологическому подходу при проектировании БД различают: 1. Явления реального мира; 2. Информация об этих явлениях; 3. Представление этой информации посредством данных. Соответственно выделяют сферы: 1. Объектная система; 2. Информационная сфера; 3. Датологическая сфера. Объектная система. Объектная система имеет следующие составляющие: • Объект; • Свойство; • Связь; • Время. Объект – это то о чем должна накапливаться информация в АС. Выбор объектов производится в соответствии с целевым назначением информационной системы. Объекты могут быть составными и атомарными. Для составного объекта должно быть определено его внутреннее строение, структура, порядок композиции составляющих. Каждый объект в конкретный момент времени характеризуется определенным состоянием. Это состояние описывается с помощью ограниченного набора свойств и связей (отношений) с другими объектами. Свойства могут быть: • Локальными, независимыми от других объектов; • Реляционными. Связь между объектами характеризуется степенью n, в зависимости от входящих в нее объектов. Время также рассматривается в качестве основной составляющей. В отдельные моменты времени или в течении некоторых временных интервалов объекты могут иметь определенное состояние. Использование временных характеристик позволяет строить динамические модели. Основные составляющие объектной системы комбинируются в базисные структуры, которые называются элементарными ситуациями. Элементарной ситуацией называется структура описываемая выражением  o, y, t , где o – объект y - свойство t – время. Элементарные ситуации, существующие в некоторый момент времени для конкретной области называется элементарными фактами. Множество всех объектов, имеющих общее свойство у называется объектной группой. Они могут быть пересекающейся и непересекающейся. Информационная сфера. Информационная сфера определяется понятиями, с помощью которых можно формально описать и проанализировать информацию об объектах системы. Основные понятия информационной сферы сведения. Для каждого сведения всегда определена его предметная цель, т.е. указано к чему оно относится: объекту, объектной группе, атрибуту, связи, времени, ситуации. Сведения представляют собой смысловые, концептуальные образы составляющих, которые используются человеком при восприятии и осмыслении реальных объектов. Однозначные сведения обозначаются универсальным именем, неоднозначные, локальным именем. Сведения представляются выражениями, основу которых составляют элементарные сведения. Структура элементарного сообщения соответствует структуре элементарной ситуации  x, y, z , где x – сведения об объекте y – сведения о свойстве z – сведения о времени. Тройка  x, y, z  , называется полным элементарным сообщением. Множеству допустимых элементарных ситуаций соответствует множеству возможных полных элементарных сообщений. Датологическая сфера. В датологической сфере рассматриваются вопросы представления данных выделенных информационных структур. Жизненный цикл базы данных Процедура создания концептуальной схемы базы данных, определения данных, включаемых в базу данных, создание программ обновления и обработки данных называется жизненным циклом базы данных (ЖЦ). Жизненный цикл включает в себя процессы проектирования, реализации и поддержания системы базы данных и состоит из следующих этапов: − предварительное планирование; − проверка осуществимости; − определение требований; − концептуальное проектирование; − реализация; − оценка работы и поддержка базы данных; − снятие с эксплуатации. Предварительное планирование выполняется в процессе разработки стратегического плана базы данных. Стратегический план предполагает количество и вид баз данных, которые требуется создать для организации. Когда начинается разработка проекта реализации, общая информационная модель, созданная в процессе планирования базы данных, пересматривается и уточняется. Предварительное планирование предполагает определение функций и количества используемых прикладных программ, приложений, находящихся в процессе создания. Эта информация помогает установить связи между текущими приложениями и определить, каким образом используется информация приложений, а также сформулировать будущие требования к системе. Проверка осуществимости определяет технологическую, операционную и экономическую осуществимость плана создания базы данных. Технологическая осуществимость предполагает определение доступности необходимого оборудования и программного обеспечения, необходимых для работы базы данных: имеются ли в наличии данные ресурсы, или необходимо их приобретение. Операционная осуществимость связана с определением квалификации и опыта специалистов, работающих с БД. Экономическая целесообразность предполагает получение определённой выгоды от внедрения базы данных. Этап определения требований включает выбор целей базы данных, выяснение информационных потребностей различных подразделений и требований к оборудованию и программному обеспечению. Информационные потребности могут выясняться с помощью анкет, опросов менеджеров и работников компании, а также на основе документов компании. Общая информационная модель, созданная на этапе планирования базы данных, разделяется на модели для каждого отдела компании, являющиеся основой для создания проекта следующего этапа. Этап концептуального проектирования включает создание концептуальной схемы базы данных. На этом же этапе создаются подробные модели пользовательских представлений, которые затем преобразуются в концептуальную модель, фиксирующую все элементы данных, которые будет содержать база данных. В процессе реализации базы данных выбирается и приобретается СУБД. Затем концептуальная модель преобразуется в проект реализации базы данных, создаётся словарь данных, база данных заполняется данными, создаются прикладные программы и обучаются пользователи. Построение словаря данных как центрального хранилища определений структуры данных – ключевой шаг в реализации базы данных. Словарь данных предназначен для системного персонала администрирования данных, прикладных программистов и конечных пользователей. Оценка базы данных включает опросы пользователей в целях выяснения неучтённых информационных потребностей. При необходимости вносятся изменения, обеспечивается поддержка системы путём добавления новых программ. Последний этап – снятие с эксплуатации базы данных. АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ. ОБСЛЕДОВАНИЕ СУЩЕСТВУЮЩЕЙ СИСТЕМЫ. Исследованию подвергаются: • Характер деятельности организации; • Организационная (должностная), функциональная структуры организации; • Документы и массивы, потоки данных; • Используемые средства обработки информации; • Затраты на функционирование системы. Характер деятельности организации. Определяются сфера деятельности организации, ее характер, цели и результаты функционирования, а также выполняемые функции управления. Функции управления ранжируются по приоритету и с учетом их взаимосвязи. Организационная (должностная), функциональная структура организации. Обследование системы предполагает определение организационной, функциональной структуры системы и анализе состава информации обрабатываемого системой. Организационная структура представляет собой перечень подразделений организации с учетом их подчиненности. Если в качестве объекта автоматизации выступает какое-либо одно - подразделение организации определяется должностная структура подразделения. Изучение должностной структуры дает возможность понять содержание используемых процедур управления, смысл некоторых документов, суть отношений между сотрудниками. В результате изучения определяется функциональная структура организации, функциональные обязанности лиц, имеющих отношение к разрабатываемой задаче. На этом этапе изучения следует помнить, что конкретная задача управления реализуется определенным набором функций, хотя часто встречается взаимозаменяемость этих понятий: задача - функция. При изучении обязанностей должностных лиц, имеющих непосредственное отношение к анализируемой задаче, особенно тщательно изучается круг их функциональных обязанностей, характер выполняемых ими работ и сроки выполнения. Изучение функциональных обязанностей каждого должностного лица должно быть направлено на выявление их перегрузки, а также основных недостатков существующей организационной структуры. Таким образом, в результате функционального анализа по каждому подразделению и должностному лицу определяется: перечень задач (функций) управления; содержание задачи управления (перечень реализующих данную задачу функций (операций)); периодичность выполнения задач и функций управления; количество работников, участвующих в реализации задачи, их образование, должность, затрачиваемое время; наличие и содержание формальных методов решения задач; применяемые технические средства. Документы и массивы. Обследование информационной составляющей предполагает: уточнение применяемой терминологии с целью обеспечение взаимопонимания персонала разработчика и заказчика; выявление используемых в организации внешних и внутренних документов, составлении схемы документооборота; анализ массивов информации; определение информационных связей организации и ее подразделений. Документы, которые предназначены для сбора и регистрации данных, называются входными (регистрационными, учетными) документами. Входными по отношению к административным процедурам обработки данных. Документы, вырабатываемые в результате обработки данных, называются Выходными (результирующими) документами. Документы, предназначенные для пользования внутри организации, называются внутренними документами. Документы поступающие или направляемые вне организации называются внешними документами. Прежде чем приступить к изучению каждого документа по отдельности, следует составить список всех документов, разрабатываемой задачи. Существование каждого документа должно быть обосновано, поскольку часто выясняется, что некоторые документы, хотя и существуют, но не используются. Должны быть выявлены причины не использования этих документов; неточное соответствие их назначению, перегрузка должностного лица, задержка в их поступлении. Массивы информации подлежащие исследованию могут быть или ручными или машинными. При изучении массивов необходимо собрать информации: наименование, носитель, место нахождения, структура записи, длина записи, число записей, процедуры ведения массивов, способы использования массивов, процедуры защиты массивов. Следует обратить внимание на ручные массивы информации, которые ведутся не по стандартным формам в тетрадях, личных записных книжках. Используемые средства обработки информации. При этих исследованиях определяется: - какие ручные процедуры выполняются при обработке данных; - с помощью каких средств выполняются процедуры; с какой скоростью выполняется процедура. Для каждого из используемых средств следует зафиксировать следующие сведения: тип средства; покупная цена; дата приобретения; срок амортизационного отчисления; расходы на содержания; ежегодная продолжительность использования. Эти сведения могут использоваться при определения экономических показателей. Анализ информационных потоков Для описания потоков информации на макроуровне и совершенствования существующих потоков информации используют графические и матричные методы, а также системные спецификации. Основными элементами информационного потока являются некоторые объемы информации на носителях и процедуры преобразования информации. Располагая эти элементы в виде вершин графа, дуги которого соответствуют передаче информации от одного элемента к другому, получают графическую модель в виде ориентированного графа. Наиболее удобно представлять модель в виде обобщенная структурно-информационно-временной схемы (ОСИВС), что позволяет проследить движение информации не только по логико-функциональным связям, но и по организационным. Схема ОСИВС служит для наглядного представления этапов решения основных задач, их последовательности, а также движения информации во времени по структурным подразделениям. На схеме по горизонтали откладывается масштаб времени в днях, неделях, месяцах - в зависимости от общей продолжительности решения рассматриваемых задач. По вертикали схема разбивается на ряд горизонтальных полос, каждая из которых соответствует организации или структурному подразделению. Удобно выделять средние полосы для структурных подразделений рассматриваемой организации, расположенные выше полосы для вышестоящих и ниже – для подчиненных организаций. На полученную сетку наносят этапы решения задач и движения информации. Применяемые при этом условные обозначения позволяют непосредственно на схеме вводить пояснения и количественные характеристики – шифр и наименование документа, частоту его формирования, объем содержащейся в документе и перерабатываемой информации в алфавитно-цифровых знаках. Логический анализ схемы позволяет проследить движение информации от входа к выходу, определить моменты и места образования и использования документов, процедуры преобразования информации, время обработки, наличие дублирования при вводе исходных данных и при их обработке, количество однотипных операций, излишние перемещения данных между подразделениями. При более глубоком анализе ОСИВС помогает выявить степень использования данных, действительную необходимость передачи их в то или иное подразделение. При исследовании информационных потоков на основе сетевой модели и стандартного аппарата ее анализа и оптимизации используется иная интерпретация. Под событием понимают определенный документ или машинный носитель, а под работой - процедуры преобразования информации: составление документов, объединение или расчленение документов, другие виды их преобразования и использования. По известным алгоритмам находят критический путь, начальные и конечные возможные и допустимые сроки выполнения работ, резервы времени для работ и событий. Оптимизация процесса переработки информации заключается как в перераспределении ресурсов, используемых для ее преобразования, так и в изменении содержания работ. Другой разновидностью методов, основанных на использовании теории графов, является графоаналитический метод, заключающийся в построении информационного графа и анализе его матрицы смежности. В качестве компонентов потока информации рассматриваются исходная, промежуточная и выходная информация в виде соответствующих наборов данных. Между компонентами информационного потока устанавливается отношение порядка: нулевой порядок имеют наборы данных исходной информации, а наивысший – выходные результаты. Упорядоченные таким образом компоненты представляют в виде графа, вершины хi которого отображают компоненты информационного потока, а дуги направление. Вершины соединяют дугами в том случае, если существует информационная связь между компонентами, представленными соответствующими вершинами, причем без промежуточных результатов. Их наличие требует введения дополнительной вершины между двумя рассматриваемыми. Дуги направлены от вершины более низкого порядка к вершине более высокого порядка. Построенный граф называют информационным. Граф может быть более компактно представлен матрицей смежности, которая строится следующим образом. Элемент (i, j) матрицы, находящийся на пересечении i-й строки и j-го столбца, равен единице, если вершины xi и xj соединены дугой, и равен нулю в противном случае. Матрицу смежности возводят во вторую, третью и тд. степень, пока не получат матрицу, равную нулю по всем элементам. Общее число полученных при этом матриц равно порядку информационного графа. Матричная модель описанного типа позволяет определить: порядок схемы потока информации; порядок каждой компоненты потока; число компонентов, непосредственно участвующих в формировании каждого результата; число результатов, в формировании которых непосредственно участвует каждая компонента; число путей фиксированной длины, связывающих любые две компоненты потока; число возможных путей между любыми двумя компонентами потока; все результаты, для формирования которых используется каждая компонента; все компоненты, необходимые для формирования каждого результата. Информационные потоки могут быть также представлены комплексом графов , на каждом из которых отображается преобразование информации при расчете отдельного показателя. Ребра графа ориентированы в виде дерева от исходных показателей к результирующим, которые в свою очередь являются исходными для следующего уровня укрупнения. Такая модель удобна, например, для отображения процесса формирования сводок о различных аспектах работы цехов, предприятий, объединений; при формировании плана и т.п. Если исходные показатели используются для формирования нескольких результирующих, возможно срастание деревьев – наличие у графов общих вершин и пересекающихся дуг. Для отображения процессов преобразования информации наряду с графовыми используют матричные информационные модели, которые отражают во взаимосвязанном виде процедуры создания документов, содержащих экономические показатели и другие реквизиты. Существует несколько типов матричных информационных моделей, выбор среди которых определяется в основном содержанием задач анализа. Так, например, для укрупненного анализа связей между подразделениями удобны модели типа "документ на документ", а для изучения процесса создания документа и последующего его использования предпочтительнее модели типа "показатель на показатель", хотя они и являются более громоздкими. Наиболее полное формализованное описание как изучаемой, так и проектируемой системы может быть представлено системными спецификациями. Они представляют собой комплект документов, назначение которого – представить в компактной и удобной для использования форме сведения о движении информации в системе, начиная с содержания и формы представления входных данных, описания процедур их обработки и контроля, информационных массивов и кончая формами представления выходных данных. Системные спецификации состоят из трех групп бланков, предназначенных соответственно для представления общих сведений о разрабатываемой системе, изучения и анализа информационных потоков и алгоритмов переработки данных, описания результатов проектирования. Значительные затраты времени и труда на заполнение бланков системных спецификаций требуют различного их применения. Их использование тем более эффективно, чем сложнее разрабатываемая система. Хорошо подготовленные спецификации упрощают передачу результатов работы одних специалистов другим, повышают качество проектирования за счет снижения вероятности пропусков и неточностей в процессе работы и формализации ввода исправлений и дополнений, упорядочивают планирование работ и контроль за их качеством и сроками выполнения. Описанные ниже бланки приведены в качестве примера и могут видоизменяться применительно к конкретным системам. В системных спецификациях для документов, массивов и процедур обработки информации целесообразно использовать по два вида бланков – укрупненные и детальные описания. Детализация требуется в тех случаях, когда соответствующие документы или массивы будут использоваться в создаваемой системе. Все бланки имеют идентификатор, помещенный в нижней правой части бланка. Он содержит шифр бланка и его порядковый номер. Нумерация бланков сквозная, по всем видам бланков. Для каждого типа бланков заранее выделяют группу номеров исходя из размерности задачи. Если содержание бланка не умещается на одной странице, используют несколько страниц с порядковой нумерацией в каждом случае. Номер страницы указывается через тире после номера бланка, после чего в скобках записывается общее число страниц этого бланка. Рядом с номером бланка в идентификаторе помещают наименование и шифры проекта и этапа, к которому относится данный бланк. В нижней левой части бланка указывается, кто его заполнил и проверил. Ни рис. 4 приведен бланк АД-1, который используется для общей характеристики документа. В графе "Приоритет" указывается, после каких или перед какими документами появляется описываемый, какие документы отменяет или заменяет. В графе "Метод подготовки (использования)" указывают, готовится ли документ путем расчета показателей, сбором сведений от источников информации и т.п., а его использование – для принятия управляющих решений, подготовки других документов и пр. В графе "Последовательность" указывается порядок следования сведений в данном документе. Все количественные характеристики, перечень которых может быть при необходимости изменен или дополнен, указываются при малых разбросах значений только в графе "среднее", а при больших разбросах заполняются все три графы "мин", "макс" и "среднее". В графе "Частота" приводится периодичность выдачи или получения документа – ежедневно, раз в месяц и т.п. Степень использования содержащихся в документе данных приводится в процентах от общего количества их в данном документе, В графе "Дублирование" приводятся наименования или шифры документов и информационных массивов, в которых имеются сведения, повторяющие содержащиеся в данном документе. Если образец документа прилагается, желательно, чтобы он был заполнен обычным образом. Цель использования указывается кратко по существу: подготовка отчета, расчет заявки и т.п. В последующих графах от "Обработки" до "Ссылка на" проставляется "крестик" или "галочка", если должностное лицо выполняет соответствующую операцию со всем документом или некоторыми данными из него. Наименование подразделения Шифр подразделения Вход/Выход Шифр документа Наименование документа Кем, когда утвержден Количество копий Источник (откуда поступает) Имеет отношение к документам Кем готовится (используется) Приоритет Метод подготовки (использования) Последовательность Характеристика мин макс среднее Время обработки Объем в знаках Частота Степень использования Дублирование Образец прилагается Движение документа № Долж-ность лица Цель исп-ния Степень использ. Обра-ботка Хра-нение Конт-роль Пере-дача Ссыл-ка на Прим. Дополнительные сведения Источник Заполнил Дата Проект(тема) Шифр Проверил Дата Этап(раздел) Шифр Рисунок 4 – Бланк АД-1 общей характеристики документа Второй бланк анализа документов АД-2 (рис. 5) предназначен для детального описания документа. Как указывалось, его заполнение целесообразно для тех документов, вероятность сохранения в системе которых достаточно велика. Наименования подразделения и документа должны совпадать с указанными на бланке АД-1. Под специальными требованиями понимается цвет бумаги, особый формат, недопустимость помарок и исправлений и т.п. Высший уровень 01 присваивается тем элементам документа, которые не являются составной частью никакого другого элемента, например шапка документа и его текстовая часть. Уровень 02 имеют элементы, непосредственно входящие составной частью в элемент уровня 01, уровень 03 - входящие в уровень 02, и т.д. Наименование подразделения Шифр подразделения Наименование документа Шифр документа Специальные требования Длина Ширина Уро-вень Наименование элемента Число симво-лов Шаблон Часто-та Использова-ние Дубли-рова-ние Прим. Дополнительные сведения Источник Заполнил Дата Проект(тема) Шифр Проверил Дата Этап(раздел) Шифр Рисунок 5 – Бланк АД-2 детального описания документа Например, описание сведений о сотруднике имеет следующий вид:  01 сведения о сотруднике  02 личные данные  03 фамилия  03 имя  03 отчество  02 сведения о рождении  03 место рождения 04 город, поселок, деревня  04 область, район  03 дата рождения  04 число  04 месяц  04 год Шаблон состоит из условных знаков: X – любой символ; А – буква; 9 – цифра; П – пробел. Число символов указывается повторением условных знаков или записью в скобках; например, четырехзначное обозначение года имеет шаблон 9999, или 9(4). Если число символов переменно, шаблон приводится для максимально возможного их числа; например, дата типа "01 мая 1987" имеет шаблон 9 (2) А (8) 9 (4). В графе "Частота" указывается средняя частота заполнения данного элемента в документах в долях единицы или процентах. В графах "Использование" и "Дублирование" указывают шифры документов или информационных массивов, в которых используется или повторяется информация, содержащаяся в данном элементе документа. Наименование подразделения Шифр подразделения Наименование массива Носитель Шифр Количество копий Последовательность записей в массиве Последовательность элементов в записях Метод подготовки Метод хранения Характеристика мин макс среднее Объем в знаках Количество записей Частота обращения к массиву Время поиска одной записи Имеет отношение к (номера бланков спецификаций) Степень использования Дублирование Кем обновляется Частота обновления Объем разового обновления мин макс среднее Данные используемые для обновления № Наименование вводимых данных Ссылка на АД Ссылка на АП Примечание Время хранения Условия передачи в архив № Долж-ность лица Цель исползования Частота Объем Ссылка на АП Примечание Источник Заполнил Дата Проверил Дата Рисунок 6 – Бланк описания массивов Для описания и анализа информационных массивов также используют два вида бланков - для укрупненного описания бланк АМ-1 и для детального - АМ-2 (рис. 6). В графах "Последовательность записей" и "Последовательность элементов" указывается индекс, по которому располагаются последовательные записи в массиве или элементы в записи. Графа "Имеет отношение к" должна содержать перечень шифров бланков, в которых описаны данные и процедуры их обработки, необходимые как для формирования, так и для использования описываемого массива. Заполнение остальных граф аналогично описанному выше. Для записи сведений об алгоритмах решаемых задач обработки данных укрупненно используют бланк АП-1 (рис. 7) и подробно - бланк АП-2 (не приводится). На бланке АП-1 указывается, что является исходной информацией для решения задачи или процедуры обработки данных; используемые при выполнении процедуры массивы; получаемая выходная информация. В центральной части приводится схема алгоритма или ОСИВС решения задачи, если она не приводилась раньше в виде самостоятельного бланка. В соответствии с этой схемой составляется бланк АД-2, на котором детально описываются отдельные операции типа: ввод, сортировка, выборка, сравнение, вычисление, контроль, передача, вывод. Для каждой операции указывается ее смысловое содержание, например сортировка по видам продукции, вычисление среднего значения и т.п.; приводятся сведения о частоте выполнения операции, ее продолжительности, трудозатратах и др. Наименование процедуры (задачи) Шифр Наименование подразделения Шифр подразделения Условия выполнения Кем выполняется Способ выполнения Применяемое оборудование Продолжительность выполнения мин макс Средняя/абс. № Вход Объем Частота Блок-схема (ОСИВС) № Выход Объем Частота Прим. Дополнительные сведения Источник Заполнил Дата Проект(тема) Шифр Проверил Дата Этап(раздел) Шифр Рисунок 7 – Бланк описания процедур МОДЕЛИРОВАНИЕ ДАННЫХ. классификация моделей данных Модель данных определяет структуру данных и правила их построения. Это определение является наиболее общим и может быть применено при рассмотрении данных с точки зрения ЭВМ, с точки зрения алгоритмических языков, с точки зрения БД, Модель данных ЭВМ включает: допустимые форматы данных, состав операций выполняемых с данными. Каждый язык программирования высокого уровня имеет свою модель данных, которая независима от машинной реализации и спроектирована для улучшения моделирования определенных видов реальных ситуаций или для удобства выполнения определенных видов вычислений и представления соответствующих типов данных. Модель данных алгоритмического языка включает: виды данных – переменные, массивы; типы данных – целые, вещественные и т.п.; состав операций выполняемых над данными (состав процедурных операторов языка). Модель данных – совокупность структур данных и операций над ними, для определения логической структуры БД и динамического моделирования состояний ПрО. Выделяются следующие виды моделей: 1. Модель ПрО – инфологические 2. Модель данных – концептуальные датотлогические 3. Модель БД – физическая. Модель предметной области (МПрО) МПрО может быть построена: • На основе анализа и интеграции информационных потребностей пользователей; • На основе анализа самой ПрО и учете потребностей пользователей. Концептуальная инфологическая модель ориентируется на пользователя, датологическая – на реализацию в вычислительной среде. Модель данных. Модель данных – совокупность правил порождения структур данных в БД, операций над ними, а также ограничений целостности, определяющей допустимые связи и значения данных, последовательности их изменения. Выделяют три вида моделей: • Иерархические • Сетевые • реляционные. Модель базы данных. Модель БД (МБД) является средством интеграции содержимого БД и реализации требуемых операций по обработке и управлению данными. МБД описывается схемой БД, которая определяет ее структуру и ограничения целостности и управления доступом. Разработанная администратором банка информации схема БД используется для сопровождения и доступа к данным БД. В соответствии с рассмотренной ранее трёхуровневой архитектурой ANSI/SPARC можно определить понятие модели данных по отношению к каждому уровню. На рисунке 8 представлена классификация моделей данных. Инфологические модели данных Информационная алгебра Информационная алгебра была разработана рабочей группой комитета CODASYL. Целью данной работы являлось создание структуры машинно-независимого языка описания задач, ориентированного на системный уровень обработки данных. Основой концептуальной модели является представление, что информационная система имеет дело с объектами и событиями реального мира, которые представляются в виде данных. Информационная алгебра оперирует понятиями «сущность» и «свойства». Сущность – нечто физически существующее в реальном мире. Сущность имеет свойства. Для каждой сущности каждому из её свойств приписывается значение из множества значений свойства. Также в информационной алгебре вводится ряд понятий: система координат, точка значений, пространство свойств. Вводятся также понятия комплекса и агрегата. При описании задач основной операцией является отображение одного подмножества пространства свойств на другое. Рассматриваются два типа отображений. Одно соответствует операциям в данном файле (можно, например, определить отображение группы из пяти точек для каждого рабочего в одну новую точку, которая будет содержать итог за неделю). Эта операция называется агрегированием. Второй тип отображения соответствует операции обработки файлов, при которой точки из некоторого числа входных файлов обрабатываются для получения нового выходного файла – комплексирование данных. Важно заметить, что в модели информационной алгебры выделены основополагающие элементы: сущности, свойства, значения свойства, которые позволяют адекватно описать некоторую предметную область и реально существующие объекты. Выделение этих элементов следует считать важным достижением. Здесь выделены три основные составляющие, присущие природе данных: носитель свойств («сущность»), сами свойства («свойства»), каждому из которых приписывается значение («значение свойства»), также вводится понятие пространства – «пространство свойств». Однако данная модель не отражает ряд важных моментов, присущих природе данных, в частности не учитывается, что: − носители свойств могут находиться в определённых отношениях друг с другом и образовывать некоторую структуру; − сами свойства между собой также могут находиться в некоторых отношениях. Рисунок 8 – Классификация моделей данных В модели CODASYL введено понятие значения показателя, при этом также необходимо указать некоторую характеристику упорядочения, такую как номер наблюдения, дату измерения показателя, время и т.п., чтобы была возможность различать ряд значений определённого объекта по определённому показателю. Данная характеристика, ввиду её природой естественности, в модели CODASYL присутствует неявно и входит в свойства. Выделение характеристики упорядочения позволяет при необходимости исследовать динамику изменения показателей, задать отношения: быть позже, быть раньше, относиться к одному интервалу (к неделе, месяцу, году), отстоять на определённый промежуток времени и др.; ввести операции усреднения по интервалам и подсчёта итоговых сумм за период. То есть использование характеристики упорядочения даёт возможность в значительной мере автоматизировать процесс подготовки данных для последующего анализа, в том числе статистического. Существует целое направление так называемых временных (temporal) баз данных, учитывающих изменения данных во времени. Модель Смитов В семантическом моделировании проектируется схема понятий прикладной области в их взаимосвязи. Предлагались и предлагаются различные пути такого моделирования. Вот, например, какие метапонятия рассматривали для концептуального моделирования в конце 1970-х гг. Дж. Смит и Д. Смит. Исходными базовыми понятиями в этих моделях являются объекты и связи между объектами. Связи могут быть двух видов: обобщение и агрегация (рис. 9). Рисунок 9 – Примеры связей Обобщение интуитивно ясно, и связывает одни объекты с другими, по смыслу более общими. Например, объект «животное» есть обобщение для объектов «собака» и «лошадь». Агрегация связывает разнородные объекты по признаку компонентного вхождения в другие объекты, как например, «колеса» и «кузов» связаны с «автомобилем» тем, что последний состоит из первых. Независимо оба вида связей образуют каждый свою иерархию среди объектов модели. Кроме этих базовых имеются и другие понятия концептуальной модели: атрибут, отношение, экземпляр, индивид. Самое замечательное в модели Смитов – это относительность перечисленных понятий. Одно и то же явление может быть и объектом, и отношением, и атрибутом, и экземпляром, и индивидом, и всё определяется точкой зрения на явление. Зависимость интерпретации от точки зрения на явление (а точнее – возможность выбора точек зрения с разной интерпретацией) – это очень мощное свойство, придающее концептуальной модели большую гибкость и приспособляемость в описании проектируемой ИС. Это свойство, например, будь оно реализовано, позволило бы в информационной системе смотреть на «адрес» то как на объект реестра адресов, то как на атрибут «лица», то как на отношение, связывающее владельца с остальными жильцами – когда, где и кому как нужно. Наиболее близко к концептуальной в этом отношении подошла (теоретическая) реляционная модель данных, а вот объектный подход с его фиксированной интерпретацией структуры отстоит от реляционного на шаг назад. В модели Смитов выделяются две иерархии – иерархия агрегаций (отношение разнородных объектов) и иерархия обобщений (по типу «собака, лошадь – животное»), в точках пересечения появляются абстрактные объекты. Вводится также ряд понятий: индивиды, категории, компоненты. Для успешной интеграции понятий существует «принцип относительности объектов», который утверждает, что индивиды, категории, отношения и компоненты – разные способы рассмотрения одних и тех же объектов. Разработана методология спецификаций, основанная на принципах относительности объектов и сохранения индивидов. Отказ от чёткого разграничения ролей объектов является одновременно и сильной и слабой стороной данной модели. Слабые стороны данной модели проявляются в тех случаях, когда можно чётко разделить объекты (носители свойств) и свойства, что характерно для систем статистической обработки. Можно отметить, что не существует формализма, позволяющего отличить объект от свойства, поэтому это должно задаваться извне для построения более конкретной модели. Модель Бахмана Модель Бахмана напоминает навигационную модель страниц и ссылок сегодняшнего Интернета, её иногда называют моделью навигации данных. На диаграммах Бахмана изображают типы записей и связи между типами записей. Следует учитывать, что это одна из первых инфологических моделей. Чарльз Бахман в GE (General Electric) построил прототип системы навигации по данным. За руководство работы инициативной группой DBTG, разработавшей стандартный язык определения данных и манипулирования данными, Бахман получил Тьюринговскую премию. В своей Тьюринговской лекции он описал эволюцию моделей плоских файлов к новому миру, где программы могут осуществлять навигацию между записями, следуя связям между записями. Идеологическая основа работы Бахмана (более «научно» называемая моделью базы данных) IDS, за которую Бахман заслуженно был удостоен в 1973 г. высшей компьютерной награды ACM, получила название «сетевой» (network). Модель «сущность-связь» Модель «сущность-связь». Наиболее популярной семантической моделью является модель «сущность-связь» (E/R – Entity/Relationship), предложенная Питером Пин-Шен Ченом в 1976 г. На использовании разновидностей E/R модели основано большинство современных подходов к проектированию баз данных (в основном реляционных). Данная модель имеет графическую природу, в ней используются изображения в виде диаграмм с прямоугольниками и стрелками, представляющие главные элементы данных и их связи. В данной модели выделены объекты (объектом называется «предмет, который может быть чётко идентифицирован») и свойства объектов. Таким образом, определяются отношения типа «объект-свойство». В связи с наглядностью представления данных модели «сущность-связь» получили широкое распространение в CASE-системах. Объектная модель Объектная модель – логическая схема объектной БД в одной из общепринятых систем описания (обозначений). Хотя, по выражению К. Дж. Дейта, «не существует общепринятой, абстрактной и формально определённой "объектной модели данных"» и применительно к «объектной "модели"» правильнее говорить об «удобном ярлыке для целой совокупности некоторых взаимосвязанных идей», конкретные CASE-системы, реализующие на свой лад некоторые из этих идей, всё же существуют. Объектная схема – схема БД конкретной объектной СУБД, для описания модели данных используются основные принципы объектно-ориентированного программирования. Многомерная модель Многомерная схема – схема данных в одной из многомерных систем представления данных. Данные представляются посредством гиперкуба (некоторого куба со множеством измерений). Информационные системы масштаба предприятия, как правило, содержат приложения, применяемые менеджерами высшего звена и предназначенные для комплексного многомерного анализа данных, их динамики, тенденций и т.п. Такой анализ в конечном итоге призван способствовать принятию решений. Нередко эти системы так и называются – системы поддержки принятия решений (DSS). Указанные приложения обычно обладают средствами предоставления пользователю агрегатных данных для различных выборок из исходного набора в удобном для восприятия и анализа виде. Чаще всего такие агрегатные функции образуют многомерный (а, следовательно, нереляционный) набор данных (нередко называемый гиперкубом или метакубом, оси которого содержат параметры, а ячейки – зависящие от них агрегатные данные). С середины 1990-х гг. интерес к многомерным моделям стал приобретать массовый характер. Многомерные системы позволяют оперативно обрабатывать информацию для проведения анализа и принятия решения. Многомерные СУБД предназначены для интерактивной аналитической обработки. По сравнению с реляционной моделью многомерная организация данных обладает более высокой наглядностью и информативностью. К основным понятиям многомерных моделей относятся измерение и ячейка. Измерение образуют множество однотипных данных, образующих одну из граней гиперкуба. Ячейка – это поле, значение которого однозначно определяется фиксированным набором значений. Рисунок 10 – Многомерная модель в виде OLAP-куба Тип поля определён как цифровой. Вдоль каждого измерения данные могут быть организованы в виде иерархии, отражающей различные уровни их детализации. Благодаря такой модели данных пользователи могут формулировать сложные запросы, генерировать отчёты, получать подмножества данных. При использовании более трех измерений представить и изобразить такой куб в рамках 3-мерного пространства, ограниченного высотой, шириной и глубиной, невозможно. В данном случае разработчики применяют специальные методы для отображения неотображаемого, например показ нескольких последовательностей (series) на одном графике. Каждая последовательность закрашивается отдельным цветом. Группа последовательностей представляет собой значение одного 4-го измерения. Технология комплексного многомерного анализа данных получила название OLAP (On-Line Analytical Processing). Концепция OLAP была описана в 1993 г. известным исследователем баз данных и автором реляционной модели данных Э. Ф. Коддом. Нередко для повышения скорости выполнения запросов пользователей данные кубов вычисляются заранее и хранятся в многомерной базе данных. Отметим, что многомерный анализ данных может быть осуществлён как в клиентском приложении, так и на сервере баз данных. Все производители ведущих серверных СУБД (IBM, Informix, Microsoft, Oracle, Sybase) производят серверные средства для такого анализа. Существует мнение, причём вполне обоснованное, что многомерные модели используются не для описания данных, а для их представления, так как «универсализация» отношений приводит к «потере точности» описания, но зато и к удобству восприятия информации конечным пользователем. Таким образом, значение многомерных схем – преимущественно «интерфейсное» (они удобны конечным пользователям), а не описательное. Модель «Объект-роль» Объект-роль – модель концептуального описания, принятая в системе Info Modeler фирмы Visio. В этой системе для модели «объект-роль» используется два языка: графический и [условно-] естественный. В данной модели предполагается отсутствие принципиального различия между объектами и свойствами, в ряде случаев они могут меняться местами, всё зависит от «роли», которой исполняет объект при определённом описании. Датологические модели Модели данных, используемые на концептуальном уровне, характеризуются большим разнообразием. По отношению к ним внешние модели называются подсхемами и используют те же абстрактные категории, что и концептуальные модели данных. Инфологические модели данных используются на ранних стадиях проектирования для описания структур данных в процессе разработки приложений. Инфологическая модель должна быть отображена в компьютерно-ориентированную даталогическую модель, поддерживаемую конкретной СУБД. В даталогическом аспекте рассматриваются вопросы представления данных в памяти информационной системы. Документальные модели данных Документальные модели данных применяются для представления слабоструктурированной информации, ориентированной в основном на свободные форматы документов, текстов на естественном языке (монографий, публикаций в периодике, текстов законодательных актов и т.п.). Модели, ориентированные на формат документа, связаны, прежде всего, с языками разметки документов. Стандартный обобщённый язык разметки документов SGML (Standard Generalized Markup Language) позволяет отделить аспекты содержания документов от аспектов его представления. Описание документов в этом языке не зависит от программно-аппаратной платформы, на которой осуществляется их обработка. На его основе разработаны программные системы управления документами, а также браузеры для просмотра размеченных документов. На основе языка SGML разработан язык гипертекстовой разметки HTML (Hyper Text Markup Language), применяемый для отображения статистических данных на Web-страницах. Этот язык определяет оформление элементов документа и имеет некий ограниченный набор инструкций – тегов, при помощи которых осуществляется процесс разметки. В качестве элемента гипертекстовой базы данных2, описываемой HTML, используется текстовый файл, который может легко передаваться по сети с использованием протокола HTTP. Эта особенность, а также то, что HTML является открытым стандартом и огромное количество пользователей имеет возможность применять возможности этого языка для оформления своих документов, безусловно, повлияли на рост популярности HTML и сделали его сегодня главным механизмом представления информации в Интернете. Кроме HTML в настоящее время используется язык гипертекстовой разметки XML (Extensible Markup Language). Он используется в качестве средства для описания грамматики других языков и контроля за правильностью составления документов. Сам по себе XML не содержит никаких тегов, предназначенных для разметки, он просто определяет порядок их создания. Тезаурусные модели основаны на принципе организации словарей и содержат определённые языковые конструкции и принципы их взаимодействия в заданной грамматике. Эти модели эффективно используются в системах-переводчиках, особенно многоязыковых переводчиках. Принцип хранения информации в этих системах подчиняется тезаурусным моделям. Дескрипторные модели – самые простые из документальных моделей, они широко использовались на ранних стадиях использования документальных баз данных. В этих моделях каждому документу соответствовал дескриптор – описатель. Этот дескриптор имел жёсткую структуру и описывал документ в соответствии с теми характеристиками, которые требуются для работы с документами в разрабатываемой документальной БД. Например, для БД, содержащей описание патентов, дескриптор содержал название области, к которой относился патент, номер патента, дату выдачи патента и ещё ряд ключевых параметров, которые заполнялись для каждого патента. Обработка информации в таких базах данных велась исключительно по дескрипторам, т.е. по тем параметрам, которые характеризовали патент, а не по самому тексту патента. Фактографические модели Фактографические модели представлены в виде специальным образом организованных совокупностей формализованных записей данных. Основанные на таких моделях фактографические системы используются не только для реализации информационно-справочных функций (в отличие от документальных систем), но и для решения задач обработки данных. Под обработкой данных понимается специальный класс решаемых на ЭВМ задач, связанных с вводом, хранением, сортировкой, отбором и группировкой данных однородной структуры. Центральным функциональным звеном фактографических систем является СУБД. В БД функцию описания данных выполняет язык описания данных, а выполняемые над данными операции определяются языком манипулирования данными. Основные операции над данными. Операции над данными отражают динамические свойства модели данных. Как правило, можно выделить следующие основные виды операций: 1. Идентификация одного данного и нахождения его положения в БД; 2. Выборка (чтение) данного из БД; 3. Включение (запись) данного в БД; 4. Удаление данного из БД; 5. Модификация (изменение) данного в БД. Операции над данными должны соотноситься с ЯМД СУБД. Ограничения целостности. Логические ограничения, которые накладываются на данные, называются ограничениями целостности. Ограничения используются в моделях данных для поддержания целостности данных при функционировании системы, т.е. СУБД должна обеспечивать непротиворечивость данных заданными ограничениями при переводе БД из одного состояния в другое. Использование ограничений связано также с адекватностью отражения предметной области с помощью данных, хранимых в БД. Например, «год рождения» не может быть больше «года поступления в институт». Выбор модели данных. • Возможность прямого моделирования. • Сложность и трудоемкость написания определенных данных и программирования для манипулирования структурами данных. • Сложность модели для изучения пользователем. • Простота, т.е. модель должна иметь минимальное число типов базисных структур и правил композиции. • Наглядность представления структуры данных. Хранимые в БД данные описываются различными моделями представления данных. К классическим (традиционным) моделям относятся: сетевая, иерархическая, реляционная. Сетевая и иерархическая модель являются историческими предшественниками реляционной. Все ранние (дореляционные) системы не основывались на каких-либо абстрактных моделях, понятие модели данных фактически появилось в лексиконе специалистов в области БД только вместе с реляционным подходом (в 1970-е гг.). В ранних системах доступ к БД производился на уровне записей. Пользователи этих систем осуществляли явную навигацию в БД, используя языки программирования, расширенные функциями СУБД. Интерактивный доступ к БД поддерживался только путём создания соответствующих прикладных программ с собственным интерфейсом. После появления реляционных систем большинство ранних систем было оснащено «реляционными» интерфейсами. Однако в большинстве случаев это не сделало их по-настоящему реляционными системами, поскольку оставалась возможность манипулировать данными в естественном для них режиме. СУБД, основанные на сетевой и иерархической моделях, используются и в настоящее время. Иерархические модели Иерархическая модель данных была создана в 1960-х гг. как отражение потребностей практики. Иерархическая модель состоит из упорядоченного набора экземпляров типа дерево. Тип «дерево» является составным (рис.11). Он может включать в себя подтипы («поддеревья»), также являющиеся типом «дерево». Тип «дерево» состоит из вершины («корневого» типа) и упорядоченного набора из нуля или более типов «поддеревьев». Каждый из элементарных типов, включённых в тип «дерево», является простым или составным типом «запись». Простая «запись» состоит из одного типа, например, символьного, а составная «запись» объединяет некоторую совокупность различных типов, например числовые и символьные. Корневой тип имеет подчинённые типы и сам не является подтипом (подчинённым типом). Подтип является потомком по отношению к предку (родителю). Рисунок 11 – Иерархический граф В примере Группа является предком для Староста и Студенты, а Староста и Студенты – потомки Группа (рис. 12). Рисунок 12 – Пример структуры типа «дерево» Между типами записи поддерживаются связи. Тип «дерево» в целом представляет собой иерархически организованный набор типов «запись». База данных представляет совокупность таких деревьев. Потомки одного и того же типа являются близнецами. В иерархической модели предусмотрены навигационные операции по структуре базы данных и операции манипулирования данными. Например, могут быть следующие операции: − найти указанное «дерево» БД (например, Группу 21 ИТ); − перейти от одного дерева к другому; − перейти от одной записи к другой внутри дерева (например, к следующей записи типа Студенты); − перейти от одной записи к другой в порядке обхода иерархии; − вставить новую запись в указанную позицию; − удалить текущую запись. Между предками и потомками автоматически поддерживается целостность ссылок. Основное правило: никакой потомок не может существовать без своего родителя, у некоторых родителей не может быть потомков. Иерархическая модель данных активно использовалась во многих СУБД до появления реляционных систем. Рисунок 13 – Пример хранения данных в базе данных «Живучесть» иерархических моделей обусловлена тем, что многие структуры данных естественным образом иерархичны (например, в области биологии: виды, классы, группы и т.д.). Сетевые модели Концепция сетевой модели данных была сформулирована в конце 1960-х гг. в Предложениях группы CODASYL, и с тех пор на неё ссылаются как на модель CODASYL DTBG. Сети представляют естественный способ представления отношений между объектами. Они широко применяются в математике, физике, социологии и других областях знаний. Сетевой подход к организации данных является расширением иерархического. В иерархических структурах запись-потомок должна иметь одного предка; в сетевой структуре данных потомок может иметь любое число предков. Рисунок 14 – Сетевой граф Сетевая БД состоит из набора записей и набора связей между этими записями. Тип связи определяется для двух типов записи: предка и потомка. Экземпляр типа связи состоит из одного экземпляра типа записи предка и упорядоченного набора экземпляров типа записи потомка. Для данного типа связи С с типом записи предка P и типом записи потомка PT должны выполняться следующие два условия: 1) каждый экземпляр типа P является предком только в одном экземпляре C; 2) каждый экземпляр PT является потомком не более чем в одном экземпляре С. На формирование типов связи не накладываются особые ограничения, т.е. возможны, например, следующие ситуации: − тип записи потомка в одном типе связи может быть типом записи предка в другом типе связи (как в иерархии); − данный тип записи P может быть типом записи предка в любом числе типов связи; − данный тип записи P может быть типом записи потомка в любом числе типов связи; − может существовать любое число типов связи с одним и тем же типом записи предка и одним и тем же типом записи потомка; и если L1 и L2 – два типа связи с одним и тем же типом записи предка P и одним и тем же типом записи потомка C, то правила, по которым образуется родство, в разных связях могут различаться; − типы записи X и Y могут быть предком и потомком в одной связи и потомком и предком – в другой; − предок и потомок могут быть одного типа записи. Рисунок 15– Пример сетевой схемы Примерный набор операций для манипулирования данными может быть следующим: − найти конкретную запись в наборе однотипных записей; − перейти от предка к первому потомку по некоторой связи ; − перейти к следующему потомку в некоторой связи; − перейти от потомка к предку по некоторой связи; − создать новую запись; − удалить запись; − изменить запись; − включить в связь; − исключить из связи; − переставить в другую связь и т.д. В принципе поддержание целостности связей не требуется, но иногда требуют целостности по ссылкам (как в иерархической модели). Системы на основе сетевой модели не получили широкого распространения на практике. Реляционные модели Реляционный подход формировался в 1970-е гг. Публикация известной статьи Э. Ф. Кодда о реляционной модели данных (в июне 1970 г.) стимулировала целый ряд математических исследований, направленных на изучение свойств реляционных баз данных, впоследствии приведших к созданию теории реляционных баз данных. В своих работах Э. Ф. Кодд описал математические основы реляционной модели. Основная идея Кодда состояла в том, чтобы применить концепцию математических отношений к моделированию данных. Отношение – это таблица из строк и столбцов. Наиболее важные характеристики реляционной модели заключаются в следующем: − Описание данных производится в соответствии с их естественной структурой, т.е. не требуется добавления дополнительных структур для машинного представления. − Обеспечивается независимость данных от их физического представления, от связей между данными и от соображений реализации. − Модель обеспечивает строгую математическую основу для интерпретации выводимости, избыточности и непротиворечивости отношений. Рисунок 16 – Пример табличной организации данных В это же время компания IBM начала разработку нескольких исследовательских проектов и программных продуктов-прототипов, нацеленных на создание реляционных СУБД. Благодаря успешному созданию исследовательских прототипов, реляционная теория стала активно продвигаться на практике. В 1980-х гг. было создано большое количество коммерческих реляционных продуктов – от компаний IBM, Oracle Corp., Ingres Corp. и других поставщиков. В настоящее время реляционные СУБД доминируют на рынке инструментальных средств разработки систем баз данных. Реляционные системы продолжают совершенствоваться и их внутренняя природа значительно меняется. В связи с распространением объектного подхода в 1990-е гг. появились объектно-реляционные модели. Расширяется и сфера применения реляционных систем. Примером развития реляционной модели является постреляционная модель. Классическая реляционная модель предполагает неделимость данных, постреляционная модель снимает ограничение неделимости данных, допускает многозначные поля, состоящие из множества значений. Физические модели Физическая организация данных оказывает основное влияние на эксплуатационные характеристики базы данных. Разработчики пытаются создать наиболее производительные физические модели данных, предлагая пользователям тот или иной инструментарий для поднастройки модели под конкретную СУБД. Физическая модель данных оперирует категориями, касающимися организации внешней памяти и структур хранения, используемых в данной операционной среде. В настоящий момент в качестве физических моделей используются различные методы размещения данных, основанные на файловых структурах: это организация файлов прямого и последовательного доступа, индексных файлов и инвертированных файлов, файлов, использующих различные методы хеширования, взаимосвязанных файлов. Кроме того, современные СУБД широко используют страничную организацию данных. Физические модели данных, основанные на страничной организации, являются наиболее перспективными. РАЗРАБОТКА МОДЕЛИ ПРЕДМЕТНОЙ ОБЛАСТИ ТИПА «СУЩНОСТЬ-СВЯЗЬ» Модель типа «сущность-связь» – это неформальная модель предметной области, которая используется на этапе инфологического проектирования БД. Основное назначение неформальной модели «сущность-связь» – семантическое описание ПрО и представление информации для обоснования выбора видов моделей и структуры данных. При построении модели используется три основных конструктивных элемента для представления составляющих ПрО: • Сущность • Атрибут • Связь Информация о проекте объединяется с помощью графических диаграмм. Сущность – это собирательное понятие, некоторая абстракция реально существующего объекта, процесса или явления, о котором необходимо хранить информацию в системе. Тип сущности определяет набор однородных элементов. Экземпляр сущности – конкретный объект в наборе. Каждый тип сущности должен быть поименован. Для идентификации конкретных экземпляров сущностей в некотором типе используются специальные атрибуты – идентификаторы. Атрибут – это поименованная характеристика сущности, которая принимает значения некоторого множества значений. В модели атрибут выступает в качестве средства, с помощью которого моделируются свойства сущностей. Пример: Сущность КНИГА Атрибуты НАЗВАНИЕ, ФАМИЛИЯ_АВТОРА, ГОД_ИЗДАНИЯ Чтобы задать атрибут в модели необходимо: • Присвоить ему наименование; • Привести смысловое значение; • Определить множество допустимых значений; • Дать назначение. Основное назначение атрибута – описание свойств сущности, а также идентификация экземпляров сущностей. Атрибут или набор атрибутов, которые могут быть использованы для однозначной идентификации экземпляра сущности называются первичным ключом. Связи – выступают в модели в качестве средства, с помощью которого представляют отношения между сущностями, имеющими место в ПрО. Тип связи рассматривается между типами сущностей. Существуют следующие виды бинарных связей: • бинарные • терные • n -арные. Классификация бинарных связей. Отображение 1:1 (Связь один к одному) С помощью отображения 1:1 определяют такой тип связи между типами сущностей А и В, когда каждому экземпляру сущности А соответствует один и только один экземпляр сущности В и наоборот. Т.е. А однозначно идентифицирует В и, наоборот, В однозначно идентифицирует А. Рисунок 17 – Бинарная связь 1:1 Отображение 1:М (Связь один ко многим) С помощью отображения 1:М определяют такой тип связи между типами сущностей А и В, когда одному экземпляру сущности А соответствует несколько или ни одного экземпляра сущности В, а каждому экземпляру сущности В соответствует только один экземпляр А. Связь можно охарактеризовать как «имеет в составе». Рисунок 18 – Бинарная связь 1:М Отображение М:1 (Связь многие к одному) Связь обратная 1:М. Характеризуется как «входит в состав» Рисунок 19 – Бинарная связь М:1 Отображение М:М (Связь многие ко многим) С помощью отображения М:М определяют такой тип связи между типами сущностей А и В, когда каждому экземпляру сущности А соответствует несколько или ни одного экземпляра сущности В и наоборот. Рисунок 20 – Бинарная связь М:М Информация о проекте оформляется составлением спецификаций по сущностям, атрибутам и связям с использованием графических диаграмм. Сущность: Атрибут: Связь: Пример: На рисунке приведена диаграмма модели типа «Сущность-Связь» Спецификация сущностей: ПАЦИЕНТ Первичный ключ - № КАРТЫ ВРАЧ Первичный ключ – ТАБЕЛ. № ЗАБОЛЕВАНИЕ Первичный ключ – ШИФР Спецификация атрибутов: № КАРТЫ: цифровой, 6 символов, идентификация пациента, хранит номер карты пациента ФИО: символьный, 80 символов, хранит информацию о ФИО ……………………………… Спецификация связей: ПАЦИЕНТ лечится у ВРАЧ тип М:М ПАЦИЕНТ перенес ЗАБОЛЕВАНИЕ тип 1:М Рисунок 21 – Пример диаграммы «Сущность–Связь» Класс принадлежности. Если экземпляры данной сущности должны участвовать в связи, то участие называется обязательным. имеет СТУДЕНТ ( . ) ( . ) ОЦЕНКА Если экземпляры данной сущности могут не участвовать в связи , то участие называется необязательным. ведет ПРЕПОДАВАТЕЛЬ ( ) ( . ) ДИСЦИПЛИНА На графической диаграмме ... Обязательная. Необязательная. Разработка РЕЛЯЦИОННой МОДЕЛи ДАННЫХ Определение реляционных отношений Один из самых естественных способов представления данных – это двумерная таблица. Она привычна для пользователя, понятна и обозрима. Как люба сетевая структура с некоторой избыточностью может быть разложена на совокупность древовидных структур, так и любое представление данных может быть сведено к двумерным плоским файлам (таблицам). Таблицы строятся таким образом, что информация о связях между элементами данных не теряется. Сами таблицы являются двумерными массивами и описываются математически на основе понятий реляционной алгебры. Свойства таблиц: 1. Каждый элемент таблицы представляет собой элемент данных, повторяющиеся группы отсутствуют. 2. Все столбцы в таблице однородны. 3. Столбцам присвоены имена. 4. В таблице нет двух одинаковых строк. 5. В операциях с таблицами ее строки и столбцы могут просматриваться в любом порядке и в любой последовательности безотносительно к их информационному содержанию. Таблицы такого вида называются отношениями. Математически отношение определяется следующим образом: Пусть даны N множеств D1,D2,…,DN, тогда R есть отношение над этими множествами, если R есть множество упорядоченных n-кортежей вида d1,d2,…,dN , где d1 – элемент из D1, d2 – элемент из D2, dN – элемент из DN. D1, D2, DN называются доменами отношения R. Пример приведен на рис. 22. Домен D1: Домен D2: Домен D3: Домен D4: 101 102 103 болт гайка красный 9 11 12 14 104 105 106 муфта зажим синий 17 7 21 23 гвоздь винт зеленый желтый отношение кортеж Рисунок 22 – Пример отношения Здесь 4 домена: D1 – множество целых чисел; D2 – множество символьных строк, представляющих названия деталей; D3 – множество символьных строк названий цветов; D4 – множество целых чисел. Отношение R состоит из 4 кортежей. Каждый кортеж из 4 элементов, которые выбираются каждый из своего домена. С точки зрения обработки данных отношение можно рассмотреть в следующих аналогиях (рис.23). Сущность Атрибут сущности (Имя файла) (поле в записи) ДЕТАЛЬ НОМЕР_ДЕТ НАЗВАНИЕ_ДЕТ ЦВЕТ ВЕС 101 болт черный 9 102 муфта синий 11 103 винт зеленый 12 104 зажим желтый 17 Одна запись Значение атрибута (значение поля в записи) Файл Рисунок 23 – Отношения в обработке данных Четыре домена соответствуют четырем элементам реального мира: номер детали, название, цвет, вес. Отношение принимает вид таблицы или файла, где кортежи – строки таблицы или записи в файле. Имена столбцов называются атрибутами, а индивидуальное значение, появляющееся в отдельных кортежах – значением атрибута. Число столбцов в отношении называется степенью. Число кортежей – мощностью. Реляционная база данных определяется как совокупность отношений, содержащих всю информацию хранимую в БД. Отношение имеет имя, которое отличает его от имён всех других отношений. Атрибутам реляционного отношения назначаются имена, уникальные в рамках отношения. Обращение к отношению происходит по его имени, а обращение к атрибуту – по имени отношения и имени атрибута. Атрибут может быть обязательным и необязательным. Значение обязательного атрибута должно быть определено в момент внесения данных в БД. Если атрибут необязательный, то для таких случаев предусмотрено специальное значение – NULL, которое можно интерпретировать как «неизвестное значение». Значение NULL не привязано к определённому типу данных, т.е. может назначаться данным любых типов. Каждое отношение в БД хранится в отдельном файле. Записи файлов имеют одинаковый формат. СУБД сохраняет отношение в виде индексного файла, где индекс представляет собой как правило первичный ключ отношения. Первичный ключ – атрибут или набор атрибутов, которые могут быть использованы для однозначной идентификации конкретного кортежа. Значение первичного ключа должно быть уникальным (unique) и обязательным (not null). Для связей между отношениями используются внешние ключи. Внешний ключ (foreign key) – это атрибут подчинённого (дочернего) отношения, который является копией первичного (primary key) или уникального (unique) ключа родительского отношения. Фактически внешние ключи логически связывают экземпляры сущностей разных типов (родительской и подчинённой сущностей). Внешний ключ – это ограничение целостности, в соответствии с которым множество значений внешнего ключа является подмножеством значений первичного или уникального ключа родительской таблицы. Ограничение целостности по внешнему ключу проверяется в двух случаях: • при добавлении записи в подчинённую таблицу СУБД проверяет, что в родительской таблице есть запись с таким же значением первичного ключа; • при удалении записи из родительской таблицы СУБД проверяет, что в подчинённой таблице нет записей с таким же значением внешнего ключа. Ограничения целостности должны поддерживаться СУБД. Для соблюдения целостности сущностей достаточно гарантировать отсутствие в отношении кортежей с одним и тем же значением первичного ключа. Со ссылочной целостностью значительно сложнее. Необходимо следить за тем, чтобы не появлялись некорректные значения внешних ключей при обновлении отношений (например, заказы несуществующих клиентов). При удалении кортежа существует три подхода, позволяющие поддерживать ссылочную целостность: − запрещается производить удаление кортежа, на который существуют ссылки (либо сначала удалить ссылающиеся кортежи, либо изменить значения их внешнего ключа); − при удалении кортежа, на который имеются ссылки, во всех ссылающихся кортежах значение внешнего ключа становится неопределённым; − при удалении кортежа из отношения, на которое ведётся ссылка, из ссылающегося отношения автоматически удаляются все ссылающиеся кортежи (каскадное удаление). Большинство современных СУБД способны контролировать соблюдение правила ссылочной целостности. Для этой цели используются различные объекты баз данных (ссылочные ограничения и правила, триггеры и др.). Схема отношения (заголовок отношения) представляет собой список имен атрибутов. Например, ПРОВАЙДЕРЫ INTERNET (Название Провайдера, Почасовая Оплата, Скорость, Web-сайт). Множество собственно кортежей отношения часто называют содержимым (телом) отношения. Список, в котором указываются имена реляционных таблиц с перечислением их атрибутов (первичные ключи подчёркнуты) и определений внешних ключей, называется реляционной схемой базы данных. Результат проектирования БД оформляется следующим образом: Название БД: ____________________________ Спецификация отношений: Имя отношения ( перечень атрибутов) Первичный ключ отношения: _____________ Возможные ключи:______________________ Вторичные ключи: ______________________ ………………… Внешние ключи: _______________________ Спецификация атрибутов: Имя атрибута Назначение атрибута Тип Допустимые значения Примечание ПОЛУЧЕНИЕ РЕЛЯЦИОННЫХОТНОШЕНИЙ ИЗ ДИАРАММ ER – ТИПА Процесс получения реляционных отношений основывается на учете связей между сущностями диаграммы в схеме отношения. Связанность сущность обеспечивается включением в реляционное отношение первичных ключей сущностей. Правила формируются в зависимости от вида бинарной связи и класса принадлежности сущности. Правило 1: Если степень бинарной связи равна 1:1 и класс принадлежности обеих сущностей является обязательным, то требуется только одно отношение, объединяющее атрибуты двух сущностей. Первичным ключом этого отношения может быть ключ любой из двух сущностей. Правило 2: Если степень бинарной связи равна 1:1 и класс принадлежности одной сущности является обязательным, а другой необязательным , то необходимо построение двух отношений. Под каждую сущность необходимо выделить по одному отношению, при этом ключ сущности должен служить первичным ключом для соответствующего отношения. При этом ключ сущности, для которой класс принадлежности является необязательным, добавляется в качестве атрибута в отношение, выделенное для сущности с обязательным классом принадлежности. Правило 3: Если степень бинарной связи равна 1:1 и класс принадлежности обеих сущностей является необязательным, то необходимо построение трех отношений: по одному для каждой сущности, ключи которых служат в качестве первичных ключей соответствующих отношений, и одно для связи. Среди своих атрибутов отношение, выделенное для связи, будет иметь ключи сущностей. При построении отношений для связи 1:М учитывается класс принадлежности М-связанной сущности. Класс принадлежности 1-связанной сущности на конечный результат не влияет. Правило 4: Если степень бинарной связи 1:М и класс принадлежности М-связанной сущности является обязательным, то достаточным является использование двух отношений, по одному на каждую сущность. При условии, что ключ каждой сущности служит в качестве первичного ключа для соответствующего отношения. Дополнительно ключ 1-связанной сущности должен быть добавлен как атрибут в отношение, отведенной для М-связанной сущности. Правило 5: Если степень бинарной связи 1:М и класс принадлежности М-связанной сущности является необязательным, то достаточным является использование трех отношений, по одному на каждую сущность, причем ключ каждой сущности служит первичным ключом соответствующего отношения, и одного отношения для связи. Отношение для связи должно иметь среди своих атрибутов ключ каждой сущности. Правило 6: Если степень бинарной связи равна М:М, то необходимо три отношения: по одному на каждую сущность с первичными ключами от соответствующих сущностей, и одно отношение для связи. Отношение для связи должно иметь среди своих атрибутов ключ каждой сущности. Процесс проектирования БД 1. Возможность хранения всех необходимых данных. 2. Исключение избыточности. 3. Сведения числа хранимых в БД отношений к минимуму. Решение проблем избыточности, корректировки и обновления данных решается, как правило, разбиением отношения на несколько независимых. Это приводит к общему увеличению числа отношений и соответственно файлов. Это приводит к сложностям пользования и ведения БД. 4. Нормализация отношений для упрощения процедур обновления и удаления данных. Определение избыточности данных. При решении этой задачи необходимо определить что является избыточностью, а что необходимым дублированием. ТЕМА Шифр темы Исполнитель 111 Исп-1 112 Исп-2 113 Исп-1 114 Исп-1 В поле исполнитель на первый взгляд наблюдается избыточность. Если привести данные к виду Шифр темы Исполнитель 111 Исп-2 112 Исп-1 113 --- 114 --- То если удалить запись 111 не будет известен исполнитель тем 113 и 114. Таким образом, это пример не избыточности данных, а необходимого неизбыточного дублирования. Если отношение ТЕМА расширить атрибутом ТЕЛЕФОН ШИФР ТЕМЫ ИСПОЛНИТЕЛЬ ТЕЛЕФОН Мы получим пример избыточного отношения по атрибуту ТЕЛЕФОН. Достаточно хранить один экземпляр телефона для каждого исполнителя. В этом случае для устранения избыточности необходимо получить два отношения. ТЕМА (ШИФР_ТЕМЫ, ИСПОЛНИТЕЛЬ) ТЕЛ._ИСПОЛНИТЕЛЯ (ИСПОЛНИТЕЛЬ, ТЕЛЕФОН) Аномалии вставки, удаления и обновления. Вставка. При добавлении новых экземпляров отношения может возникнуть ситуация , когда некоторые из атрибутов не имеют значения ( они могут принимать значение 0 для арифметических данных или пробелы для символьных данных, если событие еще не наступило). При обработке запросов по таким данным будут выдаваться искаженные результаты. Обновление. Если имеет место большая избыточность данных, то к одному и тому же объекту может относиться несколько кортежей. В этом случае изменения должны вноситься во все записи относящиеся к этому объекту. Удаление. Аномалия сводится к тому, что при необходимости удаления некоторых значение атрибутов в случае определенной избыточности данных, удаляется вся запись. Нормализация реляционных отношений Функциональная зависимость Процесс разбиения отношения с целью уменьшения вероятности возникновения аномалий манипулирования данными называется декомпозицией. Логической и методической основой декомпозиции является концепция функциональной зависимости между атрибутами в рассматриваемом отношении. Определение функциональной зависимости: Если даны два атрибута А и В, то говорят, что В функционально зависит от А, если для каждого значения А существует ровно одно связанное с ним значение В в любой момент времени: А →В При этом А и В могут быть не только атомарными, но и составными. На практике это сводится к тому, что функциональная зависимость В от А означает, что если в любой момент времени известно значение А, то можно одновременно найти значение атрибута В. Отсутствие функциональной зависимости А В. СТУДУНТ ( НЗК, ФИО, НОМ_ГР ) НЗК → ФИО НЗК → НОМ_ГР Определение функциональной зависимости через термины реляционной алгебры: Пусть R (A1,A2,…,AN) - схема отношения, X и Y – подмножества (A1,A2,…,AN). Говорят, что Х функционально определяет Y (X→Y) , если в любом отношении R, являющемся текущим значением R, не может содержаться два кортежа, компоненты которых совпадают по всем атрибутам, принадлежащим множеству Х, но не совпадают по одному или более атрибутам принадлежащим множеству Y. Определение детерминанты: Если А → В есть функциональная зависимость и В не зависит функционально от любого подмножества А, то говорят что А представляет собой детерминант В или В функционально полно зависит от А (А В). УСПЕВ ( НЗК, ФИО, ДИСЦ., ОЦЕНКА, ДАТА ) НЗК+ДИСЦ. полностью определяет атрибут ОЦЕНКА. Единственный способ определения функциональной зависимости для схемы отношения заключается в тщательном анализе семантики атрибутов этого отношения. В этом смысле зависимости являются фактически отображением связей, существующих в реальном мире. Исходя из функциональной зависимости можно определить как первичные, так и возможные ключи. Наличие тех или иных зависимостей в схеме отношения определяет степень ее нормализации. Существует 4 нормальные формы и еще одна дополнительная нормальная форма Бойса-Кодда. Определение 1 НФ: Отношение находится в 1 НФ если каждый его элемент имеет и всегда будет иметь атомарное строение. В этом случае реляционное отношение представлено в виде множества неповторяющихся кортежей. Эта форма является достаточной для работы языков запросов СУБД. Определение 2 НФ: Отношение задано во 2НФ, если оно является отношением в 1 НФ и каждый атрибут не являющийся первичным атрибутом в этом отношении, полностью зависит от любого возможного ключа этого отношения. Первичным называется атрибут, которые входят хотя бы в один из возможных ключей. Если все возможные ключи отношения содержат по одному атрибуту, то это отношение задано во 2НФ, т.к. в этом случае все атрибуты не являющиеся первичными полностью зависят от возможных ключей. Если ключи составные, отношение заданное в 1НФ может не быть отношением во 2НФ. ПОСТАВКА (НОМЕР_ИЗДЕЛИЯ, НОМЕР_ПОСТАВЩИКА, ИМЯ_ПОСТАВЩИКА, СВЕДЕНИЯ_О_ ПОСТАВЩИКЕ, ЦЕНА) НОМЕР_ИЗДЕЛИЯ, НОМЕР_ПОСТАВЩИКА → ЦЕНА НОМЕР_ПОСТАВЩИКА → ИМЯ_ПОСТАВЩИКА СВЕДЕНИЯ_О_ ПОСТАВЩИКЕ ПОСТАВКА (НОМЕР_ИЗДЕЛИЯ, НОМЕР_ПОСТАВЩИКА, ЦЕНА) ПОСТАВЩИК(НОМЕР_ПОСТАВЩИКА, ИМЯ_ПОСТАВЩИКА, СВЕДЕНИЯ_О_ ПОСТАВЩИКЕ) Определение НФБК: Отношение находится в НФБК, если каждый детерминант отношения является возможным ключом. Определение 3 НФ: Отношение задано в 3 НФ, если оно задано во 2 НФ и каждый атрибут из отношения, не являющийся первичным, нетранзитивно зависит от каждого возможного ключа. Пусть А, В, С – атрибута реляционного отношения. Если С зависит от В, а В – от А, то С зависит от А. Если при этом обратное соответствие неоднозначно (т.е. А не зависит от В или В не зависит от С), то говорят, что С транзитивно зависит от А. А В С Преобразование в 3НФ состоит в разбиении исходного отношения на два: А В В С Определение 4 НФ: Схема реляционного отношения задана в 4 НФ, если при существовании многозначной зависимости Х Y, где Y не является пустым множеством, Y не принадлежит Х, причем ХY состоит не из всех атрибутов отношения, также существует зависимость Х → А для любого атрибута А отношении. СЛУЖАЩИЙ СЛУЖАЩИЙ ИН.ЯЗЫК ДОЛЖНОСТЬ ГОД Иванов Английский инженер 1996 Иванов Немецкий инженер 1996 Иванов Немецкий Ст.инженер 1998 Иванов Английский Ст.инженер 1998 Сидоров Французский Вед.инженер 1998 Сидоров Французский Руководитель 1999 Сидоров Испанский Вед.инженер 1999 Сидоров Испанский Руководитель 1999 СЛУЖАЩИЙ ИН.ЯЗЫК СЛУЖАЩИЙ ДОЛЖНОСТЬ Для устранения избыточности выполняет разбиение ЯЗЫК СЛУЖАЩИЙ ИН.ЯЗЫК Сидоров Французский Сидоров Испанский Иванов Английский Иванов Немецкий ДОЛЖНОСТЬ СЛУЖАЩИЙ ДОЛЖНОСТЬ ГОД Сидоров Вед.инженер 1998 Сидоров Руководитель 1999 Иванов Инженер 1996 Иванов Ст.инженер 1998 Алгоритм декомпозиции. Предлагаемый алгоритм целесообразно использовать, если в БД учитывается порядка 20-30 атрибутов. Так как в основу алгоритма полагается удовлетворение НФБК, то еще остается 3 нормальная форма, которая налагает еще более жесткие ограничения. 1. Разработка универсального отношения для БД. Универсальное реляционное отношение представляет собой совокупность атомарных атрибутов составляющих БД. В случае повторяющихся групп, они оформляются путем введения избыточности данных. СЛУЖАЩИЙ ШИФР ФАМИЛИЯ ОБРАЗ-Е ОТДЕЛ ДОЛЖН. 0341 Иванов высшее 31 Инженер 0341 Иванов высшее 31 Ст. инж-р 0341 Иванов высшее 31 Вед. Инж-р Атрибуты ОТДЕЛ и ДОЛЖН. представляют повторяющуюся группу. Такая корректно заполненная таблица представляет собой универсальное реляционное отношение. 2. Определение всех функциональных зависимостей между атрибутами отношения. 3. Определение того, что находится ли отношение в НФБК. Если «ДА» проектирование завершается, если «НЕТ», отношение должно быть разложено на два отношения. Декомпозиция выполняется следующим образом: Пусть отношение R (A, B, C, D, E…) не приведено к нормальной форма Бойса- Кодда. Определяется функциональная зависимость C → D, про которую известно, что она является причиной того, что отношение не находится в НФБК. С является детерминантом, но не является возможным ключом. Создаются два новых отношения. R1 ( A, B, C, E…) R2 ( C,D ) Отношение R2 называется проекцией отношения R. Этот метод декомпозиции называется декомпозицией без потерь. УСПЕВАЕМОСТЬ ( НЗК, ФИО, НОМЕР_КОМН., НОМЕР_ТЕЛ., ДИСЦ., СЕМЕСТР, ОЦЕНКА) Возможные ключи: НЗК+ДИСЦ.+СЕМЕСТР Детерминанты: НЗК+ДИСЦ.+СЕМЕСТР → ОЦЕНКА НЗК → ФИО НОМЕР_КОМН. НОМЕР_КОМН. → НОМЕР_ТЕЛ. УСПЕВАЕМОСТЬ ( НЗК, ДИСЦ., СЕМЕСТР, ОЦЕНКА) СТУДЕНТ ( НЗК, ФИО, НОМЕР_КОМН.) ОБЩЕЖИТИЕ ( НОМЕР_КОМН., НОМЕР_ТЕЛ) 4. Повторение шагов 2 и 3 для каждого нового отношения, полученного в результате декомпозиции. УСПЕВАЕМОСТЬ ( НЗК, ДИСЦ., СЕМЕСТР, ОЦЕНКА) Возможные ключи: НЗК +ДИСЦ.+СЕМЕСТР Детерминанты: НЗК +ДИСЦ.+СЕМЕСТР → ОЦЕНКА Список возможных ключей совпал с списком детерминант, следовательно реляционное отношение находится в НФБК. СТУДЕНТ ( НЗК, ФИО, НОМЕР_КОМН.) Возможные ключи: НЗК Детерминанты: НЗК → ФИО НОМЕР_КОМН. Список возможных ключей совпал с списком детерминант, следовательно реляционное отношение находится в НФБК. ОБЩЕЖИТИЕ (НОМЕР_КОМН., НОМЕР_ТЕЛ) Возможные ключи: НОМЕР_КОМН. Детерминанты: НОМЕР_КОМН. → НОМЕР_ТЕЛ. Список возможных ключей совпал с списком детерминант, следовательно реляционное отношение находится в НФБК. В этом примере можно найти иллюстрацию нормализации реляционного отношения по 2 НФ. Здесь наблюдается транзитивная зависимость НЗК → НОМЕР_КОМН. → НОМЕР_ТЕЛ. ОСНОВЫ РЕЛЯЦИОННОЙ АЛГЕБРЫ Основная идея реляционной алгебры состоит в том, что коль скоро отношения являются множествами, средства манипулирования отношениями могут базироваться на традиционных теоретико-множественных операциях, дополненных некоторыми специальными операциями, специфичными для реляционных баз данных. Математически отношение определяется следующим образом: Пусть даны N множеств D1,D2,…,DN, тогда R есть отношение над этими множествами, если R есть множество упорядоченных n-кортежей вида , где d1 – элемент из D1, d2 – элемент из D2, dN – элемент из DN. D1, D2, DN называются доменами отношения R. Существует много подходов к определению реляционной алгебры, которые различаются наборами операций и способами их интерпретации, но, в принципе, являются более или менее равносильными. Базовый вариант алгебры был предложен Коддом. В этом варианте набор основных алгебраических операций состоит из восьми операций, которые делятся на два класса – теоретико-множественные операции и специальные реляционные операции. В состав теоретико-множественных операций входят операции: объединения отношений; пересечения отношений; взятия разности отношений; взятия декартова произведения отношений. Специальные реляционные операции включают: ограничение отношения; проекцию отношения; соединение отношений; деление отношений. Кроме того, в состав алгебры включается операция присваивания, позволяющая сохранить в базе данных результаты вычисления алгебраических выражений, и операция переименования атрибутов, дающая возможность корректно сформировать заголовок (схему) результирующего отношения. Общая интерпретация реляционных операций При выполнении операции объединения (UNION) двух отношений с одинаковыми заголовками производится отношение, включающее все кортежи, которые входят хотя бы в одно из отношений-операндов. Операция пересечения (INTERSECT) двух отношений с одинаковыми заголовками производит отношение, включающее все кортежи, которые входят в оба отношения-операнда. Отношение, являющееся разностью (MINUS) двух отношений с одинаковыми заголовками, включает все кортежи, входящие в отношение-первый операнд, такие, что ни один из них не входит в отношение, которое является вторым операндом. При выполнении декартова произведения (TIMES) двух отношений, пересечение заголовков которых пусто, производится отношение, кортежи которого производятся путем объединения кортежей первого и второго операндов. Результатом ограничения (WHERE) отношения по некоторому условию является отношение, включающее кортежи отношения-операнда, удовлетворяющее этому условию. При выполнении проекции (PROJECT) отношения на заданное подмножество множества его атрибутов производится отношение, кортежи которого являются соответствующими подмножествами кортежей отношения-операнда. При соединении (JOIN) двух отношений по некоторому условию образуется результирующее отношение, кортежи которого производятся путем объединения кортежей первого и второго отношений и удовлетворяют этому условию. У операции реляционного деления (DIVIDE BY) два операнда – бинарное и унарное отношения. Результирующее отношение состоит из унарных кортежей, включающих значения первого атрибута кортежей первого операнда таких, что множество значений второго атрибута (при фиксированном значении первого атрибута) включает множество значений второго операнда. Операция переименования (RENAME) производит отношение, тело которого совпадает с телом операнда, но имена атрибутов изменены. Операция присваивания (:=) позволяет сохранить результат вычисления реляционного выражения в существующем отношении БД. Поскольку результатом любой реляционной операции (кроме операции присваивания, которая не вырабатывает значения) является некое отношение, можно образовывать реляционные выражения, в которых вместо отношения-операнда некоторой реляционной операции находится вложенное реляционное выражение. В построении реляционного выражения могут участвовать все реляционные операции, кроме операции присваивания. Вычислительная интерпретация реляционного выражения диктуется установленными приоритетами операций: RENAME RESTRICT = PROJECT TIMES = JOIN = INTERSECT = DIVIDE BY UNION = MINUS В другой форме приоритеты операций показаны на рисунке 24. Вычисление выражения производится слева направо с учетом приоритетов операций и скобок. Рисунок 24 – Таблица приоритетов операций традиционной реляционной алгебры Замкнутость реляционной алгебры и операция переименования Каждое значение-отношение характеризуется заголовком (или схемой) и телом (или множеством кортежей). В рамках алгебры, операции которые замкнуты относительно понятия отношения, каждая операция должна производить отношение в полном смысле, т. е. оно должно обладать и телом, и заголовком. Только в этом случае можно будет строить вложенные выражения. Заголовок отношения представляет собой множество пар имя-атрибута, имя-домена. Если посмотреть на общий обзор реляционных операций, то видно, что домены атрибутов результирующего отношения однозначно определяются доменами отношений-операндов. Однако с именами атрибутов результата не всегда все так просто. Например, у отношений-операндов операции декартова произведения имеются одноименные атрибуты с одинаковыми доменами. Поскольку это множество, в нем не должны содержаться одинаковые элементы. Но и потерять атрибут в результате недопустимо. А это значит, что в таком случае вообще невозможно корректно выполнить операцию декартова произведения. Аналогичные проблемы могут возникать и в случаях других двуместных операций. Для разрешения проблем в число операций реляционной алгебры вводится операция переименования. Ее следует применять в том случае, когда возникает конфликт именования атрибутов в отношениях-операндах одной реляционной операции. Тогда к одному из операндов сначала применяется операция переименования, а затем основная операция выполняется уже без всяких проблем. Более строго определяется операция переименования, результатом которой является отношение, совпадающее во всем с отношением-операндом, кроме того, что имя указанного атрибута изменено на заданное имя. Особенности теоретико-множественных операций реляционной алгебры Хотя в основе теоретико-множественной части реляционной алгебры Кодда лежит классическая теория множеств, соответствующие операции реляционной алгебры обладают некоторыми особенностями. Операции объединения, пересечения, взятия разности. Совместимость по объединению Операции объединения отношений. Все, что относится к операции объединения, верно и для операций пересечения и взятия разности отношений. Смысл операции объединения в реляционной алгебре в целом остается теоретико-множественным. В теории множеств: результатом объединения двух множеств A{a} и B{b} является такое множество C{c}, что для каждого с либо существует такой элемент a, принадлежащий множеству A, что c=a, либо существует такой элемент b, принадлежащий множеству B, что c=b; пересечением множеств A и B является такое множество C{c}, что для любого c существуют такие элементы a, принадлежащий множеству A, и b, принадлежащий множеству B, что c=a=b; разностью множеств A и B является такое множество C{c}, что для любого c существует такой элемент a, принадлежащий множеству A, что c=a, и не существует такой элемент b, принадлежащий B, что c=b. Рисунок 25 – Иллюстрация результатов теоретико-множественных операций Но если в теории множеств операция объединения осмысленна для любых двух множеств-операндов, то в случае реляционной алгебры результатом операции объединения должно являться отношение. Если в реляционной алгебре допустить возможность теоретико-множественного объединения двух произвольных отношений (с разными заголовками), то, конечно, результатом операции будет множество, но множество разнотипных кортежей, т. е. не отношение. Если исходить из требования замкнутости реляционной алгебры относительно понятия отношения, то такая операция объединения является бессмысленной. Эти соображения подводят к понятию совместимости отношений по объединению: два отношения совместимы по объединению в том и только в том случае, когда обладают одинаковыми заголовками. В развернутой форме это означает, что в заголовках обоих отношений содержится один и тот же набор имен атрибутов, и одноименные атрибуты определены на одном и том же домене (эта развернутая формулировка, вообще говоря, является излишней, но она пригодится нам в следующем абзаце). Если два отношения совместимы по объединению, то при обычном выполнении над ними операций объединения, пересечения и взятия разности результатом операции является отношение с корректно определенным заголовком, совпадающим с заголовком каждого из отношений-операндов. Напомним, что если два отношения «почти» совместимы по объединению, т. е. совместимы во всем, кроме имен атрибутов, то до выполнения операции типа объединения эти отношения можно сделать полностью совместимыми по объединению путем применения операции переименования. Для иллюстрации операций объединения, пересечения и взятия разности предположим, что в базе данных имеются два отношения СЛУЖАЩИЕ_В_ПРОЕКТЕ_1 и СЛУЖАЩИЕ_В_ПРОЕКТЕ_2 с одинаковыми схемами {СЛУ_НОМЕР, СЛУ_ИМЯ, СЛУ_ЗАРП, СЛУ_ОТД_НОМЕР} (имена доменов опущены по причине очевидности). Каждое из отношений содержит данные о служащих, участвующих в соответствующем проекте. На рис. 26 показано примерное наполнение каждого из двух отношений (некоторые служащие участвуют в обоих проектах). Рисунок 26 – Примерное наполнение отношений СЛУЖАЩИЕ _В_ПРОЕКТЕ_1 и СЛУЖАЩИЕ _В_ПРОЕКТЕ_2 Тогда выполнение операции СЛУЖАЩИЕ_В_ПРОЕКТЕ_1 UNION СЛУЖАЩИЕ_В_ПРОЕКТЕ_2 позволит получить информацию обо всех служащих, участвующих в обоих проектах. Выполнение операции СЛУЖАЩИЕ_В_ПРОЕКТЕ_1 INTERSECT СЛУЖАЩИЕ_В_ПРОЕКТЕ_2 позволит получить данные о служащих, которые одновременно участвуют в двух проектах. Наконец, операция СЛУЖАЩИЕ_В_ПРОЕКТЕ_1 MINUS СЛУЖАЩИЕ_В_ПРОЕКТЕ_2 выработает отношение, содержащее кортежи служащих, которые участвуют только в первом проекте. Результаты этих операций показаны на рис. 27. Рисунок 27 – Результаты выполнения операций UNION, INTERSECT и MINUS Заметим, что включение в состав операций реляционной алгебры трех операций объединения, пересечения и взятия разности является, очевидно, избыточным, поскольку, например, операция пересечения выражается через операцию взятия разности. Тем не менее Кодд в свое время решил включить все три операции, исходя из интуитивных потребностей далекого от математики потенциального пользователя системы реляционных БД. Операция расширенного декартова произведения и совместимость отношений относительно этой операции Другие проблемы связаны с операцией взятия декартова произведения двух отношений. В теории множеств декартово произведение может быть получено для любых двух множеств, и элементами результирующего множества являются пары, составленные из элементов первого и второго множеств. Если говорить более точно, декартовым произведением множеств A{a} и B{b} является такое множество пар C{}, что для каждого элемента множества C существуют такой элемент a множества A, что c1=a, и такой элемент b множества B, что c2=b. Поскольку отношения являются множествами, для любых двух отношений возможно получение прямого произведения. Но результат не будет отношением! Элементами результата будут не кортежи, а пары кортежей. Поэтому в реляционной алгебре используется специализированная форма операции взятия декартова произведения – расширенное декартово произведение отношений. При взятии расширенного декартова произведения двух отношений элементом результирующего отношения является кортеж, который представляет собой объединение одного кортежа первого отношения и одного кортежа второго отношения. Более точное определение операции расширенного декартова произведения: Пусть имеются два отношения R1{a1, a2, …, an} и R2{b1, b2, …, bm}. Тогда результатом операции R1 TIMES R2 является отношение R{a1, a2, …, an, b1, b2, …, bm}, тело которого является множеством кортежей вида {ra1, ra2, …, ran, rb1, rb2, …, rbm} таких, что {ra1, ra2, …, ran} входит в тело R1, а {rb1, rb2, …, rbm} входит в тело R2. Но теперь возникает вторая проблема – как получить корректно сформированный заголовок отношения-результата? Поскольку схема результирующего отношения является объединением схем отношений-операндов, то очевидной проблемой может быть именование атрибутов результирующего отношения, если отношения-операнды обладают одноименными атрибутами. Эти соображения приводят к введению понятия совместимости по взятию расширенного декартова произведения. Два отношения совместимы по взятию расширенного декартова произведения в том и только в том случае, если пересечение множеств имен атрибутов, взятых из их схем отношений, пусто. Любые два отношения всегда могут стать совместимыми по взятию декартова произведения, если применить операцию переименования к одному из этих отношений. Для наглядности предположим, что в придачу к введенным ранее отношениям СЛУЖАЩИЕ_В_ПРОЕКТЕ_1 и СЛУЖАЩИЕ_В_ПРОЕКТЕ_2 в базе данных содержится еще и отношение ПРОЕКТЫ со схемой {ПРОЕКТ_НАЗВ, ПРОЕКТ_РУК} (имена доменов снова опущены) и телом, показанным на рис. 28. На этом же рисунке показан результат операции СЛУЖАЩИЕ_В_ПРОЕКТЕ_1 TIMES ПРОЕКТЫ. Следует заметить, что операция взятия декартова произведения не является слишком осмысленной на практике. Во-первых, мощность тела ее результата очень велика даже при допустимых мощностях операндов, а, во-вторых, результат операции не более информативен, чем взятые в совокупности операнды. Как будет показано далее, основной смысл включения операции расширенного декартова произведения в состав реляционной алгебры Кодда состоит в том, что на ее основе определяется действительно полезная операция соединения. Рисунок 28 – Отношение ПРОЕКТЫ и результат операции СЛУЖАЩИЕ_В_ПРОЕКТЕ_1 TIMES ПРОЕКТЫ По поводу теоретико-множественных операций реляционной алгебры следует еще заметить, что все четыре операции являются ассоциативными. Т. е. если обозначить через OP любую из четырех операций, то (A OP B) OP C = A OP (B OP C), и, следовательно, без внесения двусмысленности можно писать A OP B OP C (A, B и C – отношения, обладающие свойствами, необходимыми для корректного выполнения соответствующей операции). Все операции, кроме взятия разности, являются коммутативными, т. е. A OP B = B OP A. Специальные реляционные операции Специальные реляционные операции реляционной алгебры: ограничение, проекция, соединение и деление. Операция ограничения Операция ограничения WHERE требует наличия двух операндов: ограничиваемого отношения и простого условия ограничения. Простое условие ограничения может иметь: вид (a comp-op b), где а и b – имена атрибутов ограничиваемого отношения; атрибуты a и b должны быть определены на одном и том же домене, для значений базового типа данных которого поддерживается операция сравнения comp-op, или на базовых типах данных, над значениями которых можно выполнять эту операцию сравнения; или вид (a comp-op const), где a – имя атрибута ограничиваемого отношения, а const – литерально заданная константа; атрибут a должен быть определен на домене или базовом типе, для значений которого поддерживается операция сравнения comp-op. Операцией сравнения comp-op могут быть «=», «», «>», «», «<», «». Простые условия вычисляются в трехзначной логике, и в результате выполнения операции ограничения производится отношение, заголовок которого совпадает с заголовком отношения-операнда, а в тело входят те кортежи отношения-операнда, для которых значением условия ограничения является true. Тем самым, если в некоторых кортежах содержатся неопределенные значения, и по данной причине вычисление простого условия дает значение unknown, то эти кортежи не войдут в результирующее отношение. Для обозначения вызова операции ограничения будем использовать конструкцию A WHERE comp, где A – ограничиваемое отношение, а comp – простое условие сравнения. Пусть comp1 и comp2 – два простых условия ограничения. Тогда по определению: A WHERE (comp1 AND comp2) обозначает то же самое, что и (A WHERE comp1) INTERSECT (A WHERE comp2); A WHERE (comp1 OR comp2) обозначает то же самое, что и (A WHERE comp1) UNION (A WHERE comp2); A WHERE NOT comp1 обозначает то же самое, что и A MINUS (A WHERE comp1). Эти соглашения позволяют задействовать операции ограничения, в которых условием ограничения является произвольное булевское выражение, составленное из простых условий с использованием логических связок AND, OR, NOT и скобок. Результат выполнения операции СЛУЖАЩИЕ_В_ПРОЕКТЕ_1 WHERE (СЛУ_ЗАРП > 20000.00 AND (СЛУ_ОТД_НОМ = 310 OR СЛУ_ОТД_НОМ = 315)) (получить данные из отношения СЛУЖАЩИЕ_В_ПРОЕКТЕ_1 о служащих, работающих в отделах 310 и 315 и получающих зарплату, превышающую 20 000.00 руб.) показан на рис. 29. Рисунок 29 – Результат операции СЛУЖАЩИЕ_В_ПРОЕКТЕ_1 WHERE (СЛУ_ЗАРП > 20000.00 AND (СЛУ_ОТД_НОМ = 310 OR СЛУ_ОТД_НОМ = 315)) На интуитивном уровне операцию ограничения лучше всего представлять как взятие некоторой «горизонтальной» вырезки из отношения-операнда (выборки некоторых строк из таблицы). Операция взятия проекции Операция взятия проекции также требует наличия двух операндов – проецируемого отношения A и подмножества множества имен атрибутов, входящих в заголовок отношения A. Результатом проекции отношения A на множество атрибутов {a1, a2, ..., an}(PROJECT A {a1, a2, ..., an}) является отношение с заголовком, определяемым множеством атрибутов {a1, a2, ..., an}, и с телом, состоящим из кортежей вида таких, что в отношении A имеется кортеж, атрибут a1 которого имеет значение v1, атрибут a2 имеет значение v2, ..., атрибут an имеет значение vn. Тем самым, при выполнении операции проекции выделяется «вертикальная» вырезка отношения-операнда с естественным уничтожением потенциально возникающих кортежей-дубликатов. Заметим, что потенциальная потребность удаления дубликатов очень сильно усложняет реализацию операции проекции, поскольку в общем случае для удаления дубликатов требуется сортировка промежуточного результата операции. Основная сложность состоит в том, что этот промежуточный результат в общем случае может быть очень большим, и для сортировки требуется применять дорогостоящие алгоритмы внешней сортировки, выполняемые с применением обменов с внешней памятью. (Под «стоимостью» действия понимается время его выполнения.) Результат операции PROJECT СЛУЖАЩИЕ_В_ПРОЕКТЕ_1 {СЛУ_ОТД_НОМ} (в каких отделах работают служащие, данные о которых содержатся в отношении СЛУЖАЩИЕ_В_ПРОЕКТЕ_1?) показан на рис. 30. Рисунок 30 – Результат выполнения операции PROJECT СЛУЖАЩИЕ_В_ПРОЕКТЕ_1 {СЛУ_ОТД_НОМ} Операция соединения отношений Общая операция соединения (называемая также соединением по условию) требует наличия двух операндов – соединяемых отношений и третьего операнда – простого условия. Пусть соединяются отношения A и B. Как и в случае операции ограничения, условие соединения comp имеет вид либо (a comp-op b), либо (a comp-op const), где a и b – имена атрибутов отношений A и B, const – литерально заданная константа, и comp-op – допустимая в данном контексте операция сравнения. Тогда по определению результатом операции соединения A JOIN B WHERE comp совместимых по взятию расширенного декартова произведения отношений A и B является отношение, получаемое путем выполнения операции ограничения по условию comp расширенного декартова произведения отношений A и B (A JOIN B WHERE comp (A TIMES B) WHERE comp). Если тщательно осмыслить это определение, то станет ясно, что в общем случае применение условия соединения существенно уменьшит мощность результата промежуточного декартова произведения отношений-операндов только в том случае, если условие соединения имеет вид (a comp-op b), где a и b – имена атрибутов разных отношений-операндов. Поэтому на практике обычно считают реальными операциями соединения именно те операции, которые основываются на условии соединения приведенного вида. Конечно же, и в операции соединения может задаваться произвольное логическое выражение, составленное из простых условий над атрибутами отношений-операндов и константами. Операцию соединения с таким условием comp разумно считать операцией действительно соединения, если оно имеет вид (или может быть преобразовано к виду) comp1 AND (a comp-op b), где a и b – имена атрибутов разных отношений-операндов. Для иллюстрации операций соединения мы немного изменим заголовки и тела отношений, которые использовались ранее в примерах этой лекции. Пусть теперь имеются отношения СЛУЖАЩИЕ {СЛУ_НОМЕР, СЛУ_ИМЯ, СЛУ_ЗАРП, ПРО_НОМ} (атрибут ПРО_НОМ содержит номера проектов, в которых участвует каждый служащий) и ПРОЕКТЫ {ПРО_НОМ, ПРОЕКТ_РУК, ПРО_ЗАРП} (ПРО_НОМ – номер проекта, ПРОЕКТ_РУК – имя служащего-руководителя проекта, ПРО_ЗАРП – средняя заработная плата служащих, участвующих в проекте). Примерное содержимое тел отношений СЛУЖАЩИЕ и ПРОЕКТЫ показано на рис. Тогда осмысленной операцией соединения общего вида будет СЛУЖАЩИЕ JOIN ПРОЕКТЫ WHERE (СЛУ_ЗАРП > ПРО_ЗАРП) (выдать данные о служащих, получающих заработную плату, превышающую среднюю заработную плату любого проекта). Результаты этого запроса показаны на рис. 31. Хотя операция соединения в приведенной интерпретации не является примитивной (поскольку определяется с использованием операций декартова произведения и проекции), в силу особой практической важности она включается в базовый набор операций реляционной алгебры Кодда. Заметим также, что в практических реализациях соединение обычно не выполняется именно как ограничение декартова произведения. Имеются более эффективные алгоритмы, гарантирующие получение такого же результата. Существует важный частный случай соединения – эквисоединение (EQUIJOIN) и простое, но важное расширение операции эквисоединения – естественное соединение (NATURAL JOIN). Операция соединения называется операцией эквисоединения, если условие соединения имеет вид (a = b), где a и b – атрибуты разных операндов соединения. Этот случай важен потому, что он чаще всего встречается на практике, и для него существуют наиболее эффективные алгоритмы реализации. Рисунок 31 – Отношения СЛУЖАЩИЕ и ПРОЕКТЫ Операция естественного соединения применяется к паре отношений A и B, обладающих (возможно, составным) общим атрибутом c (т. е. атрибутом с одним и тем же именем и определенным на одном и том же домене). Пусть ab обозначает объединение заголовков отношений A и B. Тогда естественное соединение A и B – это спроецированный на ab результат эквисоединения A и B по условию A.c = B.c. Хотя операция естественного соединения выражается через операции переименования, соединения общего вида и проекции, для нее обычно используется сокращенная форма, называемая NATURAL JOIN. На рис. 32, 33 приведены результаты операций СЛУЖАЩИЕ JOIN (ПРОЕКТЫ RENAME (ПРО_НОМ, ПРО_НОМ1)) WHERE (СЛУ_ЗАРП = ПРО_ЗАРП) (эквисоединение отношений СЛУЖАЩИЕ и ПРОЕКТЫ: найти всех служащих, получающих зарплату, равную средней заработной плате в каком-либо проекте) и СЛУЖАЩИЕ NATURAL JOIN ПРОЕКТЫ (естественное соединение – выдать полную информацию о служащих и проектах, в которых они участвуют). Рисунок 32 – Результат операции СЛУЖАЩИЕ JOIN ПРОЕКТЫ WHERE (СЛУ_ЗАРП > ПРО_ЗАРП) Рисунок 33 – Результаты операций эквисоединения и естественного соединения отношений СЛУЖАЩИЕ и ПРОЕКТЫ Если вспомнить введенное нами в конце предыдущей лекции определение внешнего ключа отношения, то должно стать понятно, что основной смысл операции естественного соединения состоит в возможности восстановления сложной сущности, декомпозированной по причине требования первой нормальной формы. Операция естественного соединения не включается в состав набора операций данной реляционной алгебры Кодда, но имеет очень важное практическое значение. Операция деления отношений Эта операция наименее очевидна из всех операций реляционной алгебры Кодда и поэтому нуждается в более подробном объяснении. Пусть заданы два отношения – A с заголовком {a1, a2, ..., an, b1, b2, ..., bm} и B с заголовком {b1, b2, ..., bm}. Будем считать, что атрибут bi отношения A и атрибут bi отношения B (i = 1, 2, …, m) не только обладают одним и тем же именем, но и определены на одном и том же домене. Назовем множество атрибутов {aj} составным атрибутом a, а множество атрибутов {bj} – составным атрибутом b. После этого будем говорить о реляционном делении «бинарного» отношения A{a, b} на унарное отношение B{b}. По определению, результатом деления A на B (A DIVIDE BY B) является «унарное» отношение C{a}, тело которого состоит из кортежей v таких, что в теле отношения A содержатся кортежи v UNION w такие, что множество {w} включает тело отношения B. Операция реляционного деления не является примитивной и выражается через операции декартова произведения, взятия разности и проекции. Мы покажем это в следующей лекции. Для иллюстрации этой операции предположим, что в базе данных служащих поддерживаются следующие отношения: СЛУЖАЩИЕ, как оно было определено ранее, и унарное отношение НОМЕРА_ПРОЕКТОВ {ПРО_НОМ} (рис). Тогда запрос СЛУЖАЩИЕ DIVIDE BY НОМЕРА_ПРОЕКТОВ выдаст данные обо всех служащих, участвующих во всех проектах (результат операции приведен также на рис. 34). Рисунок 34 – Пример реляционного деления Литература Основная и дополнительная учебная литература, необходимая для освоения дисциплины а) основная литература: Громов, Ю. Ю. Управление данными : учебник / Ю. Ю. Громов, О. Г. Иванова, А. В. Яковлев, В. Г. Однолько. – Тамбов : Изд-во ФГБОУ ВПО «ТГТУ», 2015. – 192 с. Базы данных: Учебник для вузов: [В 2 кн] Локальные базы данных . Кн. 1, В. П. Агальцов, М.: ФОРУМ, 2013, с. 377 Основы баз данных : Учеб. пособие / С. Д. Кузнецов. — М.: ИНТУИТ, 2012. — 484 с. б) дополнительная литература: Базы и банки данных, Ревунков Г.И., МГТУ им. Н.Э. Баумана (Московский государственный технический университет имени Н.Э. Баумана), 2011, с. 68 http://e.lanbook.com/books/element.php?pl1_id=52425. Базы данных, Медведкова И.Е., Бугаев Ю.В., Чикунов С.В., ВГУИТ (Воронежский государственный университет инженерных технологий), 2014, с. 108 http://e.lanbook.com/books/element.php?pl1_id=72882. В) учебно-методические пособия Базы данных : Курс лекций и материалы для практ. занятий: Учеб. пособие для вузов, И. П. Карпова, СПб.: Питер, 2013, с. 240 http://library.mirea.ru/books/48304 Ресурсы информационно-телекоммуникационной сети Интернет, необходимые для освоения дисциплины http://www.intuit.ru/studies/.
«Базы данных в структуре информационных систем. Инфологический подход к проектированию баз данных. Архитектура БД» 👇
Готовые курсовые работы и рефераты
Купить от 250 ₽
Решение задач от ИИ за 2 минуты
Решить задачу
Найди решение своей задачи среди 1 000 000 ответов
Найти

Тебе могут подойти лекции

Смотреть все 70 лекций
Все самое важное и интересное в Telegram

Все сервисы Справочника в твоем телефоне! Просто напиши Боту, что ты ищешь и он быстро найдет нужную статью, лекцию или пособие для тебя!

Перейти в Telegram Bot