Раздел 1 - Информационные системы с базами данных. Anna
3 Раздел 1 - Информационные системы с базами данных 3 Зміст Раздел 1 - Информационные системы с базами данных Тема 1 - Информационные системы с базами данных Тема 2 - Понятие модели данных предметной области Тема 3 - Проектирование базы данных Тема 4 - Проектирование модулей приложений Список литературы Раздел 2 - Реляционная модель данных Тема 5 - Реляционная модель данных Тема 6 - Нормализация реляционной модели данных Тема 7 - Введение в структурированный язык запросов SQL Тема 8 - Целостность и безопасность данных Раздел 3 - Общие сведения о других видах баз данных и баз знаний Тема 9 - Распределенные базы данных Тема 10 - Объектно-ориентированные базы данных Тема 11 - Общая характеристика баз знаний Тема 12 - Модели знаний
4 Раздел 1 - Информационные системы с базами данных 4 Раздел 1 - Информационные системы с базами данных Тема 1 - Информационные системы с базами данных 1.1 Информация и данные Прежде чем перейт и к обсуждению понят ия информационной сист емы (ИС), попробуем выяснить, что же понимается под словом "информация". Ответить на этот вопрос и просто, и сложно: слово "информация" связано с широким кругом понят ий. Содержат ельная ст орона понят ия "информация" очень многогранна и не имеет чет ких семантических границ. Однако всегда можно сказать, что с ней делать. Именно ответ на этот вопрос чаще всего и инт ересует как сист емных аналит иков и разработ чиков ИС, т ак и пользоват елей информации (ее основных пот ребит елей). С точки зрения как пользователей, так и разработчиков ИС в информации есть одно важное свойст во она являет ся единицей данных, подлежащей обработ ке. Обычно информация пост упает пот ребит елю именно в виде данных: т аблиц, графиков, рисунков, фильмов, уст ных сообщений, кот орые фиксируют в себе информацию определенной ст рукт уры и т ипа. Таким образом, данные выст упают как средст во предст авления информации в определенной, фиксированной форме, пригодной для обработ ки, хранения и передачи. Хот я очень част о т ермины "информация" и "данные" выст упают как синонимы, следует помнит ь об эт ом их сущест венном от личии. Именно в данных информация находит инт ерпрет ацию в конкрет ной ИС. При упоминании о " форме " предст авление информации следует сказат ь еще об одной, "человеческой" черт е информации ее восприят ие различными кат егориями людей. Данные могут быт ь сгруппированы вмест е в документ. Документ может имет ь или не имет ь определенную внут реннюю ст рукт уру. Данные могут быт ь от ображены на экране монит ора. Документ ы могут имет ь аудио- или видеоформу. Разрабат ывая ИС, никогда не следует забыват ь, для кого они (сист емы) создают ся и кт о будет их использоват ь. Форма предст авления информации в ИС определяет т акже и кат егории пользоват елей.ис создают ся для конкрет ных групп пользоват елей, т о ест ь они, как правило, проблемно -ориент ированные. Информация являет ся данными, кот орым присваивает ся некот орое содержание (инт ерпрет ация) в конкрет ной сит уации в рамках некот орой сист емы понят ий. Информация подает ся с помощью кодирования данных и приобрет ает ся пут ем их декодирования и инт ерпрет ации. В эт ом определении фиксирует ся т ри основных преобразования информации и данных в процессе их обработ ки в ИС: информация - данные, данные - данные, данные - информация.
5 Раздел 1 - Информационные системы с базами данных 5 На рис. 1.1 приведены две ст ороны определения понят ия информации: функциональная и предст авит ельная. Первая в целом определяет круг дейст вий над информацией, а вт орая - результ ат выполнения эт их дейст вий. Рисунок Содержание понят ия "информация" 1.2 Информационные системы Основной целью создания ИС являет ся удовлет ворение информационных пот ребност ей пользоват елей пут ем предост авления необходимой им информации на основе хранимых данных. Пот ребност ь в информации как т аковой не исчерпывает понят ия информационных пот ребност ей. Обычно в понят ие информационных пот ребност ей включают определенные т ребования к качест ву информационного обслуживания и поведение сист емы в целом(производит ельност ь, акт уальност ь и надежност ь данных, ориент ация на пользоват еля и др.). Под информационной сист емой понимает ся организационная совокупност ь т ехнических средст в, т ехнологических процессов и кадров, реализующих функции сбора, обработ ки, хранения, поиска, выдачи и передачи информации. Необходимост ь повышения производит ельност и т руда в сфере информационной деятельности приводит к тому, что в качестве внешних средств хранения и быстрого доступа к информации чаще всего используют ся средст ва вычислит ельной т ехники (цифровой и аналоговой) на основе компьют еров. Современные ИС сложные комплексы аппарат ных и программных средст в, т ехнологии и персонала, кот орые еще называют авт омат изированными информационными сист емами. Ст рукт урно ИС включают в себя аппарат ное (hardware), программное (software), коммуникационное (netware), промежут очного слоя (middleware), лингвист ическое и организационно-т ехнологическое обеспечение. Аппарат ное обеспечение ИС включает в себя широкий набор средст в вычислит ельной т ехники, передачи данных, а т акже целый ряд специальных т ехнических уст ройст в (уст ройст ва графического от ображения информации, аудио-и видеоуст ройст ва, средст ва речевого ввода и т.д.). Аппарат ное обеспечение являет ся основой любой ИС. Коммуникационное (сет евое) обеспечение включает в себя комплекс аппарат ных сет евых коммуникаций и программных средст в поддержки коммуникаций в ИС. Оно имеет сущест венное значение при создании распределенных ИС и ИС на основе Инт ернет а Программное обеспечение ИС обеспечивает реализацию функций ввода данных, их размещения на носит елях, модификации данных, дост уп к данным, поддержку функционирования оборудования. Программное обеспечение можно разделит ь на сист емное (кот орое завершает процесс выбора аппарат но- программного решения или плат формы) и пользоват ельское (применяемого для решения задач удовлет ворения пот ребност ей пользоват еля в компьют ерной среде). Лингвист ическое обеспечение ИС предназначено для решения задач формализации содержания полнот екст овой и специальной информации для создания поискового образа данных ( профиля). В классическом смысле обычно оно включает процедуры индексирования т екст ов, их классификацию и т емат ическую рубрикацию. Чаще ИС, содержащие сложност рукт урированную информацию, включают в себя т езаурусы т ерминов и понят ий. Сюда можно от нест и и создание процессоров специализированных формальных языков конечных пользоват елей, например, как для манипулирования бухгалт ерской информации и т.д. Чаще т рудам по разработ ке лингвист ического обеспечения не предост авляет ся должного значения. Подобные упущения зачаст ую приводят к неприят ию пользоват елями самой информации. Эт о касает ся в первую очередь узкоспециализированных ИС. По мере рост а сложност и и масшт абов ИС важную роль начинает играт ь организационно-
6 Раздел 1 - Информационные системы с базами данных 6 т ехнологическое обеспечение, соединяющий разнородные компонент ы (аппарат уры, программы и персонал) в единую сист ему и обеспечивает процедуры ее управления и функционирования. Недооценка этой составляющей ИС чаще всего приводит к срыву сроков внедрения системы и вывода ее на производст венные мощност и. На рис. 1.2 приведены функции ИС через ее основные структурные компоненты. Рисунок Определение информационной сист емы 1.3 Основные подходы к обработке информации в автоматизированных информационных системах Одним из главных вопросов разработ ки программного обеспеченияис являет ся вопрос о соот ношении программ и данных, т ак как решение эт ого вопроса, в конечном ит оге, определяет выбор алгорит мов обработ ки информации, аппарат ных средст в и т ехнологической плат формы. Фундамент альным принципом в решении вопроса о соот ношении программ и данных являет ся концепция независимост и приложений от данных, и неважно, обработ ка данных предполагает ся: цент рализованная или распределенная. Сут ь эт ой концепции заключает ся не ст олько в от делении программ от данных, сколько в рассмот рении их как самост оят ельных взаимодейст вующих объект ов. Одной из последних модификаций эт ого принципа являет ся концепция независимост и приложений от данных вмест е с процедурами их обработ ки (объект но-ориент ированный подход в программировании), чт о позволяет решит ь ряд вопросов обработ ки данных, связанных с инт ерпрет ацией семант ического содержания данных. Формирование концепции БД и создание на ее основе мет ода баз данных для решения задач обработ ки информации произошло в 1962 году. К середине 60- х годов прошлого века основной концепцией пост роения программного обеспечения были концепция файловой сист емы и т ак называемый позадачный мет од. В конце 80- х годов прошлого века была предложена концепция объект но - ориент ированных баз данных и объект но - ориент ированный подход разработ ки программ на основе обработ ки событ ий. На рис. 1.3 приведены основные признаки для каждой из указанных выше концепций. На рис. 1.4 проведено сопост авление основных мет одов обработ ки данных. Основное содержание позадачного мет ода сводит ся к декомпозиции программы со своими от дельными блоками данных и алгорит мами; мет ода баз данных - до имеющихся от дельных описаний логической ст рукт уры данных и единой т очки зрения от носит ельно процедуры обработ ки данных; объект но- ориент ированного мет ода - в т ом, чт о программы рассмат ривают ся как совокупност ь объект ов, между кот орыми происходит обмен информацией. Объект у присущи следующие свойст ва: инкапсуляция объект ы наделяют ся ст рукт урой и имеют определенное поведение (набор операций). Операции над объектами составляют его методы. Структура объекта спрятана от пользоват еля, манипулирует объект ом через его операции. Объект рассмат ривает ся как абстракция реального мира. Для того чтобы объект выполнил некоторое действие, ему нужно от правит ь сообщение. Объект взаимодейст вует с другими через событ ия; наследование предст авляет собой механизм, позволяющий делат ь одни объект ы из других, при этом свойства родительского объекта сохраняются в потомке; полиморфизм различные объект ы могут получат ь одинаковые сообщения, но реагироват ь на них по-разному в соот вет ст вии с реализацией своих одноименных мет одов.
7 Раздел 1 - Информационные системы с базами данных 7 Рисунок Основные концепции обработ ки информации Рисунок 1.4 Основные проблемы мет одов обработ ки информации Следоват ельно, при разработ ке авт омат изированных ИС следует помнит ь: ИС создают ся для конкрет ных групп пользоват елей, т о ест ь они являют ся проблемноориент ированные; Основной целью создания ИС являет ся удовлет ворение информационных пот ребност ей пользоват елей пут ем предост авления необходимой им информации на основе хранимых данных; Современные ИС - сложные комплексы аппарат ных и программных средст в, т ехнологии и персонала, кот орые еще называют авт омат изированными информационными сист емами; Соблюдение концепции независимост и приложений от данных вмест е с процедурами их обработ ки (объект но-ориент ированный подход в программировании) позволяет решит ь ряд вопросов обработ ки данных, связанных с инт ерпрет ацией семант ического содержания данных; ИС работ ает с упорядоченными взаимозависимыми данным, кот орые хранят ся с минимальной избыт очност ью и сост авляют базу данных. Сист емой управления базами данных называет ся совокупност ь программных средст в, необходимых для использования БД и предст авления разработ чикам и пользоват елям множест ва различных предст авлений данных. 1.4 Базы данных и системы управления базами данных Основные определения Базу данных в общем случае можно определит ь как унифицированную совокупност ь сохранившихся и воспроизводимых данных, используемых в рамках организации (Engles RA, 1972 г.). Однако понятие БД не основывается в настоящее время на единой концепции, скорее это целое семейст во связанных между собой понят ий с ПО, программного и аппарат ного обеспечения, анализа и моделирования данных и приложений. База данных (по Дж. Март ину) предст авляет собой совокупност ь взаимосвязанных данных, совмест но используемых несколькими приложениями, и кот орые хранят ся с минимально регулируемой избыт очност ью. Данные запоминают ся т аким образом, чт обы они по возможност и не зависели от программ. Для обработ ки данных применяет ся общий управляющий мет од доступа. Если БД не пересекаются по структуре, то говорят о системе баз данных. База данных (согласно мат ериалам комит ет а КОДАСИЛ) сост оит из всех экземпляров записей, экземпляров наборов записей и област ей, кот орые конт ролируют ся конкрет ной схемой. Под схемой можно понимать карту всей логической структуры БД. Для разработ чика ИС сущест венным момент ом при использовании концепции баз данных являет ся т о обст оят ельст во, чт о данные ст ановят ся определенным образом организованы,
8 Раздел 1 - Информационные системы с базами данных 8 получают какую-то упорядоченность и внутреннюю структуру, а также то, что есть некоторый набор унифицированных операций обработ ки данных и декларат ивных средст в предст авления данных. К таким следует отнести операции " Вставить " ( Insert), " Добавить " ( Add), " Удалить " ( Delete) и ряд других. К декларат ивным средст вам предст авления данных следует от нест и язык определения данных. То ест ь использование данной концепции при создании ИС предполагает наличие языка определения данных и языка манипулирования данными, а т акже правил пост роения инт ерфейсов программ (приложений) с БД и пользоват елем. Такое распределение средст в манипулирования данными и их предст авления являет ся в определенной ст епени условным. Язык определения данных служит для описания логической структуры (схемы) БД, а в некоторых случаях и способов хранения и доступа к данным. Язык манипулирования данными предост авляет алгорит мические средст ва пост роения приложений для обработки элементов данных, которые хранятся в БД Архитектура БД Основной идеей спецификации ANSI SPARC ест ь выделения т рех архит ект урных уровней базы данных, а именно: внешнего, концепт уального и внут реннего (рис. 1.5). Концептуальный уровень На концепт уальному уровне осущест вляет ся инт егрированное описание предмет ной област и, для которой разрабатывается БД, независимо от ее восприятия отдельными пользователями и образов реализации в компьют ерной сист еме. Дадим определение основных понят ий, кот орые используют ся на концепт уальном уровне. Предмет ная област ь (ПО) - част ь реального мира, для кот орой осущест вляет ся концепт уальное моделирование. Концепт уальная модель ПО формальное изображение совокупност и мыслей, кот орые характ еризуют возможные сост ояния ПО, а т акже переходы из одного сост ояния в другое (включит ельно с классификацией имеющихся в ПО сущност ей, дейст вующих правил, законов, ограничений и т.п.) Концепт уальное моделирование ПО процесс пост роения концепт уальной модели ПО, которая бы отображала ПО с учетом требований, выдвинутых до этого процесса Концепт уальная схема фиксация концепт уальной модели ПО средст вами конкрет ных языков моделей данных. В СКБД концепт уальная модель подает ся в виде концепт уальной схемы. Опишем свойст ва концепт уальной модели ( схемы) и характ ерные особенност и концепт уального моделирования: Общее и однозначное т олкование предмет ной област и всеми заинт ересованными лицами. Концепт уальная схема от ображает лишь концепт уально важные аспект ы ПО, исключая любые аспект ы внешнего или внут реннего от ображения данных. Эт а модель не должна от ображат ь конкрет ные нужды от дельных пользоват елей или приложений. Она должна фиксироват ь, чем ест ь ПО в целом, а не с т очки зрения инт ересов или пот ребност ей пользоват елей. Определение допуст имых границ эволюции базы данных. В процессе эксплуат ации база данных может развиват ься, однако эт о развит ие может происходит ь т олько в пределах, допуст имых для концепт уальной схемы. От ображение внешних схем на внут реннюю. Именно через концепт уальную схему внешние данные отображаются на внутренние, и наоборот. Таким образом создается единая основа для описания данных и поддержки эт их от ображений. Обеспечение независимост и данных. Наличие от ображений концепт уальный-внешний и концепет уальный-внут ренний дает возможност ь решат ь проблему логической и физической независимости данных. Любые изменения в той или другой внешней модели не должны служить причиной изменений в концепт уальной или внут ренний моделях. В эт ом случае должны изменит ься т олько соот вет ст вующее от ображение «концепт уальный-внешний». Аналогично, любые изменения во внут ренней модели не задевают концепт уальную модель и модели внешнего уровня, а т олько приводят к изменениям от ображения «концепт уальныйвнут ренний». Цент рализованное админист рирование. Именно через концепт уальную схему осущест вляет ся админист рирование баз данных. Стойкость. Концептуальная схема не должны подлаживаться к требованиям тех или других пользоват елей (внешний уровень) или к т ребованиям хранения данных (внут ренний уровень). Будучи моделью ПО, она должна меняться только тогда, когда входит в противоречие с ней. Внешний уровень Через внешний уровень пользоват ели и приложения получают дост уп к базе данных. Цель внешнего уровня предост авит ь пользоват елю/приложению лишь т е данные, кот орые ему нужны (а следоват ельно, к кот орым разрешенный дост уп) и в нужном виде. Эт о индивидуальный уровень пользоват еля, кот орым может быт ь конечный пользоват ель, программист или приложение.
9 Раздел 1 - Информационные системы с базами данных 9 Внешняя модель это средства изображения концептуальной модели ПО с учетом интересов конкрет ных пользоват елей или приложений. Каждая внешняя модель подает ся в СКБД в виде внешней схемы. Внешний уровень выполняет т акие функции: Обеспечивает изображение данных удобным для человека или приложения образом. Ст епень независимост и внешнего изображения от концепт уального уровня определяет ся мощност ью средст в описания от ображения «концепт уальный- внешний». Содейст вует решению проблемы безопасност и (защит ы) данных. Предост авляя пользоват елю лишь т е данные, чт о его инт ересуют, мы ост авляем вне границ его дост упа сдачу данных. Содейст вует решению проблемы логической независимост и данных Эт о дост игает ся благодаря от ображению «концепт уальный-внешний», чт о уст анавливает соот вет ст вие между концепт уальной схемой и конкрет ной внешней схемой. Мощност ь его средст в определяет ст епень логической независимост и приложений от данных. Внутренний уровень Внут ренняя модель являет ся от ображением концепт уальной модели ПО с учет ом образов хранения данных и методов доступа к ним. Внутренняя модель отображается в СКБД в виде внут ренней схемы. Дост уп к физической памят и предост авляет ся с помощью описания от ображений внут ренней модели на физическую памят ь операционной сист емы. Вообще внут ренний уровень выполняет т акие функции. Обеспечивает налаживание базы данных для повышения производит ельност и обработ ки данных, описания и поддержки планированной избыт очност и. Дает возможность описывать и поддерживать структуры хранения и методы доступа. Содейст вует решению проблемы физической независимост и данных: изменения во внут ренней схеме не должны приводит ь к изменениям во внешней схеме. Содейст вует решению проблемы безопасност и (защит ы) данных. Решает проблему от ображения данных на ст рукт уры ОС, в кот орых данные хранят ся (к т аким ст рукт урам принадлежат в част ност и файлы). Отображение От ображение внешнего уровня на концепт уальный и концепт уального уровня на внут ренний показанные на рис От ображение «внешний- концепт уальный» определяет соот вет ст вие между внешним уровнем и концепт уальным. Независимост ь внешней схемы, зат ем и ст епень логической независимост и данных, обуславливают ся мощност ью средст в описания эт их от ображений. То ест ь можно описыват ь или менят ь внешнюю схему т олько в т ех границах, кот орые допускает эт о от ображение. Подобное можно сказат ь и об от ображении «концепт уальный- внут ренний», кот орое уст анавливает соот вет ст вие между концепт уальной и внут ренней моделями. Мощност ь его средст в определяет ст епень физической независимост и приложений от данных Любые изменения в физической ст рукт уре не должны приводит ь к изменениям в концепт уальной модели меняет ся лишь от ображения «концепт уальный-внут ренний». За создания и ведение схем всех уровней (концептуальной, внешней и внутренней), а также от ображений от вечает админист рат ор базы данных.
10 Раздел 1 - Информационные системы с базами данных 10 Рисунок 1.5 Архитетура БД СУБД В случае приложения концепции БД для создания ИС естественно возникает вопрос, а кто или что должно все это поддерживает? Таким образом, встает вопрос о Системе управления базой данных (СУБД). СУБД являют ся сложными программными сист емами, работ ающими на разных операционных плат формах. Именно СУБД должна предост авит ь средст ва определения и манипулирования данными, сделав данные независимыми от приложений, кот орые используют. К основным функциям СУБД следует от нест и: обеспечения языковых средст в описания и манипуляции данными; обеспечение поддержки логической модели данных; обеспечение взаимодейст вия логической и физической ст рукт ур данных; обеспечение защит ы и целост ност и данных; обеспечение поддержки БД в акт уальном сост оянии. Сист емой управления базами данных (Data-base Management System) называет ся совокупност ь программных средст в, необходимых для использования БД и предст авления разработ чикам и пользоват елям множест ва различных предст авлений данных. 1.5 Понят ие модели данных Предст авление информации с помощью данных т ребует унифицированного подхода к понят ию данных как независимого объект а моделирования. Поэт ому для разработ чика ИС выбор соот вет ст вующей модели данных являет ся одной из важнейших проблем. Выбор модели данных вызывает выбор средст в анализа ПО как област и реального мира, подлежащего изучению и обработ ке. Модель данных ограничивает возможност ь выбора СУБД, пот ому чт о, как правило, от дельно взят ая модель поддерживает определенную модель данных. Таким образом, понят ие модели данных являет ся одним из фундамент альных понят ий информат ики, от кот орого во многом зависят механизмы реализации ИС как программно -аппарат ного комплекса. Основой для любой ст рукт уры данных являет ся от ображение элемент арной единицы данных в виде следующей т ройки: <объект, свойст во объект а, значение свойст ва>. Совокупност ь взаимосвязанных между собой элемент арных единиц данных может от ображат ься различными способами, приводит к формированию различных ст рукт ур, а следоват ельно - различных моделей данных. Модели данных делят ся на два класса: сильно и слабо т ипизированные. В сильно типизированных моделях все данные должны принадлежат ь к определенной кат егории, или т ипа. Если данные не подпадают ни под одну из кат егорий, их нужно т ипизироват ь искусст венно. Некот орые модели ст роят ся т аким образом, чт о кат егории определяют ся заранее и не могут изменят ься динамически. В эт ом случае моделируемый мир вроде помещает ся в смирит ельную рубашку. Например, кат егория «служащий»
11 Тема 2 - Понятие модели данных предметной области 11 строгофиксированная, и все ее объекты должны иметь одинаковые свойства и структуру. Сильно т ипизированные модели имеют значит ельные преимущест ва, пот ому позволяют построить абстракции свойств данных и исследовать их в терминах категорий. Большинство моделей, используемых в автоматизированных системах, в том числе и базах данных, относятся к сильно т ипизированным. Для слабо т ипизированных моделей принадлежност ь данных к т ой или иной кат егории не имеет никакого значения. Кат егории используют ся наст олько, насколько эт о целесообразно в каждом конкретном случае. Отдельные данные могут существовать как независимо, так и в связи с другими. Информация о кат егориях (если они используют ся) рассмат ривает ся как дополнит ельная. В от личие от сильно т ипизированных моделей, слабо т ипизированные обеспечивают инт еграцию данных и кат егорий. Лучшие возможност и т акой инт еграции предост авляют ся исчислением предикат ов, кот орое во многих моделях данных использует ся для изображения знаний, кот орые не поддерживают ся базовыми средст вами моделирования. Модель данных (Data Model) являет ся логической ст рукт урой данных, сост авляет присущи эт им данным свойст ва, независимые от аппарат ного и программного обеспечения и не связаны с функционированием компьют ера. Можно рассмот рет ь несколько аспект ов моделирования обработ ки данных: Информационное моделирование: Концепт уальное моделирование (моделирование семант ики ПО); Логическое моделирование данных; Физическое моделирование: Создание моделей дост упа к данным; Опт имизация физической организации данных в аппарат ной среде. На рис. 1.6 иллюстрируется общий смысл понятие модели данных в настоящее время. Рисунок 1.6 Предст авление об информационной модели данных Наличие в СУБД определенной ст рукт уры данных приводит к понят ию баз ст рукт урированных данных, т.е. данные в т аких БД должны быт ь предст авлены как совокупност ь взаимосвязанных элемент ов. Следует имет ь в виду, чт о для каждого т ипа БД используют ся соот вет ст вующие модели данных. В наст оящее время для баз ст рукт урированных данных различают т ри основных т ипа логических моделей данных в зависимост и от характ ера поддерживаемых ими связей между элемент ами данных сет евую, иерархическую и реляционную. Признаками классификации в эт их моделях являют ся: ст епень т вердост и (фиксации) связи, мат емат ическое предст авление ст рукт уры модели и допуст имых т ипов данных (см. т аблицу 1.1). Рис. 1.7 иллюст рирует особенност и каждой модели данных. При сопост авлении моделей следует помнит ь, чт о все они т еорет ически эквивалент ны. Эквивалент ност ь моделей заключает ся в т ом, чт о они могут быт ь сведены друг к другу пут ем формальных преобразований. Таблица Общие характ ерист ики моделей данных Модель данных Характ ер связей между объект ами Формальное предст авление Сет евая Полут вердые связи произвольный граф Иерархическая Твердые связи древовидная структура Реляционная Гибкие связи плоский файл
12 Тема 2 - Понятие модели данных предметной области 12 Рисунок 1.7 Основные т ипы моделей данных Выводы Под информационной сист емой понимает ся организационная совокупност ь т ехнических средст в, т ехнологических процессов и кадров, реализующих функции сбора, обработ ки, хранения, поиска, выдачи и передачи информации. Ст рукт урно ИС включают в себя аппарат ное, программное, коммуникационное, лингвист ическое и организационно-т ехнологическое обеспечение. Сущест вуют т ри концепции обработ ки данных в ИС: файловой сист емы, баз данных, объект но-ориент ированных баз данных. Соот вет ст венно сущест вуют т ри мет ода обработ ки данных: позадачный мет од, мет од баз данных, объект но-ориент ированный мет од. База данных определяет ся как совокупност ь взаимосвязанных данных, совмест но используемых несколькими приложениями и т акими, чт о хранят ся с минимальной регулируемой избыт очност ью. База данных сост оит из всех экземпляров записей, экземпляров наборов записей и област ей, кот орые конт ролируют ся конкрет ной схеме. Под схемой можно понимат ь карт у всей логической ст рукт уры БД. Вопросы для самопроверки В чем заключают ся основные функции информационной сист емы? Как соотносятся понятия «информация» и «данные»? Какие преобразования данных вы знает е? В чем заключает ся функциональное содержание понят ия «информация»? В чем предст авит ельное содержание понят ия «информация»? Из каких элемент ов сост оит информационная сист ема? Какие основные функции ИС вы знает е? Какие свойства характерны объекту ИС? В чем заключает ся концепция независимост и приложений от данных? Основные аспект ы концепции файловой сист емы? Основные аспект ы концепции баз данных? Основные аспект ы концепции объект но - ориент ированных баз данных? Сформулируйт е понят ие «базы данных». Чт о понимает ся под сист емой управления базами данных? Назовит е основные функции сист емы управления базами данных. Объяснит е понят ие модели данных. Какие модели данных вы знает е? Укажите кратко характеристики моделей. Тема 2 - Понятие модели данных
13 Тема 2 - Понятие модели данных предметной области 13 предметной области 2 ПРЕДМЕТНАЯ ОБЛАСТЬ БАЗЫ ДАННЫХ И ЕЕ МОДЕЛИ 2.1 Понятие предметной области Основным назначением ИС являет ся операт ивное обеспечение пользоват еля информацией о внешнем миру пут ем реализации вопросно- соот вет ст вующего от ношения. Вопросносоот вет ст вующие от ношения позволяют выделит ь для ИС определенный ее фрагмент предмет ную област ь, кот орый будет воплощен в авт омат изированной ИС. Информация о внешнем миру подает ся в ИС в форме данных, кот орая ограничивает возможност и содержат ельной инт ерпрет ации информации и конкрет изирует семант ику ее предст авления в ИС. Совокупност ь эт их выделенных для ИС данных, связей между ними и операций над ними образует информационную и функциональную модели предмет ной област и (ПО), чт о описывают ее ст ан с определенной т очност ью. Информационная и функциональная модели ПО являют ся входными данными для процесса проект ирования БД. Совокупность реалий (объектов) внешнего мира объектов, о которых можно спрашивать, образовывает объект ное ядро ПО, кот орое имеет онт ологический ст ат ус. Нельзя получит ь в ИС ответ на вопрос о том, что ей неизвестно. Термин "объект" является первичным понятием. Синонимами т ермина "объект" ест ь "реалия, сущност ь, вещь". Сущност ь ПО являет ся результ ат ом абст рагирования реального объект а пут ем выделения и фиксации набора его свойст в. Примерами сущностей (с точки зрения ИС) или объектов (с точки зрения внешнего мира) есть от дельный ст удент, группа ст удент ов, аудит ория, время занят ий, слова, числа, символы. Обычно полагается, что быть объектом - означает быть дискретным и заметным. С объект ами связано две проблемы: идент ификация и адекват ное описание. Для идент ификации используют имя. Использует ся т олько указат ельная функция имени. Имя эт о прямой образ идент ификации объект а. К косвенным образам идент ификации объект а от носят определение объект а через него свойст ва (характ ерист ики или признаки). Объект ы взаимодейст вуют между собой через свои свойст ва, кот орые порождает сит уации. Сит уации эт о взаимосвязи, кот орые выражают взаимоот ношения между объект ами. Сит уации в предмет ной област и (ПО) описывают ся с помощью высказываний о ПО с использованием выражений и вычислениями предикат ов, т о ест ь формальной, мат емат ической логики. Методы математической логики позволяют формализовать эти утверждения и представить их в виде, пригодному для анализа. Пример. Рассмот рим высказывание: ст удент Иванов А.А, родился в 1982 году. Оно выражает такие свойства объекта "Иванов А.А.": в явном виде - год рождения; в неявном виде- принадлежност и к ст удент ам. Первое свойст во уст анавливает связь между объект ами "Иванов А.А." и "Год рождения", а вт орая - между объект ами "Иванов А.А." и "Множест во ст удент ов". Формализация эт ого высказывания предст авляет ся как результ ат присваивания значений сменным, кот орые входят в предикат ы: РОДИЛСЯ (Иванов А.А., 1982) ЯВЛЯЕТСЯ СТУДЕНТОМ (Иванов А.А.) На рис. 2.1 приведенный один из подходов к классификации сит уаций в рамках ПО.
14 Тема 2 - Понятие модели данных предметной области 14 Рисунок 2.1 Классификация сит уаций ПО Различают ст ат ические и динамические сит уации. Примерами ст ат ических сит уаций являют ся т акие сит уации, как цвет а, возраст. Примерами динамических сит уаций являют ся такие ситуации, как выпечь хлеб. Приведенная классификация вводит в ПО два важных аспект а - прост ранст во и время, к тому же время и как момент, и как интервал. ПО существует в пространстве и времени, то есть ей присущие времени и прост ранст венные от ношения и связи. Нужно различат ь реальное время внешнего мира и его от ображение в БД и в ист очниках информации. В БД взаимосвязи, зависимые от времени, фиксируют ся т олько после регист рации в БД. Таким образом, ПО в каждый определенный момент времени предст авляет собой от деленную совокупност ь определенных объект ов и сит уаций, кот орую называют по сост оянию ПО. Предмет ная област ь эт о целенаправленная первичная т рансформация карт ины внешнего мира в некот орую карт ину, определенная част ь кот орой фиксирует ся в ИС как алгорит мическая модель фрагмент у дейст вит ельност и. 2.2 Информационная модель предметной области базы данных Информационная модель данных предназначена для предст авления семант ики ПО в сроках субъект ивных средст в описания - сущност ей, ат рибут ов, идент ификат оров сущност ей, супертипов, подтипов и т.д. Информационная модель ПО БД содержит т акие основные конст рукции: диаграммы " сущност ь-связь" (Entity - Relationship Diagrams); определение сущност ей; уникальные идент ификат оры сущност ей; определение ат рибут ов сущност ей; от ношение между сущност ями; супертипы и подтипы. Элемент ы информационной модели данных ПО являют ся входными данными для решения задачи проект ирования БД создание логической модели данных. Предмет ом информационной модели являет ся абст рагирования объект ов или явлений реального мира в рамках ПО, в результ ат е кот орого оказывают ся сущност и (entity) ПО. Как правило, они сказывают ся сущест вит ельным ест ест венного языка. Сущност ь описывает ся с помощью данных, именованных свойст вами или ат рибут ами (attributes) сущност и. Как правило, ат рибут ы являют ся определениями в высказывании о сущностях и сказываются существительными естественного языка. Сущности вступают у связи друг с другом через свои ат рибут ы. Каждая группа ат рибут ов, кот орые описывают одно реальное проявление сущност и, предст авляет собой экземпляр (instance) сущност и. Другими словами, экземпляры сущност и эт о реализации сущност и, кот орые от личают ся одно от одного и допускают однозначную идент ификацию. Одним из основных компьют ерных средст в распознавания сущност ей в базе данных ест ь присвоения сущност ям идент ификат оров (Entity identifier). Част о идент ификат ор сущност и называют ключом. Задача выбора идент ификат ора сущност и являет ся субъект ивной задачей. Поскольку сущност ь определяет ся набором своих ат рибут ов, т о для каждой сущност и целесообразно выделит ь т акое подмножест во ат рибут ов, кот орая однозначно идент ифицирует данную сущност ь. Задача разработчика БД обеспечить при сохранении экземпляров сущности в БД наличие у каждого ее нового экземпляра уникального идент ификат ора. Уникальный идент ификат ор сущности это атрибут сущности, которая позволяет отличать одну сущность от другой. Если сущност ь имеет несколько уникальных идент ификат оров, т ак называемых возможных ключей,
15 Тема 2 - Понятие модели данных предметной области 15 то разработчик должен избрать первичный ключ сущности. Различают однозначные и многозначит ельные ат рибут ы. Однозначными ест ь ат рибут ы, кот орые в пределах конкрет ного экземпляра сущност и имеют т олько одно значение. В прот ивоположном случае они полагают многозначит ельными. Каждый ат рибут сущност и имеет домен (domain). Домен эт о выражение, кот орое определяет значение, разрешенные для данного ат рибут а. Другими словами, домен эт о област ь значений ат рибут а. Разработ чик БД должен проконт ролироват ь, чт обы в информационной модели ПО для каждого ат рибут а сущност ей был определен домен. Сущности не существуют отдельно одна от одной. Между ними есть реальные отношения (Relationship), и они должны быт ь от ражены в информационной модели ПО. При выделении от ношений акцент делает ся на фиксацию связей и их характ ерист ик. От ношение (связь) предст авляет собой соединение (взаимоот ношения) между двумя или больше сущност ями. Каждая связь реализует ся через значение ат рибут ов сущност ей. Обычно связь сказывает ся глаголом. Каждая связь т акже должен имет ь свой уникальный идент ификат ор связи. Разработ чик БД должен проконт ролироват ь, чт обы связь между сущност ями осущест влялся через т очно указанные ат рибут ы, кот орые будут определят ь уникальный ключ связи. Выбор ключей сущност ей - одно из самых важных проект ных решений, кот орый должны быт ь сделанным разработ чиком при переходе от информационной модели ПО к логической модели БД. Связи характ еризуют ся ст епенью связи и классом принадлежност ей сущност и к связи. Ст епень (мощност ь) связи - эт о от ношения числа сущност ей, кот орые принимают участ ие в образовании связи. Сущест вуют т акие т ипы: "один-к-одному", " один-ко-множест ву", " множест во-ко-множест ву". Типичной формой документ ирования информационной модели ПО ест ь диаграммы "сущност ь- связь" (ER-диаграммы). ER-диаграмма позволяет графически предст авит ь все элемент ы информационной модели согласно прост ому, инт уит ивно понят ным, но чет ко определенным правилом нот ациям. Дальше мы будем пользоват ься условными обозначениями, принят ыми в мет одологии информационного проект ирования. Сущност ь на Er-Диаграмме приводит ся прямоугольником с именем в верхней част и. Будем использоват ь английские слова для именования элемент ов модели. Рисунок 2.2 Предст авление сущност и Student (ст удент) на ER-Диаграмме с ат рибут ами и уникальным идент ификат ором сущност и В прямоугольнике перечисляют ся ат рибут ы сущност и, при эт ом ат рибут ы, кот орые предст авляют уникальный идент ификат ор сущност и, подчеркивают ся. Домени назначают ся аналит иками и фиксируют ся в специальном документ е словаре данных (Data Dictionary). На ст адиях разработ ки логической и физической моделей реляционной БД домени ут очняют ся в сущност ях на ER-диаграмме. Разработчик БД должен тщательно выучить домены каждого атрибута с точки зрения на возможност ь их реализации в СКБД. Рисунок 2.3 Визуализация определения доменів ат рибут ов на Er-Диаграмме при создании физической модели реляционной БД От ношение (связь) сущност ей на ER-диаграмме изображает ся линией, кот орая соединяет эт и сущност и. Ст епень связи изображает ся с помощью символа "пт ичья лапка", чт о указывает на т о, чт о в связи принимает участ ие много (N) экземпляров сущност и, и одинарной
16 Тема 2 - Понятие модели данных предметной области 16 горизонт альной черт очкой, кот орая указывает на т о, чт о в связи принимает участ ие один экземпляр сущност и. Отношения читается вдоль линии или слева направо, или спава налево. На рис. 2.4 приведено т акое от ношение: каждый ст удент должен быт ь зарегист рирован за определенной группой, в каждой группе может быть зарегистрировано один или больше студентов. Рисунок 2.4 Предст авление от ношения между двумя сущност ями на ER-Диаграмме 2.3 Концептуальнаямодельпредметнойобласти Диаграмма «сущност и - связи» служит средст вом описания схемы базы данных на концепт уальному уровне проект ирования. Мет од был предложен в 1976 году Пит ером Пен Шань Ченом. На диаграммах концепт уального уровня сущност и изображают ся прямоугольниками, атрибуты эллипсами, связи ромбами. Разработ аем концепт уальную модель предмет ной област и учет а успешност и ст удент ов в пределах кафедры. На рис. 2.5 приведенный первыйфрагмент концепт уальной диаграммы, кот орый от ображает принадлежност и ст удент ов определенной группе и изучение ст удент ами предмет ов. Рисунок 2.5 Фрагмент концепт уальной модели ПО на первом эт апе Успешност ь усвоения мат ериалов дисциплин конт ролирует ся зачет ными мероприят иями, кот орые определяют балл каждого ст удент а из определенной дисциплины. Ведь необходимо выделить отдельно сущность Statement (успешность), которая будет отображать связь между сущност ями Subject и Student (рис. 2.6). На диаграмме присут ст вующая одна связь «множест ва-ко-множест ву», кот орый являет ся недопуст имым в реляционной БД. Давайт е проанализируем: каждый ст удент проходит конт рольные мероприят ия по нескольким предмет ам и каждый предмет изучает ся несколькими ст удент ами. Каждый ст удент учит ся в одной группе и в каждой группе учат ся несколько студентов. Сведение на контрольное мероприятие выдается на группу студентов. Ведь замена сущност и Student в связи «получают» на сущност ь Group решает конфликт ную сит уацию. Каждый объект БД имеет свои ат рибут ы. Ведь приходим к т акому виду фрагмент у концепт уальной диаграммы ПО успешност ь, кот орая приведена на рис Рисунок 2.6 Фрагмент концептуальной модели ПО на втором этапе Вообще, если исследует ся дост ат очно объемная ПО, рациональным ест ь разработ ки нескольких локальных концепт уальных моделей при дальнейшем их объединении в более сложную общую концепт уальную модель. Локальные модели формируют ся т аким образом, чтобы количество объектов (сущностей) не превышала 6-7 штук.
17 Тема 2 - Понятие модели данных предметной области 17 Рисунок 2.7 Фрагмент концептуальной модели на третьем этапе 2.4 Функциональная модель предметной области Трет ьим ключевым момент ом создания ИС с целью авт омат изации информационных процессов организации ест ь анализ функционального взаимодейст вия объект ов авт омат изации. Аналит ики приводят результ ат ы в виде функциональной модели ПО БД. Сост ав функциональной модели сущест венным образом зависит от конт екст а конкрет ного ІТ- Проекта и может быть представленный с помощью довольно широкого спектра документов в виде т екст овой и графической информации. Определим функциональную модель ПО БД как совокупност ь некот орых моделей, предназначенных для описания процессов обработ ки информации. Будем называт ь эт и модели конст рукциями функциональной модели. Ниже приведенный перечень основных конст рукций функциональной модели, кот орые необходимые для выполнения проект ирования реляционных БД. Модели процессов: бизнес-модель процессов (иерархия функций сист емы); модель пот ока данных. Модели сост ояний: модель жизненного цикла сущност и; набор спецификаций функций сист емы (т ребования); описание функций системы через сущности и атрибуты; бизнеса-правила, кот орые реализуют функции. Бизнес-Модель процессов Бизнес-Модель процессов предназначена для описания процессов и функций сист емы в ПО БД. Чаще всего, бизнес-модель документируется соответственно нотациям IDEF0 и подается в виде совокупност и иерархически благоуст роенных и взіємопов'язаних диаграмм. Диаграммы содержат т акие компонент ы: конт екст ная диаграмма; диаграмма декомпозиции; диаграмма дерева узлов; диаграмма «т олько для экспозиции». Конт екст ная диаграмма являет ся вершиной иерархической ст рукт уры диаграмм и являет ся обобщенным описанием сист емы и ее взаимодейст вия с внешней средой. Дальнейшее описание сист емы ст роит ся последоват ельной разбивкам функциональной сист емы на более дет альные фрагмент ы диаграммы декомпозиции. Диаграмма дерева узлов передает иерархическую ст рукт уру функций без от ображения взаимосвязи между ними. Диаграммы «т олько для экспозиции» подают копии ст андарт ных диаграмм без синт аксиса модели. Они предназначены для демонст рации других т очек зрения на работ ы, для от ображения дет алей, кот орые не поддерживают ся синт аксисом модели в явном виде. Основными элемент ами IDEF 0 диаграмм ест ь работ ы, входные т ы исходные парамет ры, управления, механизмы и вызов. Примеры диаграмм будут приведены в следующей т еме на
18 Тема 3 - Проектирование базы данных 18 примере анализа процесса проект ирования базы данных. Модель пот ока данных Модель пот ока данных предназначенная для описания процессов перемещения данных в ПО БД и подает ся в виде диаграммы пот ока данных (Data Flow Diagram). Основными элемент ами диаграммы ест ь: ист очника данных (Data Source); процессы обработ ки данных (Data Process); хранилища данных (Data Store); пот оки данных (Data Flow) Источники данных указывают, кто пользуется или работает с данными. Процессы обработки указывают на операции, кот орые происходят над данными. Хранилища данных указывают на мест а сохранения данных. Пот оки данных указывают на образ передачи данных между ист очниками и хранилищами данных. Для представления диаграмм потока данных частіш за все используют сетевые структуры, кот орые позволяют дублирование сущност ей и от сут ст виециклов. Пот ок изображает ся слева направо. На диаграммах замечают допуст имое и недопуст имое направления перемещения данных без указания процессов управления пот оком. Диаграмма пот ока данных позволяет: представить систему с точки зрения источников и пользователей данных; от образит ь перемещение данных в процессе обработ ки; от образит ь внешние механизмы передачи данных; от образит ь мет од получения данных. Диаграмма пот ока данных предост авляет проект ировщику информацию об: хранилища данных, кот орые позволит на следующих эт апах проект ирования обоснованно определить количество БД для ИС; принят ые схемы преобразования информации, кот орая позволит в дальнейшем сост авит ь спецификации приложений. Модель жизненного цикла (ЖЦ) сущност и предназначенная для описания изменения ст анов сущност и и переходів между ними. Подает ся в виде диаграмм ЖЦ сущност и (Entity Lifecycle Diagram), кот орые от ображают направления перехода сущност и из некот орого начального стана к конечному стану и событию, которые инициируют изменения станов сущности. Модель ЖЦ также может быть представлена в текстовом виде описания. Набор спецификаций функций сист емы (т ребований), описание функций через сущност и и ат рибут ы, правила-бизнес-правила. Аналит ики должны предст авит ь проект ировщикам БД набор спецификаций функций описание функциональност ь сист емы в форме чет ко сформулированных бизнес-кат егорий, сгруппированных по направлениям деят ельност и организации. Иногда подает ся перечень зависимост ей между функциями и событ иями, кот орые их вызывают. Текст овое описание функции должен содержат ь выделении сущност и и ат рибут ы,а т акже однозначно инт ерпрет ироват ься при чт ении. После получения набора спецификаций функций и описания через ат рибут ы и сущност и проект ировщик БД может начат ь разработ ку спецификаций модулей приложений БД. Бизнес-Правила подают конкрет ные т ребования и условия для функций, кот орые определяют поведение данных, и используют ся для поддержки целост ност и данных в БД. Выводы Сделаем выводы по вт орой т еме: обеспечит ь пользоват еля информацией о внешнем миру операт ивно можно пут ем реализации от вет ного-вопросно-соот вет ст вующего от ношения о предмет ной област и. Сущест вуют несколько моделей ПО; информационная модель данных предназначена для предст авления семант ики ПО в сроках субъект ивных средст в описания сущност ей, ат рибут ов, идент ификат оров сущност ей, супертипов, подтипов и т.д.; основные принципы реляционной БД на концепт уальному уровне можно сформулироват ь т ак: все данные подают ся в виде благоуст роенной ст рукт уры ст рок и ст олбцов, кот орая называет ся от ношением; все значения являют ся скалярами, т о ест ь для любой ст роки и ст олбца любого от ношения сущест вует одно и т олько одно значение; все операции выполняются над целым отношением и результат операции есть также целое отношение. Этот принцип называет ся замыканием; функциональная модель предназначена для описания процессов обработ ки данных в рамках выделенной ПО из разных т очек зрения. элемент ы информационной модели ПО являют ся входными данными для задачи создания логической модели данных. Элемент ы функциональной модели ПО являют ся входными данными для задачи проект ирования приложений БД и, част ично, для задачи создания физической модели БД.
19 Тема 3 - Проектирование базы данных 19 Вопрос для самопроверки В чем сост оит назначение ИС? Дайт е определение понят ия «предмет ная област ь»? Какие модели ПО вы знаете? Что содержит в себе объектное ядро ПО? Как формируется имя объекту? Что такое ситуации? Классификация сит уаций ПО. Дайт е определение информационной модели ПО. Какие основные конст рукции информационной модели вы знает е? Дайт е определение сущност и? Как идентифицируется сущность в БД? Что является отношением БД? Что такое связь в БД? Чем характ еризует ся связь? Какие формы предст авления информационной модели вы знает е? Чт о от ображает концепт уальная модель ПО? Чт о т акое функциональная модель ПО? Какие основные конст рукции функциональной модели вы знает е? Тема 3 - Проектирование базы данных 3 ПРОЕКТИРОВАНИЕ БАЗЫ ДАННЫХ 3.1 Жизненный цикл и методология проектирования Процесс создания т акой ст рукт уры базы данных, кот орая бы от вечала т ребованиям пользоват елей, называет ся проект ированием базы данных. Его можно сравнит ь с возведением нового здания: определение т ребований, проект ирование, конст руирование и, в конце концов, реализация. Жизненный цикл сист емы баз данных являет ся концепцией, в пределах кот орой полезно и удобно рассматривать развитие такой системы. Он, как и жизненный цикл любой программной сист емы, сост авляет ся с двух основных фаз: проект ирование и реализации (рис. 3.1) Фаза проектирования делится на такие этапы: определение ст рат егии; анализ предмет ной област и; концепт уальное моделирование; логическое и физическое проект ирование. Фаза реализации сост авляет ся из т аких пункт ов: собст венно программная реализация; документ ирование; исследоват ельское внедрение.
20 Тема 3 - Проектирование базы данных 20 Рисунок 3.1 Этапы жизненного цикла БД Мет одология проект ирования баз данных эт о совокупност ь принципов, мет одов, инструментов и средств, которые применяются для последовательного разработки структуры базы данных. Поскольку сист ема баз данных сост авляет ся из программ и данных, мет одология проект ирования баз данных рассмат ривает ся как неот ъемлемая част ь общей мет одологии проект ирования программных сист ем. К мет одологии проект ирования баз данных выдвигают ся определенные т ребования. Приемлемой полагает ся база данных, кот орая от вечает т ребованиям пользоват елей (эффект ивност ь, адапт ивност ь, независимост ь,защищенност ь, целост ност ь и т.п.) и т ребованиям к аппарат ному обеспечению. Мет одология должна быт ь дост ат очно гибкой, дост упной разработ чикам с разным опыт ом проект ирования, кот орые используют разные модели данных и разное программное обеспечение СКБД. Мет одология проект ирования баз данных определяет: процесс проект ирования; мет одику выполнения расчет ов и крит ериев оценивания альт ернат ивных решений на каждом эт апе проект ирования; информационные т ребования как исходные дани для процесса проект ирования; средст ва описания исходных данных и от ображение результ ат ов каждого эт апа проект ирования. Процесс проектирования Для баз данных можно применит ь ит ерационное нисходящее проект ирование. Процесс проект ирования хорошо ст рукт урирован, поскольку каждый его эт ап завершает ся определенным результ ат ом, а т акже поэт ому, чт о допускает ся ит ерационное повт орение предыдущих эт апов, если полученный результ ат не от вечает т ребованиям заказчика или
21 Тема 3 - Проектирование базы данных 21 системным требованиям. Это дает возможность просматривать и менять проектные решения на будь- кот орому эт апе. С проект ированием т есно связанное эксперт ное оценивание проект а. Цель эксперт изы найт и ошибки и исправит ь их на ранних эт апах проект ирования. По обыкновению эксперт иза выполняет ся после завершения каждого из эт апов. Этап проектирования БД полагает одним из самых сложных этапов создания БД, который не имеет явным образом выраженного начала и окончания. В сравнении с анализом т ребований к БД или разработ кой приложений, проект ирование БД, по мнению многих руководящих специалист ов, являет ся неудачно ст рукт урированной задачам. Если все эт апы создания БД перекрывают ся друг с другом в своей последоват ельност и, т о эт ап проект ирования перекрывает ся со всеми другими эт апами. Проект ированияначинает ся с момент а принят ия стратегических решений и длится на этапах реализации и тестирование. Процесс проект ирования БД охват ывает несколько основных сфер: проект ирование объект ов БД (т аблицы, предст авление, индексы, т риггеры, сохраненные процедуры, функции, пакет ы) для предст авления данных ПО в БД; проект ирование инт ерфейса взаимодейст вия с БД ( формы, от чет ы и т.д.), т о ест ь проект ирование приложений, кот орые будут сопровождат ь данные в БД и реализовыват ь от вет ные-вопросно-соот вет ст вующие от ношения на эт их данных; проект ирование БД под конкрет ная вычислит ельная среда или информационную т ехнологию (архит ект ура " клиент-сервер", параллельные архит ект уры, распределенная вычислит ельная среда); проект ирование БД под назначения сист емы (инт еллект уальный анализ данных, OLAP, OLTP и т.д.). Критерии оценивания Оценивание необходимое для принят ия решений при наличии альт ернат ив. Трудност и в определении крит ериев и выборе альт ернат ив связанные с т ем, чт о част о разрабат ывает ся несколько проект ов ст рукт уры базы данных и нужно оценит ь, кот орый из них ест ь лучшим. Сделат ь эт о бывает довольно сложно. Крит ерии ест ь количест венные (время обработ ки запросов, ст оимост ь операций манипулирования данными, зат рат ы памят и и т.п.) и качест венные (гибкост ь, адапт ивност ь, восприимчивост ь и совмест имост ь). Информационные требования Определяя т ребования к информации, учт ит е, чт о ест ь информация, кот орая касает ся ст рукт уры данных (описание данных и связей безот носит ельно к конкрет ным образам их использования и обработ ки), и информация об образе использования данных (описание т ребований к обработ ки данных). Средства описания Эт о языковые средст ва, предназначенные для описания результ ат ов выполнения каждого ет ану проект ирования. А именно, речь идет о т аких средст вах. Ест ест венный язык, кот орым ст рого определяют все необходимые для описания результ ат ов проект ирования понят ия. Использует ся, как правило, на эт апе определения стратегии. Стандартные формы, анкеты и бланки. Используются преимущественно на этапе анализа. Специальные формализованные языки концепт уального моделирования (семант ические сет и, исчисление предикат ов и Еr- Языки). Используют ся преимущест венно на эт апе концепт уального моделирования. Формализованные язык определения данных (МОД) и язык манипулирования данными (ММД). Используют ся на эт апе логического проект ирования. По обыкновению с эт ой целью применяют язык SQL. 3.2 Этапы проектирования БД Определение ст рат егии Целью эт апа определения ст рат егии ест ь формирования совмест но с заказчиком прикладных моделей, изгот овление перечня рекомендаций и принят ие согласованного плана, сост авленного с учет ом имеющихся организационных, финансовых и т ехнических ограничений, который отображает как текущие, так и будущие нужды организации. Описание. Дет альный анализ ст рукт уры организации может быт ь начальной базой для разработки перспективного плана создания системы, но затраты на него проведение едва ли будут экономически оправданными. Как правило, ст рат егия разработ ки информационной сист емы определяет ся в результ ат е обобщенного анализа, на основании кот орого пот ом ст роит ся крупномасшт абная модель прикладной област и. Ст рат егия должна определят ься в достаточно сжатые сроки с тем, чтобы результаты проектирования не теряли актуальности. Результаты этого этапа должны согласовываться друг с другом и быть достаточно четко сформулированные, чт обы заказчик мог легко соот нест и предложенную ст рат егию со своими задачами и понять, какие именно факторы обусловили принятие тех или других решений. Кроме
22 Тема 3 - Проектирование базы данных 22 т ого, ему должны быт ь изложена перспект ива дальнейшего анализа, ут очнение и просмот ра ст рат егических решений. Результаты. Основными результ ат ами эт ого эт апа должны быт ь описание направлений прикладной деят ельност и, в част ност и формулирования ее целей и задач, определение приорит ет ов, ограничений, крит ических факт оров успеха и ключевых показат елей эффект ивност и; описание целей и задач авт омат изации, зат рат и возможного выигрыша; обобщенная диаграмма сущност ей и связей; обобщенная иерархическая схема задач (производст венных и управленческих); рекомендации от носит ельно будущей реализации и преодоления возможных т рудност ей; определение границ и очерчивания сферы применения сист емы баз данных; возможная архит ект ура сист емы; поэт апный план проект ирования базы данных Такой подход к моделированию предмет ной област и предусмат ривает ее от ображение с т рех разных т очек зрения: общее направление прикладной деят ельност и; прикладные задачи; информационные нужды. Пост роенные на эт ом эт апе модели должны быт ь понят ными для заказчика, а для т ого чт обы дост ичь полного согласования разных т очек зрения на прикладную област ь и возможные направления деят ельност и, проводят ся групповые координационные совещания Ст рат егии эволюционируют и развивают ся, обст оят ельст ва и задачи со временем могут менят ься, зат ем невозможно предложит ь директ ивный мет од моделирования ст рат егий.поэт ому важно объединят ь бесприст раст ност ь к новым решениям со способност ью быст ро оцениват ь альт ернат ивные направления деят ельност и с учет ом заданных ограничений и приорит ет ов. Ключевые факторы успеха: использование всех возможных средст в, кот орые дают возможност ь повысит ь уровень знаний о предметной области; активное участие в разработке стратегии лиц, которые хорошо понимают истинные нужды организации; проведение плодот ворных совещаний с т щат ельным рассмот рением всех вопросов Анализ предмет ной област и Итоги этапа определения стратегии являются исходными данными для этапа анализа, где они т щат ельно проверяют ся, ут очняют ся и дет ализируют ся, для т ого чт обы обеспечит ь предмет ной област и адекват ност ь модели, гарант ироват ь возможност ь реализации решений и сформироват ь т вердую основу для эт апов концепт уального моделирования, логического и физического проект ирования. Этот этап является меньше всего изученным, наиболее тяжелым и длительным. Однако он самый важный, поскольку именно на нем формирует ся большинст во проект ных решений Описание. Анализ предмет ной област и сост оит из анализа данных и анализа задач. Анализ данных предусмат ривает документ ирование всех ат рибут ов. Анализ задач может нуждат ься в применение разных мет одов пост роения диаграмм для исследования связей и образов использования данных, событ ий, сост ояний данных, а т акже дет ального описания алгорит мов. Изучается потребность в мерах из контроля и защиты данных, их резервном копировании и восст ановлении. Должен быт ь проведен дет альный анализ имеющихся сист ем и других факт оров, кот орые влияют на процесс внедрения сист емы. Нужно оказат ь все ограничения и предположение, кот орыемогут повлият ь на дальнейшее проект ирование, использование ресурсов и сроки проведения работ. Подход. На эт ом эт апе аналит ики и пользоват ели работ ают бок о бок, уст анавливая и проверяя т ребования. Анализ предмет ной област и предусмат ривает: проведение бесед с пользоват елями; просмот р всех документ ов и бланков, кот орые обрабат ывают ся и формируют ся организацией; анализ пот оков документ ов; анализ образов решения задач организации; фиксация правил, ограничений и законов, кот орые дейст вуют в предмет ной област и. Результаты: согласованная диаграмма сущност ей и связей; сведения об объемах данных, част от у выполнения задач, ожидаемый пользоват елем уровень производит ельност и; дет ализированное и согласованное описания задач: первичный вариант ст рат егии внедрения; описание мероприят ий по ревизии и конт ролю данных, резервного копирования и восст ановления;
23 Тема 3 - Проектирование базы данных 23 общее описание процедур, кот орые не авт омат изуют ься; крит ерии приемлемост и, качест ва, гибкост и и производит ельност и; предыдущее оценивание объемов сист емы; согласованный подход к осущест влению эт апа проект ирования и фазы реализации; ут очненный план разработ ки сист емы. Ключевые факторы успеха: акт ивное участ ие пользоват елей; тщательная проверка достоверности, полноты и непротиворечивости данных; выявление всех вопросов и предположений, кот орые имеют ключевое значение для проект ирования и внедрения; уст ановление т очных характ ерист ик ключевых задач и данных; жест кий конт роль за ходом работ, концент рация усилий на выполнении календарных планов и соблюдении запланированных сроков Концепт уальное моделирование предмет ной област и Эт ап концепт уального моделирования сост оит в пост роении описания предмет ной област и в сроках формального языка, например в сроках модели сущност ей и связей. Идеи пост роения концепт уальной модели предмет ной област и ведут свое начало из публикации рабочей группы ANSI/SPARC, посвященной архит ект уре СКБД. Описание. На базе содержат ельного описания предмет ной област и, полученного в результ ат е ее анализа, розроблюєт ься ст рогое формальное описание ее информационного обеспечения. Результаты: формальное описание информационного обеспечения ПО; подробное и ст рогое описание хранилищ данных; дет альное описание пот оков данных; дет альное описание иерархии и спецификация задач, кот орые решают ся; дет альное описание дейст вующих в предмет ной област и правил и ограничений. Ключевые факт оры успеха: глубокое знание и практ ический опыт использования языков описания концепт уальной модели, знание мет одов проект ирования реляционной модели и/или других моделей данных Логическое и физическое моделирование данных Эт ап проект ирования сост оит в поиске и определении наилучшего образа реализации и выполнение т ребований, сформулированных на эт апе анализа. При эт ом должен обеспечиват ься надлежащий уровень сервиса в условияхопределенного т ехнологического среды, кот орая от вечает принят ым решениям от носит ельно уровня авт омат изации. Логическое проект ирование эт о разработ ки ст рукт ур хранения, мет одов дост упа и логической ст рукт уры сист емы баз данных без привязки к конкрет ной СКБД. Физическое проект ирование эт о проект ирования базы данных в конкрет ной СКБД. Описание. Во время выполнения эт ого эт апа модель сущност ей и связей превращает ся в схему базы данных и спецификации хранения данных на внешних носит елях. Прикладные задачи превращают ся в модуле и процедуры с необходимыми средст вами ревизии/конт роля и резервного копирования и восст ановление. Проецируют ся формат ы от чет ов, определяют ся міжмодульні связи. Исходя из задач, сформулированных на предыдущих эт апах, создают ся проект ные решения из архит ект уры коммуникационной сет и. Для облегчения процесса поиска проект ных решений могут применят ься прот от ипы. В конце концов, на эт апе проект ирования розроблюют ься программные спецификации и план т ест ирования сист емы, а полученная информация и новые взгляды на будущую сист ему применяют ся для доработ ки и ут очнения ст рат егии ее реализации. Подход. Аналит ики, разработ чики и проект ировщики баз данных общают ся с пользоват елями меньше, чем на эт апе анализа, однако они должны предост авит ь им для проверки результ ат ы своей работ ы или предложит ь на выбор разные вариант ы проект ных решений. Полезным ест ь создания прот от ипов, однако оно должны рассмат риват ься лишь как средст во, а не самоцель. Результаты: архитектура системы: схемы сист емных модулей: логическая и физическая схемы; схема базы данных и файлов; дет альные временные и емкост ные характ ерист ики; программные спецификации; спецификации неавт омат изированных процедур; черновой вариант пособия для пользоват еля; согласованная ст рат егия внедрения, кот орое сост авляет ся из планов приема и сдачи сист емы, организационной подгот овки, мер с собирания данных, перехода на новую сист ему и уст ановление оборудования;
24 Тема 3 - Проектирование базы данных 24 план испыт аний сист емы; черновой вариант эксплуат ационной документ ации; ут очненный план разработ ки сист емы. Ключевые факторы успеха. В результ ат е выполнения данного эт апа должен быт ь создан проект, кот орый обеспечивает удовлет ворение прикладных т ребований с учет ом имеющихся т ехнических ограничений. Ключевыми факт орами успеха в дост ижении эт ой цели ест ь: знание возможност ей аппарат ного и программного обеспечения; понимание прикладных нужд; принятие обоснованных компромиссных решений; выявление и решение пот енциальных проблем 3.3 Бизнес-модель процесса преоктирования базы данных Типовая бизнес-модель процесса проект ирования базы данных Значит ельная част ь проект ов в сфере информационных т ехнологий направлена на разработ ку и создание ИС, в рамках кот орых осущест вляет ся обработ ка данных разной сложност и. Практ ически во всех т аких проект ах решает ся задачи проект ирования БД определенного т ипа. В эксплуат ации БД должна удовлет ворят ь набор т ребований от носит ельно ряда инт егрированных парамет ров, т аких, как: функциональност ь и адапт ируемост ь; производит ельност ь обработ ки т рансакций; пропускная способност ь; время реакции; безопасност ь. Такие параметры иногда находятся в противоречии друг с другом. Так, высокие требования к функциональност и на данном конкрет ном оборудовании могут вст упат ь в конфликт с высокими т ребованиями к производит ельност и. Например, от чет ы могут генерироват ься на прот яжении нескольких часов и снизить в настоящее время реакции пользователей, которые работают с сист емой в диалоговом режиме. Проект ирование БД эт о поиск средст в удовлет ворения функциональных т ребований средст вами имеющейся компьют ерной т ехнологии с учет ом заданных ограничений. Процесс проект ирования БД может быт ь предст авлен в виде модели бизнес-процессов. Бизнес-Модель процесса проект ирования позволяет: от образит ь субъект ивную мысль разработ чика БД на процесс проект ирования конкрет ной БД; учест ь особенност и ІТ-проект а, в рамках кот орого проецирует ся БД; довольно быст ро составить план проектирования конкретной БД; просчит ат ь продолжит ельност ь проект ных работ (создат ь временную модель проект ирования). Рассмот рим т ипичную бизнес-модель процесса проект ирования БД. На рис. 3.2 приведенная конт екст ная диаграмма процесса проект ирования БД. Как видно из рисунка 3.2, на вход процесса проектирования БД подаются: информационная модель ПО БД: диаграммы " сущност ь-связь" (ER- диаграммы); функциональная модель ПО БД: бизнес-модель процессов, диаграммы пот ока данных (DF- Диаграммы), диаграммы ст анов, - диаграммы жизненных циклов сущност ей, спецификации на сист емы (т ребования), бизнес-правила; общесист емные т ребования и ограничения; задача обрат ного влияния. На выходе процесса проектирования БД формируются такие результаты: физическая модель БД, чт о может быт ь преобразованная в скрипт для создания БД; физическая БД; спецификация модулей приложений БД; план тестирования БД.
25 Тема 4 - Проектирование модулей приложений 25 Рисунок 3.2 Конт екст ная диаграмма процесса проект ирования БД Диаграмма декомпозиции первого уровня Начиная функциональную декомпозицию процесса проект ирования БД, приходим к диаграммы декомпозиции процесса проект ирования БД первого уровня, кот орая от бивает основные, наиболее большие профессиональные задачи (эт апы) проект ирование БД (рис. 3.3). Такими задачами (эт апами) ест ь: сбор и анализ входных данных эт о начальный эт ап проект ирования, на кот ором осущест вляют ся сбор и конт роль качест ва результ ат ов анализа ПО БД, гот овит ся план проект ирования БД; создание логической модели БД эт о эт ап, на кот ором на основании информационной модели ПО БД создает ся логическая ст рукт ура БД, независимая от ее реализации; создание физической модели БД: внут ренняя схема эт о эт ап, на кот ором на основании логической модели БД создает ся физическая ст рукт ура БД, зависимая от ее реализации. На эт ом эт апе выполняет ся преобразования от ношения логической модели реляционной БД в команды создания объект ов физической БД, в результ ат е чего создает ся т ак называемая внут ренняя схема БД. Дополнит ельно может быт ь созданная т ак называемая внешняя схема БД, последнее от бивает т очку зрения пользоват елей на данные в БД; создание физической модели БД: учет влияния т ранзакций эт о эт ап, на кот ором анализируют ся возможные т ранзакции сист емы, по пот ребност и выполняет ся денормалізація от ношение для обеспечения более высокой производит ельност и БД; создание серверного кода это этап, на котором на основании функциональной модели ПО БД создает ся серверный код БД в виде т риггеров, сохраненных процедур и пакет ов. Эт и модули создают ся разработ чиком БД и выполняют ся сервером; проект ирование модулей приложений БД эт о эт ап, на кот ором создают ся спецификации модулей приложений, разрабат ывают ся ст рат егии т ест ирования БД и приложений, создает ся план тестирования приложений БД и готовятся тесту данные; конт роль качест ва проект ирования БД сост оит в проверке качест ва результ ат ов проект ирования на каждом его эт апе; учет задач обрат ного влияния сост оит в наст ройке некот орых т рансакций к БД и локальной перепроект ировке БД согласно т ребованиям, кот орые пост упают из других эт апов создания БД.
26 Тема 4 - Проектирование модулей приложений 26 Рисунок 3.3 Диаграмма декомпозиции процесса проект ирования БД: первый уровень Выводы Таким образом, можем сделат ь вывод, чт о процесс проект ирования БД сост оит в дост ижении компромиссов между функциональными, информационными, аппарат ными, архит ект урными и т ехнологическими т ребованиями к БД и ст роит ся на осведомленном принят ии решений за ст рукт урой БД. Проект ирования начинает ся с момент а принят ия стратегических решений и длится на этапах реализации и тестирование. Приведенная в лекции бизнес-модель процесса проект ирования БД предст авляет собой довольно прост ой т ипичный пример бизнеса-модели проект ирования. В общем случае содержание бизнес-модели проект ирования зависит от многих факт оров: личност и менеджера и состава команды проекта, объема проекта, проектных рисков и т.д. Основной целью эт апа создания логической модели БД ест ь преобразования информационной модели ПО БД в логическую модель реляционной БД, результ ат ом являет ся нормализованная схема от ношений БД Основная цель задачи разработ ки внут ренней схемы БД ест ь преобразования логической модели реляционной БД в последоват ельност ь команд SQL для создания объект ов реляционной БД. В результ ат е выполненияучет а влияния т ранзакций разработ чик БД создает физическую модель БД, что учитывает характер обработки данных в БД. Вопросы для самопроверки 1. В чем сост оит процесс проект ирования БД? 2. Назовит е основные эт апы процесса проект ирования БД. 3. В чем сост оит цель процесса анализа входных данных? 4. Назовит е основные эт апы процесса анализа входных данных. 5. В чем состоит цель процесса разработки логической структуры БД? 6. Назовит е основные эт апы процесса разработ ки логической ст рукт уры. 7. В чем состоит цель процесса разработки внутренней схемы БД? 8. Назовите основные этапы процесса разработки внутренней схемы БД. 9. В чем состоит цель процесса учета влияния транзакций? 10. Назовите основные этапы процесса учета влияния транзакций. Тема 4 - Проектирование модулей приложений 4 ПРОЕКТИРОВАНИЕ МОДУЛЕЙ ПРИЛОЖЕНИЙ БАЗЫ ДАННЫХ 4.1 Анализ функциональной модели предметной области базы данных Исходными данными для решения задачи проект ирования модулей приложений БД являет ся
27 Тема 4 - Проектирование модулей приложений 27 иерархия функций. На выходе разработ чик должен получит ь описание (спецификацию) модулей приложений, а в процессе проект ирования модулей разработ чик ст роит от ображение бизнес - требований в спецификации модулей. Алгоритм действий разработчика БД состоит в следующем: сначала разработчик старается сформулироват ь бизнес - т ребования (функции) в самом общем виде, а пот ом выполняет декомпозицию каждой т акой бизнес-функции до т ех пор, пока не будет полученная некот орая функция, которую можно считать атомарной функцией. Рассмот рим мет одологию проект ирования на примере. Рассмот рим фрагмент иерархии функций для обработ ки заявлений о выплат е ст рахового возмещения. На упрощенной схеме 4.1 проанализирована функция "2. Обработ ат ь заявление". Реализация эт ой функции включает выполнение чет ырех функций следующего уровня: "2.1. Зарегист рироват ь заявление", "2.2. Ут вердит ь решение от носит ельно заявления", "2.3. Произвест и плат еж по заявлению", "2.4. Закрыт ь заявление". На рис. 4.1 показанная дальнейшая декомпозиция функции "2.2. Ут вердит ь решение от носит ельно заявления". Полученная на эт ом эт апе функция " Позволит ь ремонт" являет ся ат омарной функцией. Ремонт разрешает ся или не разрешает ся. При рассмот рении иерархии функций разработ чику БД следует обрат ит ь внимание на т акие момент ы: в функциональной модели БД описывают ся бизнес-функции, и не все они будут непосредст венно поддерживат ься приложением БД; при рассмот рении иерархий нередко возникает сит уация, когда экземпляры одной и т ой же функции будут имет ь разные номера. Если в первом случае дополнит ельную информацию о т ом, кот орые бизнес-функции будут реализованы в сист еме, можно получит ь от руководит еля проект а, т о во вт ором случае разработ чик БД, вероят нее всего, имеет дело с ошибкой аналит ика в определении функции. Рисунок 4.1 Иерархия функций для обработ ки заявлений о выплат е ст раховой компенсации 4.2 Определение функций При разработ ке иерархии функций аналит ик должен предост авит ь т екст овое описание к каждой функции, по крайней мере для верхнего и самого нижнего уровней иерархии. Желательно, чтобы в этом описании аналитики выделяли сущности ПО. Это важно для того, чт обы знат ь с какими сущност ями ПО работ ает функция, т о ест ь какие пот енциальные объект ы реляционной БД будут использоват ься в каждой функции. Если эт о не сделано, т о разработчикам БД придет делать это самостоятельно. Пример. Определение функции " Проверит ь принят о ли заявление". Получить и зарегистрировать все необходимые страховой компанией сведения о заявлении (СВЕДЕНИЯ О ЗАЯВЛЕНИИ), включая все подробные сведения о третьих сторонах (ПОСТОРОННИЕ ЮРИДИЧЕСКИЕ ЛИЦА) и свидетелях (ФИЗИЧЕСКИЕ ЛИЦА). Выучить страховой полис (ПОЛИС) на предмет наличия исключительных ситуаций (ИСКЛЮЧЕНИЕ) и определить, действуют ли эти ситуации в случае данного заявления (ЗАЯВЛЕНИЕ). Если есть исключения, то закрыть заявление и составить стандартное письмо заявителю об отказе в выплате (ПИСЬМО) заявителю (ЗАЯВИТЕЛЬ). Если никаких исключений нет, то изменить статус заявления на ожидание оценки, назначить и сообщить оценщика (ОЦЕНЩИК)" Из примера видно, какие сущности ПО принимают участие в выполнении функции (выделенные в скобках), как изменяется состояние сущности (выделено курсивом) и каков алгоритм работы этой функции. Из примера понят но, чт о на эт ом эт апе разработ чик БД в качест ве исходных данных использует т акже информационную модель ПО БД (описание сущност ей).
28 Тема 4 - Проектирование модулей приложений 28 При выполнении анализа функций полезно имет ь некот орую т аблицу (мат рицу) "Функция- Сущность", которая должна дать ответ на следующие вопросы: имеет ли каждая сущност ь конст рукт ор (функцию, кот орая создает все экземпляры сущности); имеет ли она дест рукт ор (функцию, кот орая удаляет экземпляры сущност и); ест ь ли ссылка на эт у сущност ь (функции, кот орые используют эт у сущност ь и какой образ). Процесс анализа взаимодейст вия функции и сущност и принят о обозначат ь аббревиат урой CRUD (Create, Reference, Update, Delete - создание, ссылка, модификация, удаление). Из примера понят но, чт о на эт ом эт апе разработ чик БД в качест ве исходных данных использует т акже информационную модель ПО БД (описание сущност ей). При выполнении анализа функций полезно имет ь некот орую т аблицу (мат рицу) "Функция-Сущност ь", кот орая должна дат ь от вет на следующие вопросы: имеет ли каждая сущност ь конст рукт ор (функцию, кот орая создает все экземпляры сущност и); имеет ли она дест рукт ор (функцию, которая удаляет экземпляры сущности); есть ли ссылка на эту сущность (функции, которые используют эт у сущност ь и какой образ). Процесс анализа взаимодейст вия функции и сущност и принят о обозначат ь аббревиат урой CRUD (Create, Reference, Update, Delete - создание, ссылка, модификация, удаление). 4.3 Отображение функций в модуле Одним из основных заданий проект ирования модулей приложений ест ь пост роение от ображения функций в модуле. При решении эт ой задачи разработ чик БД должен акцент ироват ь внимание на ст рукт уре БД, чт о предст авляет основу приложения. Как правило, решение задачи отображения функций в модуле выполняется в четыре этапа: 11.Анализ работ ы функции. 12.Пост роение модели сущност ей, кот орая поддерживает эт и функции. 13.Начат ь проект ирование физической ст рукт уры по созданию схемы, кот орое поддерживает разработ анную модель сущност ей. 14.Завершит ь проект ирование разработ кой спецификаций модулей, кот орые реализуют функции на предложенной схеме БД. Из предложенного выше подхода видно, как т есно переплет ают ся в процессе проект ирования процессы разработ ки физической модели БД и спецификаций модулей приложений. Таким образом, если разработ чиком был разработ анный черновой вариант физической модели БД по общепринят ым алгорит мам, т о на эт ом эт апе он должен быт ь адапт ирован к реализации функций и, возможно, значит ельно переработ анный. При от ображении функций в модуле необходимо получит ь схему, кот орая ст авит в соот вет ст вие каждой функции определенный модуль. Рассмот рим БД, кот орая содержит информацию о сот рудниках, от делах и проект ах организации. Предположим, она будет поддерживат ь бизнес-функцию "Управление проект ами в организации". Функциональная модель ПО БД в т ерминах иерархии функций приведена на рис. 5.2, а на рис. 5.3 приведен перечень функций управления проект ами в организации. Задача состоит в отображении функций из перечня на рис. 4.3 в перечень модулей. Сначала из перечня функций должны быт ь изъят ы т е функции, кот орые не будут поддерживат ься приложением БД. Разработ чик узнает уруководит еля проект а, чт о в приложении БД не будут поддерживат ься следующие функции: назначить куратора проекта; извест ит ь руководит елей подразделений; извест ит ь сот рудников; собрат ь совещание; приступиться к выполнению; составить список работ; определить объем работ; определить стоимость работ; определит ь время работ; определит ь производст венные мощност и; распределит ь производст венные мощност и; распределит ь работ ы с сот рудников; конт ролироват ь ход выполнения проект а. Таким образом, будет получен перечень функций, кот орый показан в левой колонке т аблицы 4.1. Эт ому перечню функций должен быт ь пост авлен в соот вет ст вие перечень модулей приложения БД.
29 Тема 4 - Проектирование модулей приложений 29 Рисунок 4.2 Иерархия бизнес-функции "Управление проект ами в организации" Рисунок 4.3 Перечень функции управления проект ами в организации Таблица 4.1 Перечни функций и модулей Функции Назначит ь руководит еля проект а Определит ь бюджет проект а Модуль Введение информации о проект е Введение информации о сот рудниках
30 Тема 4 - Проектирование модулей приложений 30 Определит ь список подразделений Определит ь список сот рудников Выполнят ь проект Сдат ь проект Поиск информации о сот рудниках Поиск информации о проект ах Генерация от чет а о выполненных проект ах Генерация от чет а о выполняемых проект ах Руководит ель проект а передал разработ чику БД характ ерист ику приложения БД по управлению выполнением проект ов в организации. Эт о приложение будет занимат ься учет ом выполняемых и выполненных проект ов в организации. Разработ чик БД должен уст ановит ь от ображение функций в модуле, как показано на рис Приведенный пример показывает общий принцип пост роения от ображения бизнес-функций в модуле. Рисунок 4.4 От ображение функции в модуле 4.4 Системные модули Во время реализации функциональных возможност ей необходимо рассмот рет ь дост ат очное количест во процессов, кот орые не являют ся среди сформулированных бизнес-функций. Например, возможность выдачи результатов работы модуля в файл или на принтер. Набор модулей приложений БД, кот орый не следует явным образом из бизнес-функции, но являет ся необходимым для обеспечения работ ы сист емы, называет ся сист емным. К т аким модулям можно от нест и процедуры резервного копирования и авт омат ического восст ановления, модули изменения паролей, модули печат и и навигации по приложениям БД и др. Разработ чик БД самост оят ельно решает вопрос разработ ки спецификации сист емных модулей. 4.5 Размещение логики обработки Во время разработ ки серверного кода необходимо соблюдат ься прост ых правил: использоват ь возможно большее количест во ограничений на колонки реляционных т аблиц для реализации правил обработ ки данных без процедурного кода; использоват ь т риггеры БД для поддержания целост ност и данных во время процедурного введения правил обработ ки данных; использоват ь сохраненные процедуры для инкапсуляции общих бизнес-функций; использоват ь т ребования производит ельност и во время окончат ельного выбора от носит ельно разделения кода. Как от мечают специалист ы, преобладающее количест во недост ат ков в прикладных сист емах вызваны неопределенност ью различия между правилами для данных, правилами для процессов и правилами для инт ерфейса. Рассмот рим основные из них. Правила для данных формулируют т ребования, кот орым должны удовлет ворят ь данные, и дейст вуют для каждого экземпляра данных и выводят ся из модели данных. Примеры: пол человека может быт ь лишь мужской или женский; каждый заказ предназначен лишь для одного покупат еля.
31 Список литературы 31 Правила для процессов определяют, чт о может или не может выполнят ь приложение, и выводят ся из модели функций. Пример: размер ст ипендии не должен превышат ь 1000 грн; т олько преподават ель может выст авит ь оценку за экзамен. Правила для инт ерфейса определяют, каким должен видет ь приложение пользоват ель. Эт и правила не касают ся обработ ки, лишь влияют на воображение пользоват еля о приложении БД. Выводят ся со спецификации пользоват ельского инт ерфейса. Пример: все коды оценок должны разъяснят ься. Выделение и анализ эт их правил приводит к формированию т рех наборов документ ов: описание ст рукт уры инт ерфейса, ст рукт уры процессов (определяет реализацию инт ерфейса) и ст рукт уры данных (определяет основные объект ы БД, с кот орыми работ ают процессы). Корот ко сформулируем основные принципы размещения бизнес-логики в модулях приложений БД: правила для инт ерфейса реализуют ся во внешний (клиент ской) част и сист емы независимо от примененных языков программирования или генерат оров от чет ов; правила для процессов реализуют ся в виде процедур, кот орые вызывают ся из клиент ской част и и предст авляют серверный код; правила для данных реализуют ся в самые БД в виде ограничений и т риггеров. 4.6 Общие принципы разработки спецификаций модулей После разработ ки схемы «функции-модули» проект ировщик прист упает к решению емкой задачи написания спецификации модулей. Последняя позволит программист ам пост роит ь реальную сист ему с использованием БД. Во время написания нужно максимально исключит ь субъект ивные мысли от носит ельно написания кода, поскольку код пишет ся другими специалист ами по т ест ированию. Ст арат ься избегат ь формальных языков описания алгорит мов, использоват ь формулирование в общем виде. Не следует использоват ь команды языка SQL, поскольку во время т ест ирования админист рат ор БД может изменит ь физическую модель БД, чт о послужит причиной изменения команд. Нужно избегат ь лишних инст рукций. Спецификация должная обязат ельно содержат ь т акие компонент ы: условное название модуля; функции, выполнение кот орых обеспечивает модуль; перечень т аблиц и колонок, к кот орым происходит дост уп; для каждой колонки образ использования (запрос, вст авка, удаление или обновление); перечень колонок; дет альное описание всех дейст вий, кот орый может выполнят ь модуль. Пример: т ипичная спецификация модуля предост авления дост упа к приложению БД. Наименование: Ст раница для входа в приложение Login. Цель: идент ификация пользоват еля и предост авления дост упа к приложению БД. Исходные данные: Имя пользоват еля. Пароль. Таблица БД: Useraccount Колонки: Username запрос, поиск в предикат е поиска; Userpass запрос, поиск в предикат е поиска. Дейст вия: При условии отсутствия пользователя с таким именем и паролем в БД отказать в доступе и вывест и запрос на правильное введение данных не более чем 3 раза. При условии наличия пользователя с таким именем и паролем в БД предоставить доступ к модулю «Главная ст раница», кот орая имеет разный вид соот вет ст венно правам пользоват еля. Коммент арии: В зависимости от типа модуля (экрана форма, отчет и др.), спецификации могут содержать дополнит ельную информацию от носит ельно размещениякнопок или формат от чет а. В эт ом случае спецификацию нужно дополнит ь т акими позициями: данные о навигации (какой модуль вызывает, какие модули вызывают ся); значение входных парамет ров по умолчанию; перечень событ ий, кот орые обрабат ывают на экранной форме, каким образом обрабат ывают; перечень ошибок и дейст вий, связанных с них обработ кой; данные от носит ельно безопасност и; макет экранной формы или шаблон отчета. Выводы Исходными данными для решения задачи проект ирования модулей приложений БД являет ся иерархия функций модуля приложения, на основе кот орых должны быт ь сформулированы бизнес - т ребования (функции) в самом общем виде. Вт орым эт апом являет ся декомпозиция каждой т акой бизнес- функции до т ех пор, пока не будет полученная некот орая функция, которую можно считать атомарной функцией.
32 Раздел 2 - Реляционная модель данных 32 Из материала лекции видно, как тесно переплетаются в процессе проектирования процессы разработ ки физической модели БД и спецификаций модулей приложений. Приведенные рекомендации определяют общие принцип разработ ки модулей БД, кот орые могут быт ь дополнены в каждом част ном случае предмет ной област и. Вопрос для самопроверки 1. В чем сост оит анализ функциональных т ребований к БД? 2. Назовит е основные эт апы процесса разработ ки приложения. 3. Какие компоненты должна иметь таблица «Функция - Сущность»? 4. Назовит е основные эт апы процесса от ображения функции в модуле. 5. Какие модули относят к системным? 6. Сформулируйт е основные правила логического разработ ки приложений БД. 7. Какие компонент ы должны содержат ься в спецификации модуля БД? РЕКОМЕНДОВАННАЯ ЛИТЕРАТУРА 1. К. Дж. Кейт Введение в системы баз данных Перьев. с англ. 8-е изд. М.: Издательский дом «Вильямс», С. 2. Пушников А.Ю. Введение в сист емы управления базами данных. Част ь 1. Реляционная модель данных: Учебное пособие/ Изд-е Башкирского ун-т а. Уфа, с. 3. Томас Коннолли, Каролин Бегг. Базы данных. Проект ирование, реализация и сопровождение. Теория и практ ика. 3-е изд. М.: Издат ельский дом «Вильямс», 2003, 1436 с. 4. Джен Л. Харрингт он Проект ирование реляционных баз данных. М.: Издат ельст во «Лори», с. 5. Пасичник В.В.Организация баз данных и знаний: учебник для ВНЗ/ В.В. Пасичник, В.А. Резніченко. К.: Издат ельская группа BHV, с. 6. В.Е. Туманов. Основы проект ирования реляционных баз данных 7. Д.В. Кознов. Визуальное моделирование: т еория и практ ика Список литературы РЕКОМЕНДОВАННАЯ ЛИТЕРАТУРА 1. К. Дж. Кейт Введение в системы баз данных Перьев. с англ. 8-е изд. М.: Издательский дом «Вильямс», С. 2. Пушников А.Ю. Введение в сист емы управления базами данных. Част ь 1. Реляционная модель данных: Учебное пособие/ Изд-е Башкирского ун-т а. Уфа, с. 3. Томас Коннолли, Каролин Бегг. Базы данных. Проект ирование, реализация и сопровождение. Теория и практ ика. 3-е изд. М.: Издат ельский дом «Вильямс», 2003, 1436 с. 4. Джен Л. Харрингт он Проект ирование реляционных баз данных. М.: Издат ельст во «Лори», с. 5. Пасичник В.В.Организация баз данных и знаний: учебник для ВНЗ/ В.В. Пасичник, В.А. Резніченко. К.: Издат ельская группа BHV, с. 6. В.Е. Туманов. Основы проект ирования реляционных баз данных 7. Д.В. Кознов. Визуальное моделирование: т еория и практ ика 1. К. Дж. Кейт Введення в системи баз даних Пер. с англ. 8-е изд. М.: Издательский дом «Вильямс», С. 2. Томас Коннолли, Каролин Бегг. Базы данных. Проект ирование, реализация и сопровождение. Теория и практ ика. 3-е изд. М.: Издат ельский дом «Вильямс», 2003, 1436 с. 3. Джен Л. Харрингт он Проект ирование реляционных баз данных М.: Издат ельст во «Лори», с. 4. Пасічник В.В.Організація баз даних т а знань: підручник для ВНЗ/ В.В. Пасічник, В.А. Резніченко. К.: Видавнича група BHV, с. 5. В.Е. Туманов. Основы проект ирования реляционных баз данных 6. Д.В. Кознов. Визуальное моделирование: т еория и практ ика
33 Раздел 2 - Реляционная модель данных 33 Раздел 2 - Реляционная модель данных Тема 5 - Реляционная модель данных 5 РЕЛЯЦИОННАЯ МОДЕЛЬ ДАННЫХ 5.1 Реляционная ст рукт ура данных Теорет ические основы реляционной модели баз данных были заложены Э. Коддом в начале 70- х годов XX века. В отличие от распространенных в то время систем с иерархическими или сет евыми т ипами ст рукт ур данных, реляционный подход предложил упрощенные ст рукт уры данных - реляции, или т аблицы, и расширил возможност и языка манипулирования данными. В научной лит ерат уре, посвященной реляционным базам данных, для определения т ого, чт о было названо выше реляцией или таблицей, часто применяется термин отношения. Каждый из этих т ерминов имеет свои преимущест ва и недост ат ки. Термином «от ношения» в мат емат ической теории отношений сказывается несколько другое понятие и поэтому толкование этого термина в конт екст е т еории баз данных являет ся неоднозначным. Недост ат ок т ермина «реляция» заключает ся в его недавнем иноязычном происхождении. Поэт ому для т еорет ических разработок будем употреблять термин «реляционное отношение», а в примерах - «отношение» или «т аблица». Рассмотрим пример. Таблица расписания движения поездов или самолет ов, условно говоря, сост оит из двух част ей: наполнение и описания ст рукт уры т аблицы. Наполнение эт о т е номера рейсов поездов или самолет ов и время их от правки, занесенных в соот вет ст вующие ячейки т аблицы и периодически меняют ся, а ст рукт ура т аблицы описывает ся заголовками ст олбцов. Согласно т ерминологии баз данных и реляционного подхода, наполнение т аблиц называют данными. Иногда бывает т ак, чт о т аблица расписания содержит т олько пуст ые ст олбцы. Такой объект специалист по базам данных мог бы назват ь схеме. Реляционное от ношение в реляционной модели данных изображает ся через схему и экземпляр от ношения. Схема записывает ся в видеили прост о R(A1, A2,, Ak), если связь атрибутов с доменами известна априори. Совокупност ь схем реляционных от ношений называют схемой базы данных, или реляционной схемой. Схема реляционного от ношения обладает следующими свойст вами: Реляционное от ношение имеет имя; Имена ат рибут ов в пределах схемы одного реляционного от ношения должны быт ь уникальными; Порядок ат рибут ов в схеме реляционного от ношения не являет ся сущест венным, поскольку обращение к атрибуту осуществляется по имени, а не по телефону. Пример схемы реляционного от ношения:
34 Раздел 2 - Реляционная модель данных 34 EDUCATION (#Id_Person, Id_School, Date_enter, Date_left) Здесь EDUCATION - эт о имя реляционного от ношения, а # Id_Person, Id_School, Date_enter, Date_left - имена его атрибутов. Экземпляр реляционного от ношения эт о его наполнение. Точнее, экземпляр являет ся множеством кортежей, а кортеж это множество значений. Экземпляр отношение имеет такие свойст ва. порядок корт ежей произвольный; корт ежи, как элемент ы множест ва должны быт ь уникальными в пределах реляционного от ношения. Реляционное от ношение может быт ь изображено в виде т аблицы. Пример т абличного от ображения реляционного от ношения приведены на рис Рисунок Расписание авт обусов как от ношение Таблица эт о поименованное двумерное изображение от ношения, она сост оит из одного или более поименованных ст олбцов и нуля или более ст рок. Название т аблицы соот вет ст вует имени реляционного от ношения, имена ст олбцов именам ат рибут ов, а ст роки корт ежам. Табличная форма предст авления от ношения была введена с целью популяризации модели среди неподгот овленных пользоват елей БД. Тракт овка реляционной т еории на уровне т аблиц скрывают ряд определений, важных для понимания как т еории реляционных БД, т ак и языка манипулирования данными. Во-первых, атрибуты различных отношений могут быть определены на одном домене, так же как и ат рибут ы одного от ношения. Эт о очень важное обст оят ельст во, чт о позволяет уст анавливат ь связи по значению между от ношениями. Во-вт орых, множест во мат емат ически по своему определению не может имет ь совпадающих элемент ов, и, следоват ельно, корт ежи в отношении можно различить только по значению их компонентов. Это тоже очень важно для модели: никакие два корт ежа не могут имет ь полност ью совпадающих компонент ов. Таким образом, в реляционной модели полност ью исключает ся дублирование данных о сущност и реального мира. В-т рет ьих, от мет им, чт о схема от ношения т акже множест во, позволяет работ ат ь с ними с помощью т еорет ико - множест венных операций. Эт о являет ся важным момент ом для пост роения т еории проект ирования реляционных схем БД. Ключом или ключевым полем называет ся уникальное значение, позволяющее т ем или иным способом идент ифицироват ь сущност ь или част ь сущност и ПО, т.е. ключ - эт о значения некоторого атрибута или атрибутов в кортеже отношения, представляет экземпляр сущности в реляционной модели данных. Принят о различат ь первичные ключи и част ичные ключи. Мат емат ически первичным ключом от ношения являет ся подмножест во сужения декарт ового произведения, кот орое позволяет однозначно идент ифицироват ь корт еж. Если первичный ключ сост оит из нескольких ат рибут ов, т о он называет ся сост авным ключом, в прот ивном случае ат омарным. Част ичным ключом называет ся ат рибут сост авного ключа, если он однозначно определяет совокупност ь неключевых ат рибут ов от ношения. Ат рибут корт ежа, являет ся первичным ключом другого от ношения, называет ся внешним (иногда пост оронним) ключом. Из определения от ношения выт екает следующее важное свойст во реляционной модели данных: каждое от ношение должно имет ь первичный ключ. От мет им, чт о ключ в конт екст е модели ПО БД всегда отражает ту или иную степень связи между атрибутами сущностей ПО, т.е. семантически ключ ест ь средст во моделирования связей в модели. Пример: рассмот рим предложения "Гражданин Иванов проживал в городе Москве 10 лет". Возможными ат рибут ами в от ношении Мест о_проживания являет ся фамилия гражданина, название города проживания и время проживания. Фамилия гражданина может выст упат ь в качест ве первичного ключа эт ого от ношения, пот ому чт о личност ь однозначно определяет время его проживания в конкрет ном городе. Таким образом, в эт ом моделирует ся связь "проживал" между ат рибут ами "фамилия" и "город".
35 Раздел 2 - Реляционная модель данных 35 Пример. Предст авление связи от ношением. Предст авим связь между личност ью и мест ом его обит ания через от ношение ЖИВЕТ (Кл. личност ь, Кл. Населенного_пункт а, Время) Описание личност и: ЛИЧНОСТЬ (Кл. личност ь, ФИО, Возраст, Пол) Описание населенного пункт а: НАСЕЛЕННЫЙ_ПУНКТ (Кл.населенного_пункт а, География, Население) Однако наибольшее распрост ранение получило предст авление от ношений в виде графических диаграмм, например ER-диаграмм, о кот орых мы говорили раньше. Преимущест вами т акого предст авления являет ся наглядност ь диаграмм и возможност ь их пост роения в ряде CASE-средст в проект ирования БД. В ит оге сформулируем основные свойст ва реляционной модели данных, выт екающих из понятия отношения как множества: Все кортежи одного отношения должны иметь то же количество атрибутов. Значение каждого из ат рибут ов должно принадлежат ь некот ором определенном домена. Каждое от ношение должно имет ь первичный ключ. Никакие два корт ежа не могут имет ь полност ью совпадающих наборов значений. Каждое значение ат рибут ов должно быт ь ат омарными, т о являет ся не должно имет ь внутренней структуры и содержать как компонент другое отношение. Реляционная модель данных должна быт ь непрот иворечивой, в част ност и должно выполнят ься 1) принцип ссылочной целост ност и - связи между от ношениями должны быт ь замкнут ыми, 2) значение колонок должны принадлежат ь т ому же определенном для них домена. Порядок следования корт ежей в от ношении не имеет значения. Порядок в большей ст епени свойст вом хранения данных, чем свойст вом непосредст венно самой реляционной модели данных. 5.2 Реляционная алгебра Общие сведения В сост ав реляционной модели данных, кроме ст рукт уры данных, должны входит ь операции манипулирования данными. Из всех т аких операций сост оит язык запросов. Наиболее извест ными языками запросов в реляционной модели являет ся реляционная алгебра и реляционное исчисление. В классическом понимании алгебра определяет ся как пара, сост оящая из основной множест ва и множест ва операций (сигнат уры), при эт ом аргумент ы и результ ат каждой операции от носят ся основной множест ве. Реляционная алгебра являет ся алгеброй в ст рогом классическом понимании ее определения. Элементами основной множества является реляционные отношения. В связи с этим операции алгебры могут вкладыват ься друг в друга, т о являет ся аргумент ом определенной операции может быт ь результ ат выполнения другой операции. Эт о дает возможност ь записыват ь запросы произвольного уровня сложност и в виде выражений, содержащих вложенные друг в друга операции Операции реляционной алгебры Сигнат ура реляционной алгебры Кодда сост оит из восьми операций. Прежде чем подробно рассмот рет ь эт и операции, введем понят ие совмест имост и реляционных от ношений. Эт о понят ие необходимо, поскольку некот орые операции (а именно: т еорет ико-множест венные операции объединения, пересечения и разност и) определены т олько для совмест имых реляционных отношений. Реляционные от ношения R1(A1,, An) і R2(B1,, Bk) называют ся совмест имыми, если: У них одинаковое количество атрибутов, то является k = n; Можно установить взаимно однозначное соответствие между доменами атрибутов первой и второй реляций, т.е. существует такое биективне отображения То являет ся домены сопост авленных ат рибут ов одинаковы. Для удобст ва будем счит ат ь, что сопоставимые атрибуты совместимых отношений должны иметь одинаковые имена. Дадим т акже определения нескольких свойст в бинарных операций: Операция φ является коммутативной, если А φ В = В φ А; Операция φ является ассоциативной, если (А φ В) φ С = А φ (В φ С) ; Операция φ является дистрибутивной с операцией θ, если А φ (В θ С) = (А φ В) θ (А φ С). Давая определение бинарным операциям реляционной алгебры, мы будем указыват ь, какие из этих свойств они имеют. Поскольку различные отношения могут содержать атрибуты с одинаковыми именами. то при выполнении бинарных операций в конечном от ношении могут повт орят ься имена ат рибут ов. Для обеспечения уникальност и имен ат рибут ов они ут очняют ся именами соот вет ст вующих от ношений согласно т аким синт аксисом: <имя отношения>. <имя атрибута> При рассмот рении операций реляционной алгебры ат рибут ы обозначат ь большими буквами с начала лат инского алфавит а: А, В. а множест ва ат рибут ов - большими буквами с середины
36 Раздел 2 - Реляционная модель данных 36 лат инского алфавит а: L, М. От мет им некот орые особенност и т еорет ико -множест венных операций. В реляционной алгебре, в от личие от алгебры множест в, еще не использует ся операция дополнения, поскольку определенные домены могут быт ь бесконечными или содержат ь очень много значений и в результ ат е операции дополнения можно получит ь или бесконечное от ношение, или от ношение с очень большим количест вом корт ежей Требование совмест имост и операндов обусловлены т ем, чт о без эт ого ограничения результатом теоретико -множественных операций могли бы быть разноструктурные кортежи, а не реляционные от ношения. Объединения. Пуст ь L - некот орое множест во ат рибут ов. Объединением совмест имых реляционных от ношений R1 и R2 со схемами R1 (L) и R2 (L) (обозначает ся R1 R2) называет ся т акое реляционное от ношение R схеме R (L), содержащий корт ежи обоих объединяемых от ношений, но без повт орений (рис. 4.2). Операция коммут ат ивна, ассоциат ивна и дист рибут ивная от носит ельно пересечения. Рисунок Операция объединения отношений Пересечение. Предположим, что L - некоторое множество атрибутов. Сечением совместимых реляционных от ношений R1 и R2 со схемами R1 (L) и R2 (L) (обозначает ся R1 R2) называет ся т акое реляционное от ношение R схеме R (L), кот орое содержит корт ежи, входящие в сост ав обоих операндов (рис. 5.3).: Операция коммут ат ивна, ассоциат ивна и дист рибут ивная от носит ельно объединения. Рисунок Операция пересечения отношений Разница Пуст ь L - некот орое множест во ат рибут ов. Разницей совмест имых реляционных от ношений R1 и R2 со схемами R1 (L) и R2 (L) (обозначается R1- R2) называется такое реляционное отношение R схеме R (L), содержащий кортежи с первого операнда R1, которых нет во втором операнде R2 (рис. 5.4):. Операция не коммутативна, НЕ ассоциативная и не дистрибутивная с другими операциями. Рисунок Операция разницы отношений Декарт овое произведение. Декартовым произведением реляционных отношений R и S со схемами и соответственно, что сказывает ся RxS, называет ся от ношение Q схеме, кот орое содержит все возможные соединения кортежей отношения R с кортежами отношения S (рис. 5.5): Операция коммут ат ивна и ассоциат ивна. Рисунок Операция декарт ового произведения от ношений Специальные операции. Селекция выборка по крит еряим, кот орые выполняют ься пост рочно. Проекция выборка по колонкам. елекція вибірка по крит еріям, що виконуєт ься по рядкам. Естественное объединение изображено на рис. 5.6, деление рис. 5.7 Рисунок 5.6 Операция ест ест венного обїединения от ношений
37 Тема 6 - Нормализация реляционной модели данных 37 Рисунок 5.7 Операция деления от ношений 5.3 Понятие функциональной зависимости На ст адии логического проект ирования реляционной БД разработ чик определяет и выст раивает схемы от ношения в рамках некот орой ПО, а именно предст авляет сущност и, группирует их ат рибут ы, выявляет основные связи между сущност ями. Так, в самом общем смысле проект ирования реляционной БД сост оит в обоснованном выборе конкрет ных схем от ношений из множест ва различных альт ернат ивных вариант ов схем. На практ ике пост роение логической модели БД, независимо от модели данных, выполняет ся с учет ом двух основных т ребований: исключит ь избыт очност ь и максимально повысит ь надежност ь данных. Эт и т ребования выт екают из т ребования коллект ивного использования данных группой пользоват елей. Поэт ому любое априорное знание об ограничении ПО, накладывают на взаимосвязи между данными и значения данных, и знания об их свойствах и взаимоотношения между ними может сыграт ь определенную роль в соблюдении указанных выше т ребований. Формализация т аких априорных знаний о свойст вах данных ПО БД нашла свое от ражение в концепции функциональной зависимост и данных, т о ест ь ограничений на возможные взаимосвязи между данными, кот орые могут быт ь т екущими значениями схемы от ношений. Корт ежи от ношения могут предст авлят ь экземпляры сущност и ПО или фиксироват ь их взаимосвязь. Но даже если эт и корт ежи соот вет ст вуют схеме от ношений и выбраны из допустимых доменов, не всякий из них может быть текущим значением некоторого отношения. Например, возраст человека редко бывает больше 120 лет, или т от же пилот не может одновременно выполнят ь два разных рейса. Такие ограничения семант ики домена практ ически не влияют на выбор т ой или иной схемы от ношений. Они предст авляют собой ограничения на т ипы данных. Поскольку функциональную зависимость можно задать в виде таблицы, а таблица является формой предст авления от ношений, т о ст ановит ся очевидной связь между функциональной зависимост ью и от ношением. От ношение может задават ь функциональную зависимост ь. Эт о ут верждение являет ся первой конст рукт ивной идеей, кот орая положена в основу т еории проект ирования реляционных БД. Пример. Понят ие функциональной зависимост и Проиллюст рируем понят ие функциональной зависимост и на примере графика полет ов аэропорт а. ГРАФИК_ПОЛЁТОВ (Пилот, Рейс, Дат а_вылет а, Время_вылет а) Иванов :20 Иванов :30 Исаев :00 Исаев :30 Петров :20 Петров :30 Фролов :00 Фролов :00 Извест но, чт о: каждому рейсу соот вет ст вует определенное время вылет а, для каждого пилот а, дат ы и времени вылет а возможен т олько один рейс, на определенный день и рейс назначает ся определенный пилот. Ит ак: " Время_вылет а" функционально зависит от , " Рейс" функционально зависит от , " Пилот" функционально зависим от . Важной задачей при выявлении функциональных зависимост ей на ат рибут ах от ношений, по определению являет ся множест вом, необходимо выяснит ь, какой из ат рибут ов выст упает как аргумент, а какой - как значение функциональная зависимост ь. Наиболее подходящими кандидат ами в аргумент ы функциональной зависимост и являет ся возможные ключи, пот ому чт о корт ежи предст авляют экземпляры сущност и, кот орые идент ифицируют ся значениями атрибутов своего ключа Выводы
38 Тема 6 - Нормализация реляционной модели данных 38 В ит оге сформулируем основные свойст ва реляционной модели данных, выт екающих из понятия отношения как множества: Все кортежи одного отношения должны иметь то же количество атрибутов. Значение каждого из ат рибут ов должно принадлежат ь некот ором определенном домена. Каждое от ношение должно имет ь первичный ключ. Никакие два корт ежа не могут имет ь полност ью совпадающих наборов значений. Каждое значение ат рибут ов должно быт ь ат омарными, т о являет ся не должно имет ь внутренней структуры и содержать как компонент другое отношение. Реляционная модель данных должна быт ь непрот иворечивой, в част ност и должно выполнят ься 1) принцип ссылочной целост ност и - связи между от ношениями должны быт ь замкнут ыми, 2) значение колонок должны принадлежат ь т ому же определенном для них домена. Порядок следования корт ежей в от ношении не имеет значения. Порядок в большей ст епени свойст вом хранения данных, чем свойст вом непосредст венно самой реляционной модели данных. Вопросы для самоконтроля 1. Назовит е преимущест ва реляционной БД? 2. Объясните понятие «отношение». 3. Какие компонент ы сост авляют от ношения? 4. Что такое ключевое поле? Назначение и разновидности. 5. Объясните понятие «целостность данных». 6. Что такое категориальная целостность? 7. Что такое целостность по ссылке 8. Какие основные операции реляционной алгебры от носят ся к операциям над от ношением БД? 9. Назовит е основные свойст ва реляционной БД. 10.Назовит е основные принципы при определении функциональных зависимост ей. Тема 6 - Нормализация реляционной модели данных 6 НОРМАЛИЗАЦИЯ РЕЛЯЦИОННОЙ МОДЕЛИ ДАННЫХ 6.1 Нормальные формы реляционных отношений Под реляционной БД принят о понимат ь совокупност ь экземпляров конечных от ношений. Совокупност ь схем от ношений образует схему реляционной БД. Схема реляционной БД являет ся логической моделью реляционной БД. На основе информационной модели в процессе проект ирования создают ся логическая и физическая модели данных. Информационная модель данных от ражает пот ребност и сист емы в данных и связи между данными с т очки зрения их пот ребит елей пользоват елей; логическая модель данных являет ся независимым логическим предст авлением данных, физическая модель данных содержит определения всех реализованных объект ов в конкрет ной БД для конкрет ной СУБД. Уст ановление функциональной зависимост и и получения наилучшего с т очки зрения минимальност и предст авления множест ва функциональных зависимост ей позволят пост роит ь наиболее опт имальный вариант БД, обеспечивает надежност ь хранения и обработ ки данных на основе мет одов эквивалент ных преобразований схем от ношений реляционной БД. Процесс решения т акой задачи называет ся нормализацией от ношений информационной модели ПО и заключает ся в преобразовании ее объект ов в логические т аблицы БД. Основные т ребования следующие: первичные ключи от ношений должны быт ь минимальными; число отношений БД должно по возможности давать наименьшее избыточность данных - т ребование надежност и данных; число отношений БД не должно приводить к потере производительности системы;
39 Тема 6 - Нормализация реляционной модели данных 39 данные не должны быть противоречивыми, то есть при выполнении операций добавления, удаления и обновления данных их пот енциальная прот иворечивост ь должна быт ь сведена к минимуму; схема от ношений БД должна быт ь уст ойчивой, способной адапт ироват ься к изменениям при ее расширении дополнительными атрибутами - требование гибкости структуры БД; разброс времени реакции на различные запросы к БД не должен быть большим; данные должны правильно от ражат ь сост ояние ПО БД в каждый конкрет ный момент времени т ребование акт уальност и данных; Создание сист емы, одновременно удовлет воряющей всем вышеуказанным т ребованиям, предст авляет собой сложную опт имизационную задачу, решение кот орой не имеет однозначного значения. Реляционное отношение находится в той или иной нормальной форме, если заданные на нем функциональные зависимост и удовлет воряют определенным условиям. От ношения, кот орые не находят ся в соот вет ст вующей нормальной форме, имеют определенные нежелат ельные свойст ва, или аномалии. Поэт ому возникает пот ребност ь в нормализации, ориент ированной на то, чтобы лишить реляционные отношения этих свойств. Аномалии возникают вследствие того, чт о реляционные от ношения могут содержат ь избыт очные функциональные зависимост и, т.е. количест во ат рибут ов от ношения может быт ь слишком велико, и т огда возникает вопрос о коррект ност и его схемы. Коррект ной счит ает ся схема, кот орая не содержит нежелат ельных функциональных зависимост ей. Исправление некоррект ных схем осущест вляет ся с помощью процедуры декомпозиции (разложения) реляционного от ношения на множест во других от ношений. Цель эт ой процедуры пост роение множест ва т аблиц без нежелат ельных функциональных зависимост ей и аномалий. Эт о и являет ся сут ью процесса нормализации. Иными словами, нормализация эт о обрат ный процесс замены данной схемы реляционных от ношений другой схеме, в кот орой от ношение имеют прост ую и коррект ную форму. Возврат ност ь нормализации означает, чт о после ее осущест вления сохраняет ся возможност ь возвращения от ношение к исходному сост оянию. Теория функциональных зависимост ей позволяет уст ановит ь определенные т ребования к схемам от ношений в реляционной БД. Эт и т ребования формулируют ся в т ерминах свойст в от ношений и называют ся нормальными формами схем от ношений. Каждая нормальная форма от ношений связана с определенным классом функциональной зависимост и, кот орые предст авлены в от ношениях. Одним из очевидных средст в уст ранения пот енциальной прот иворечивост и данных в от ношениях логической модели реляционной БД являет ся их разбивка на два или более от ношений, в каждом из кот орых присут ст вует т олько одна функциональная зависимост ь. Процесс уст ранения пот енциальной прот иворечивост и и избыт очност и данных в от ношениях реляционной БД называет ся нормализацией выходных схем от ношений. Нормализация от ношений заключает ся в выполнении декомпозиции от ношений, находящт хся в предыдущей нормальной форме, на два или более от ношений, кот орые удовлет воряют т ребованиям следующей нормальной формы. В т еории реляционных БД обычно выделяет ся следующая последоват ельност ь нормальных форм: первая нормальная форма (1NF), вт орая нормальная форма (2NF), т рет ья нормальная форма (3NF) нормальная форма Бойса - Кодда (BCNF) чет верт ая нормальная форма (4NF), пят ая нормальная форма, или нормальная форма проекции - соединения (5NF или PJ / NF). Основные свойст ва нормальных форм сост оят в следующем: каждая следующая нормальная форма в некот ором смысле лучше предыдущей нормальной формы, при переходе к следующей нормальной форме свойст ва предыдущих нормальных форм сохраняют ся. 6.2 Первые нормальная форма; сост авные домены Реляционная модель не допускает использования сост авных (неат омарных) доменов, т о ест ь на пересечении строки и столбца в таблице должно стоять атомарное значение, неделимое с т очки зрения всех возможных применений. Реляционное от ношение находит ся в первой нормальной форме (1НФ), если все его ат рибут ы имеют ат омарные (прост ые) домены, зат емзначения элемент ов т аблицы являют ся прост ыми. Реляционное от ношение называет ся нормализованным, если оно находит ся в 1НФ. Первая нормальная форма от ношение находит ся в 1NF, если все ат рибут ы от ношения являют ся прост ыми (т ребование ат омарност и ат рибут ов), т о ест ь не имеют компонент ов. Иными словами, домен атрибута должен состоять из неделимых значений и не может включать в себя множест во значений с более элемент арных доменов. Пример 1. Пуст ь имеет ся переменное от ношение: Employer_Project_Task . Ат рибут ы содержат, соот вет ст венно, данные о номере дела, разряд и зарплат у служащего, номер проект а и о задачах, выполняет служащий в данном проект е. Предположим, чт о разряд служащего определяет размер его заработ ной плат ы и чт о каждый служащий может участ воват ь в нескольких проект ах при условии выполнения т олько одной задачи. Тогда очевидно, чт о единст венно возможным ключом
40 Тема 6 - Нормализация реляционной модели данных 40 от ношения являет ся сост авленный ат рибут . Диаграмма минимальной множест ва ER показана на рис В приведенном от ношении некот орые функциональные зависимости атрибутов от возможного ключа не являются минимальными. Это приводит к так называемым аномалий восст ановления. Во аномалиями восст ановления понимают ся т рудност и, с кот орыми ст алкивают ся при выполнении операций сложения корт ежей в от ношение (INSERT), удаления корт ежей (DELETE) и модификации корт ежей (UPDATE). Рисунок 6.1 ER-диаграмма от ношения Employer_Project_Task Применит ельно к нашему примеру: Добавление корт ежей мы не можем дополнит ь от ношение Employer_Project_Task данным о служащем, кот орый еще не участ вует в одном проект е (Em_Number являет ся част ью первичного ключа и не может содержат ь неопределенных значений). Между т ем част о бывает, чт о сначала служащего принимают на работ у, уст анавливают его разряд и размер заработ ной платы, а только затем назначают для него проект; Удаление кортежей мы не можем сохранить в отношении Employer_Project_Task данные о служащем, кот орый завершил участ ие в своем последнем проект е (по т ой причине, чт о значение ат рибут а Pr_Number для эт ого служащего ст ановит ся неопределенным); Модификация корт ежей изменяя разряд служащего, мы будем вынуждены модифицироват ь все корт ежи с соот вет ст вующим значением ат рибут а Em_Number. В прот ивном случае будет нарушена ест ест венная связь Em_Number Em_Degrees (у одного служащего ест ь т олько один разряд). Для преодоления эт их т рудност ей можно сделат ь декомпозицию переменного от ношение Employer_Project_Task на двух переменных от ношения Employer < Em_Number, Em_Degrees, Em_Рау >и Employer_Project_Task < Em_Number, Pr_Number, Em_Task >. На рис. 6.2 показаны ER - диаграммы эт их от ношений. Теперь мы можем легко справит ься с операциями восст ановления. Рисунок 6.2 ER - диаграммы в переменных от ношениях Employer и Employer_Project_Task 6.3 Вторая нормальная форма. Неполные функциональные зависимости Будем счит ат ь ат рибут от ношения ключевым, если он являет ся элемент ом какого-либо ключа от ношения. В прот ивном случае ат рибут будет счит ат ься неключевых. От ношение находит ся в 2NF, если оно находит ся в 1NF,и все неключевые ат рибут ы от ношения функционально минимально зависят от первичного ключа. Иными словами, 2NF т ребует, чт обы от ношение не содержало неполных (част ичных) функциональных зависимост ей. Пуст ь на реляционном от ношении R задано наборы ат рибут ов А и В. Функциональная зависимост ь R.А R.В называет ся полной, если В не зависит функционально от одного во набора С А, что не содержит В. Вт орая нормальная форма нейт рализует аномалии, связанные с неполным функциональными зависимост ями. Свест и от ношения ко вт орой нормальной форме можно т олько пут ем его разделения (декомпозиции) по крайней мере на два других. Но эт о разделение должно соот вет ст воват ь следующим условиям: От ношение, получаемые в результ ат е, являют ся проекциями исходного; Начальное реляционное от ношение можно восст ановит ь из конечных с помощью операции ест ест венного соединения без пот ерь данных; При декомпозиции не т еряют ся функциональные зависимост и (т.е. множест ва зависимост ей начального и конечного от ношений эквивалент ны). Путь к решению этой проблемы дает теорема, доказанная И. Хитом Теорема Хита.Если в реляционном от ношении R с наборами ат рибут ов А, В, С (B C = ) задано функциональную зависимость R.А R.В, то его можно декомпонуваты на два отношения
41 Тема 6 - Нормализация реляционной модели данных 41 R [ А, В] и R [А, с] т ак, чт о благодаря операции ест ест венного соединения проекций по группам атрибутов А исходное отношение R восстанавливается без потерь данных. Алгорит м возведения схемы от ношения к 2НФ являет ся. Пуст ь задано реляционное от ношение R с множест вом ат рибут ов М. Если в R являет ся неполная функциональная зависимость R.А R.В непервинного атрибута В от возможного ключа А, то R декомпонуеться на две проекции: R [ А, В] и R [ M- С] (М - В - это теоретико - множественная разность). Если полученные в результате таблицы все еще не находятся во второй нормальной форме, к ним снова применяется это правило, пока все отношения не достигнут 2НФ. Декомпозиция схемы реляционного от ношения ко вт орой нормальной форме называет ся опт имальной, если в результ ат е образует ся минимально возможное количест во т аблиц - проекций. Пример 2 Применит ельно к нашему примеру: от ношение Employer находит ся в 2NF, а от ношение Employer_Project_Task - нет, поскольку ат рибут Em_Task функционально зависит от двух ключевых ат рибут ов: Em_Number и Pr_Number. Любое переменное от ношение, находящееся в 1NF, но не находит ся в 2NF, может быт ь сведено к набору переменных от ношений, находящихся в 2NF. В результ ат е декомпозиции мы получаем набор проекций исходного переменного от ношения, природное соединение значений кот орых воспроизводит значение выходного переменного отношения (то есть это декомпозиция без потерь). 6.4 Третья нормальная форма и транзитивные зависимости От ношение находит ся в 3NF, если оно находит ся в 2NF, и все неключевые ат рибут ы от ношения зависят т олько от первичного ключа. Иными словами, 3NF т ребует, чт обы от ношение не содержало т ранзит ивных функциональной связи неключевых ат рибут ов от ключа. Понят ие функциональной т ранзит ивной зависимост и хорошо извест но в классической т еории множест в и т еории от ношений. В реляционном подходе использует ся более узкое т олкование этого термина. Набор ат рибут ов С т ранзит ивно зависит от набора ат рибут ов А, если сущест вует т акой набор ат рибут ов В, А В, В С и В А. Последним условием реляционный вариант определения от личает ся от классического. Наличие в реляционном отношении транзитивной зависимости приводит к тем же аномалий, и наличие неполной функциональной зависимост и. Если в R (А, В, С) предст авляют собой функциональные зависимости А В, В С, то такое отношение содержит информацию о двух множест ва сущност ей: (А, В) и (В, С), чт о приводит к аномалиям добавления, удаления и обновления. Декомпозиция реляционного от ношения на несколько от ношений в 3НФ должно удовлет ворят ь т е же свойст ва, чт о и декомпозиция в 2НФ. Алгорит м сведения к 3НФ базирует ся на т еореме Хит а. Рассмот рим его подробнее. Пусть задано отношение R с атрибутами (или наборами атрибутов) А, В, С, где А возможный ключ, и есть функциональные зависимости R.А R.В, RB RC Тогда таблица R декомпозируется на две проекции: R [А, В] и R [B, C]. Если полученные в результ ат е от ношение все еще не находят ся в т рет ьей нормальной форме, к ним снова применяет ся указанное правило. Функциональные зависимост и от ношения Employer прежнему порождает некот орые аномалии восст ановления. Они вызывают ся наличием т ранзит ивного связи Em_Number Em_Рау (через связь Em_Number Em_Degrees и Em_Degrees Em_Рау). Эт и аномалии связаны с избыт очност ью хранения значения ат рибут а Em_Рау в каждом корт еже, характ еризующий служащих с т ем же разрядом: добавления корт ежей - невозможно сохранит ь данные о новом разряд (и соот вет ст вующем ему размера зарплат ы), пока не появит ся служащий с новым разрядом. Первичный ключ не может содержат ь неопределенные значения; удаление корт ежей - при увольнении последнего служащего с данным разрядом мы пот еряем информацию о наличии т акого разряда и соот вет ст вующем размера зарплат ы; модификация кортежей - при изменении размера зарплаты, соответствующей некоторому разряду, мы будем вынуждены изменит ь значение ат рибут а Em_Рау в корт ежах всех служащих, кот орым назначен эт от разряд (иначе не будет выполнят ься связь Em_Degrees Em_Рау). Возможна декомпозиция: для преодоления эт их т рудност ей сделаем декомпозицию переменного от ношение Employer на двух переменных от ношения Employer1 и Degrees . На рис.6.3 показаны ER-диаграммы эт их переменных отношений. Таким образом, процедура возведения от ношение к 3NF сост оит в выполнении двух проекций: по правой и по левой части транзитивного функциональной связи. Понят но, чт о в процессе нормализации декомпозиция от ношения на независимые проекции являет ся лучшей. Необходимые и дост ат очные условия независимост и проекций от ношения обеспечивает теорема Риссанена: проекции r1 и r2 отношения r являются независимыми тогда и только тогда, когда каждый связь в отношении r логично выходит из связи в r1 и r2, общие
42 Тема 6 - Нормализация реляционной модели данных 42 атрибуты r1 и r2 образуют возможный ключ хотя бы для одного из этих отношений. Проиллюст рируем верност ь эт ой т еоремы на примере декомпозиции от ношения Employer. В декомпозиции на проекции Employer1 и Degrees общий ат рибут Em_Degrees возможно (и первичным) ключом от ношения Degrees, а единст венный дополнит ельный связь от ношение Employer (Em_Number Em_Рау) логически выходит из связи Em_Number Em_Degrees и Em_Degrees Em_Рау, выполняемых для от ношения Employer1 и Degrees соот вет ст венно. Рисунок 6.3 ER - диаграммы в переменных от ношениях Employer1 и Degrees сведенных к 3НФ Ат омарным от ношением называет ся от ношение, кот орое невозможно декомпозироват ь на независимые проекции. Далеко не всегда для неат омарних от ношений нужна декомпозиция на ат омарные проекции. При выборе способадекомпозиции необходимо ст ремит ься к получению независимых проекций, но не обязат ельно ат омарных. 6.5 НормальнаяформаБойса-Кодда Например, пуст ь имеет ся переменное от ношение Employer_Project_Task1 с множест вом связей, изображенных на рис Рисунок 6.4 Диаграмма функциональной связи от ношение Employer_Project_Task1 В от ношении Employer_Project_Task1 служащие уникально идент ифицируют ся как по номерам дел, т ак и по именам. Ит ак, сущест вуют связи Em_Number Em_Nаme и Em_Nаme Em_Number. Но один служащий может участ воват ь в нескольких проект ах, поэт ому возможными ключами являет ся < Em_Number, Pr_Number >и < Em_Nаme, Pr_Number >. Очевидно, чт о, хот я в от ношении Employer_Project_Task1 все связи неключевых ат рибут ов от возможных ключей являют ся минимальными и т ранзит ивные связи от сут ст вуют, эт ому от ношению свойст венны аномалии восст ановления. Например, в случае изменения имени служащего необходимо обновит ь ат рибут Em_Nаme во всех корт ежах от ношения, соот вет ст вующие данному служащему. Иначе будет нарушена связь Em_Number Em_Nаme, и БД окажет ся в несогласованном сост оянии. Причиной отмеченных аномалий является то, что в требованиях 2NF и 3NF не требовалась минимальная функциональная зависимост ь от первичного ключа ат рибут ов, являющихся компонент ами других возможных ключей.проблему решает нормальная форма ист орически принят о называт ь нормальной формой Бойса - Кодда и кот орая являет ся ут очнением 3NF в случае наличия нескольких возможных ключей, перекрывают ся. Переменная отношения находится в нормальной форме Бойса - Кодда (BCNF) в том и только в т ом случае, когда любая выполняемая для эт ого переменного от ношения нет ривиальная и минимально функциональная связь имеет как дет ерминант некот орое возможный ключ данного от ношения. От ношение Employer_Project_Task1 может быт ь приведено к BCNF пут ем одной из двух
43 Тема 7 - Введение в структурированный язык запросов SQL 43 декомпозиций: Employer_Number_Nаme и Employer_Number_Рroject_Task и Employer_Number_Nаme и Employer_Nаme_Project_Task (связи и значения результ ирующих переменных от ношений выглядят аналогично). 6.6 Четвертая нормальная форма и многозначные зависимости Рассмот рим еще одну возможную инт ерпрет ацию переменной от ношения Employer_Project_Task. Предположим, чт о каждый служащий может участ воват ь в нескольких проектах, но в каждом проекте ним должны выполняться те же задачи. Возможное значение переменной от ношения Employer_Project_Task показано на рис.6.5. добавление кортежа - если служащий, который уже участвует в проектах, присоединяется к новому проект у, т о к т елу значения переменной от ношения Employer_Project_Task необходимо добавит ь ст олько корт ежей, сколько задач выполняет эт от служащий. удаление корт ежей - если служащий прекращает участ ие в проект ах, т о от сут ст вует возможность сохранить данные о задачах, которые он может выполнять. модификация корт ежей - при изменении одного из задач служащего необходимо изменит ь значение ат рибут а Em_Task в скольких корт ежах, в скольких проект ах участ вует служащий Рисунок 6.5 Возможно значение переменной от ношения Employer_Project_Task Трудност и, связанные с восст ановлением переменной от ношения Employer_Project_Task, решают ся пут ем его декомпозиции на два сменных от ношение: Employer_Project_Number и Employer_Task . Значения эт их переменных от ношений, соот вет ст вующие значению переменной от ношения Employer_Project_Task показаны на рис Рисунок 6.10 Диаграммы от ношений Employer_Project_Number и Employer_Task Обрат ит е внимание, чт о последний вариант переменной от ношения Employer_Project_Task в BCNF, поскольку все ат рибут ы заголовка от ношения входят в сост ав единст венно возможного ключа. Ранее обсуждены принципы нормализации здесь неприменимы, но мы получили полезную декомпозицию. Дело в т ом, чт о в случае последнего вариант а от ношения мы имеем дело с новым видом зависимост и, впервые выявленным Роном Фейджин в 1971 г. Фейджин назвал зависимост и эт ого вида многозначными (multi - valued dependency - MVD). В от ношении Employer_Project_Task выполняют ся две MVD: Em_Number Pr_Number и Em_Number Em_Task. Первая MVD означает, что каждому значению атрибута Em_Number соот вет ст вует обусловлена т олько эт им значением множест во значений ат рибут а Pr_Number. Аналогично т ракт ует ся вт орая MVD. Например, в от ношении Lecture ат рибут ы Lecturer иbook многозначительно зависят от атрибута Subject (Subject Lecturer, Subject Book). В переменной отношения r с атрибутами A, B, C (в общем случае, составляющими) является многозначная зависимость B от A (AB) в том и только в том случае, когда множество значений атрибута B, соответствует паре значений атрибутов A и C, зависит от значения A и не зависит от значения C. Многозначные зависимости имеют интересное свойство " двойственности ", что демонст рирует следующая лемма Фейджин: В от ношении r < A, B, C>выполняет ся MVD A B в т ом и т олько в т ом случае, когда выполняется MVD A C. Функциональная связь являет ся част ным случаем MVD, когда множест во значений зависимого ат рибут а обязат ельно сост оит из одного элемент а. Таким образом, если выполняется связь A B, то выполняется и MVD A B. Теорема Фейджин. Пуст ь имеет ся переменная от ношения r с ат рибут ами A, B, C (в общем
44 Тема 7 - Введение в структурированный язык запросов SQL 44 случае, составляющими). Отношение r декомпозируется без потерь на проекции < A, B >и < A, C>тогда и только тогда, когда для него выполняется MVD A B C. От ношение находит ся в 4NF, если оно находит ся в 3NF или BCNF и все независимые многозначные функциональные связи разнесены в от дельные от ношения с т ем же ключом. Иными словами, 4NF применяется при наличии в отношении более чем одной MVD и требует, чт обы от ношение не содержало независимых многозначных MVD. Выводы Нормальные формы характ еризуют ся следующими свойст вами: 1NF все атрибуты отношения простые; 2NF отношение находится в 1NF и не содержит частичных зависимостей; 3NF отношения находится в 2NF и не содержит транзитивных зависимостей от ключа; 4NF, применяет ся при наличии более чем одной многозначной зависимост и от ношение находит ся в ВКNF или 3NF и не содержит независимых многозначных функциональных зависимост ей; Вопросы для самоконтроля 1. Дайт е определение функциональной зависимост и и сформулируйт е аксиомы, кот орым такие зависимости отвечают. 2. Когда отношение находится в первой нормальной форме? Опишите алгоритм сведения к ИНФ 3. Определит е неполную функциональную зависимост ь и вт орую нормальную форму. Опишит е алгорит м возведения в 2НФ 4. Что такое третья нормальная форма? Опишите алгоритм возведения в 3НФ. 5. Чем отличается 3НФ от НФБК? 6. Дайт е определение многозначной зависимост и и сформулируйт е аксиомы, кот орым т акие зависимости отвечают. 7. Что такое четвертая нормальная форма? Опишите алгоритм возведения в 4НФ 8. Опишит е процесс проект ирования схемы реляционной базы данных. 9. В чем заключает ся процедура декомпозиции схемы реляционных от ношений? 10. К какой нормальной форме сохраняется эквивалентность отношений за зависимостями и данными? Тема 7 - Введение в структурированный язык запросов SQL 7 СТРУКТУРИРОВАННЫЙ ЯЗЫК ЗАПРОСОВ SQL В данной лекции рассмот рим элемент ы языка SQL (Structured Query Language). Язык SQL ст ал фактически стандартным языком доступа к БД. Все СКБД, которые претендуют на название "реляционные", реализуют т от или другой диалект SQL. Многие из нереляционных сист ем т акже имеют средст ва дост упа к реляционным данным. Целью ст андарт изации являет ся совмест имост ь приложений между разными СКБД. Язык SQL оперирует т ерминами, кот орые немного от личают ся от т ерминов реляционной теории, например, вместо "отношения" используются "таблицы", вместо "кортежей" "строки", вместо "атрибутов" "колонки" или "столбцы". Язык SQL являет ся реляционно полным. Эт о означает, чт о любой операт ор реляционной алгебры может быт ь выражен подходящим операт ором SQL. 7.1 Допустимые типы данных Любой диалект SQL поддерживают три общих типа данных: строчный, числовой и тип для представления даты и времени. Задание типа данных определяет значение и длину данных, а
45 Тема 7 - Введение в структурированный язык запросов SQL 45 т акже формат их предст авления при визуализации. Для всех т ипов данные определены т ак называемые ноль-значения, кот орые указывают на отсутствие данных в колонке указанного типа, то является то обстоятельство, что значение данных в эт от момент времени неизвест ное. Данные срочного т ипа предст авляют собой последоват ельност ь ст рок символов. Сроку дани могут быт ь заданные как с определенной длиной (ключевые слова char или varchar (длина ст роки)), т ак и без указания длины (ключевое слово long varchar) для предст авления ст рок произвольной длины. Числовые т ипы данных предназначены для предст авления целых чисел, чисел с десят ичной точкой и чисел с плавающей точкой. Любое представление чисел задается своей точностью и масшт абом. Точност ь определяет допуст имое предст авление кількост ы значащих цифр числа, а масштаб количество значащих цифр после десятичной точки. Для представления целых чисел используются типы interger (точность 10 значащих цифр) и smallint (т очност ь 5 значащих цифр). Для представления чисел с фиксированной десятичной точкой используются типы number и decimal. Для представления чисел с плавающей точкой в SQL предусмотренные такие типы данных: Double Precision для чисел с точностью от 22 до 53 значащих цифр; Float (точность) для представления чисел с точностью от 1 до 21 значащей цифры; Real для чисел с т очност ью по умолчанию (зависит от конкрет ной реализации). Обычно в конкрет ных диалект ах SQL используют ся т ри т ипа для предст авления т аких данных: datestamp (timestamp) - для предст авления дат ы и времени; date - для представления даты; time - для предст авления времени. Конст ант ы, выражение, сист емные сменные. Конст ант ы обычно определяют единое значение и, согласно т ипу данных, кот орые предст авляют, могут быт ь срочными, числовыми и предст авлят ь дат у/время. Срочные конст ант ы должны быт ь заключены в одинарные кавычки. В SQL сущест вует ряд определенных сист емных сменных, кот орые можно использоват ь в выражениях вмест о имен колонок и конст ант. К т аким перемнным от носят следующие: NULL для предст авления неопределенных значений; ROWID (в Sqlbase) внутренний системный номер строки в таблице; USER имя пользователя, активного в этот момент; SYSDATETIME системное текущее время и дата; SYSDATE системная текущая дата; SYSTIME системное текущее время; SYSTIMEZONE временной пояс, уст ановленный в сист еме. Выражением в SQL являет ся ит ем или комбинация ит емов с допуст имыми для них операциями, кот орая дает единое значение. В качест ве ит емов могут выст упат ь имена колонок, конст ант ы, связанные сменные, результ ат ы вычислений функций, сист емные сменные и другие выражения. При эт ом если один из ит емов имеет нуль-значение, т о результ ат выражения т акже имеет нуль-значение. 7.2 Операторы SQL Типы операт оров Основу языка SQL предст авляют операт оры, условно разбит ые на несколько групп по выполняемым функциям. Можно выделить такие группы операторов (перечислены не все операторы SQL): Операт оры DDL (Data Definition Language) - операт оры определения объект ов БД CREATE SCHEMA - создат ь схему БД; DROP SHEMA - удалить схему БД; CREATE TABLE - создать таблицу; ALTER TABLE - изменить таблицу; DROP TABLE - удалить таблицу; CREATE DOMAIN - создат ь домен; ALTER DOMAIN - изменит ь домен; DROP DOMAIN - удалить домен; CREATE COLLATION - создат ь последоват ельност ь; DROP COLLATION - удалит ь последоват ельност ь; CREATE VIEW - создат ь предст авление; DROP VIEW - удалить представление. Операторы DML (Data Manipulation Language) - операт оры манипулирования данными: SELECT - отобрать строку из таблиц; INSERT - добавить строку в таблицу; UPDATE - изменить строку в таблице;
46 Тема 7 - Введение в структурированный язык запросов SQL 46 DELETE - удалить строку в таблице; COMMIT - зафиксироват ь внесенные изменения; ROLLBACK - от кат ит ь внесенные изменения. Операт оры защит ы и управление данными: CREATE ASSERTION - создат ь ограничение DROP ASSERTION - удалит ь ограничение GRANT - предост авит ь привилегии пользоват елю или приложению на манипулирование объект ами; REVOKE - от менит ь привилегию пользоват еля или приложения. Кроме т ого, являет ся группы операт оров уст ановки парамет ров сеанса, получение информации о БД, операт оры ст ат ического SQL, операт оры динамического SQL. Наиболее важными для пользоват еля являют ся операт оры манипулирования данными (DML) Примеры использования операт оров манипулирования данными INSERT - вставка строк в таблицу: Пример. Вставка одной строки в таблицу: INSERT INTO P (PNUM, PNAME) VALUES (4, "Иванов"); Пример. Вст авка в т аблицу нескольких ст рок, избранных из другой т аблицы (в т аблицу TMP_TABLE вставляются данные о поставщиках из таблицы P, которые имеют номера, большие 2): INSERT INTO TMP_TABLE (PNUM, PNAME) SELECT PNUM, PNAME FROM P WHERE P.PNUM>2 UPDATE - обновление строк в таблице Пример. Обновление нескольких ст рок в т аблице: UPDATE P SET PNAME = "Пушников" WHERE P.PNUM = 1; DELETE - удаление строк из таблицы Пример. Удаление нескольких ст рок в т аблице: DELETE FROM P WHERE P.PNUM = 1; Пример. Удаление всех ст рок в т аблице: DELETE FROM P; Примеры использования операт ора SELECT Операт ор SELECT являет ся факт ически самым важным для пользоват еля и сложнейшим операт ором SQL. Он предназначен для выборки данных из т аблиц, т о являет ся он, чт о свойст венно, и реализует одно из основных назначений БД - предост авлят ь информацию пользоват елю. Операт ор SELECT всегда выполняет ся над некот орыми т аблицами, кот орые входят в БД. На самом деле в БД могут быт ь не т олько пост оянно сохраненные т аблицы, а т акже временные т аблицы и т ак называемые предст авления.предст авление - эт о т от, чт о прост о хранится в БД, Select-Выражение.С точки зрения пользователей представления - это таблица, которая не хранится постоянно в БД, а "возникает" в момент обращения к нее. С точки зрения оператора SELECT и постоянно сохраненные таблицы, и временные таблицы и представления имеют совсем одинаковый вид. Конечно, при реальном выполнении операт ора SELECT сист емой учит ывают ся расхождения между сохраненными т аблицами и предст авлениями, но эт и расхождения скрыт ые от пользоват еля. Результ ат ом выполнения операт ора SELECT всегда являет ся т аблица. Таким образом, по результ ат ам дейст вий операт ор SELECT похожий на операт оры реляционной алгебры. Любой операт ор реляционной алгебры может быт ь выражен определенным чином сформулированным оператором SELECT. Сложность оператора SELECT определяется тем, что он содержит в себе все возможност и реляционной алгебры, а т акже дополнит ельные возможност и, кот орых в реляционной алгебре нет. Выборка данных из одной т аблицы Пример. Выбрат ь все данные из т аблицы пост авщиков (ключевые слова SELECT FROM ): SELECT* FROM P; В результ ат е получим новую т аблицу, кот орая содержит полную копию данных из исходной таблицы P.
47 Тема 7 - Введение в структурированный язык запросов SQL 47 Пример. Выбрат ь все ст роки из т аблицы пост авщиков, кот орые удовлет воряют некот орое условие (ключевое слово WHERE ): SELECT* FROM P WHERE P. PNUM>2; Как условие в разделе WHERE можно использоват ь складне логические выражения, кот орые используют поля т аблиц, конст ант ы, сравнение (>, <, = и т.д.), дужки, союзы AND и OR, возражение NOT. Пример. Выбрат ь некот орые колонки из исходной т аблицы (указание списка колонок, которые отбираются): SELECT P.NAME FROM P; В результ ат е получим т аблицу с одной колонкой, кот орая содержит все наименования пост авщиков. Если в исходной т аблице присут ст вовали несколько пост авщиков с разными номерами, но одинаковыми наименованиями, т о в результ ирующей т аблице будут ст роки с повторениями - дубликаты строк автоматически не откидываются. Пример. Выбрат ь некот орые колонки из исходной т аблицы, удаливши из результ ат а повт оряемые ст роки (ключевое слово DISTINCT): SELECT DISTINCT P.NAME FROM P; Использование ключевого слова DISTINCT приводит к т ому, чт о в результ ирующей т аблице будут изъятые все повторяемые строки. Пример. Использование скалярных выражений и переименований колонок в запросах (ключевое слово AS ): SELECT TOVAR. TNAME, TOVAR.KOL, TOVAR.PRICE, "="AS EQU, TOVAR.KOL*TOVAR.PRICE AS SUMMA FROM TOVAR; В результ ат е получим т аблицу с колонками, кот орых не было в исходной т аблице TOVAR: TNAME KOL PRICE EQU SUMMA Болт = 1000 Рощицы = 4000 Винт = 9000 Пример. Упорядочение результ ат ов запроса (ключевое слово ORDER BY ): SELECT PD. PNUM, PD.DNUM, PD.VOLUME FROM PD ORDER BY DNUM; В результ ат е получим т аблицу, благоуст роенную по полю DNUM: PNUM DNUM VOLUME Пример. Упорядочение результ ат ов запроса за несколькими полями с рост ом или спаданием (ключевые слова ASC, DESC): SELECT PD.PNUM, PD.DNUM, PD.VOLUME FROM PD ORDER BY DNUM ASC, VOLUME DESC; В результате получим таблицу, в которой строки идут в порядке роста значения поля DNUM, а ст роки с одинаковым значением DNUM идут в порядке спаданием значения поля VOLUME: PNUM DNUM VOLUME
48 Тема 7 - Введение в структурированный язык запросов SQL Если явным образом не указанные ключевые слова ASC или DESC, то по умолчанию принимается упорядочения за рост ом (ASC). Выборка данных из нескольких т аблиц Пример. Ест ест венное соединение т аблиц (явное указание условий соединения): SELECT P.PNUM, P.PNAME, PD.DNUM, PD.VOLUME FROM P, PD WHERE P.PNUM = PD.PNUM; В результ ат е получим новую т аблицу, в кот орой ст роки с данными о пост авщиках соединенные со ст роками с данными о пост авках дет алей: PNUM PNAME DNUM VOLUME 1 иванов иванов иванов пет ров пет ров сидоров Таблицы, кот орые соединяют, перечисленные в разделе FROM операт ора, условие соединения приведено в разделе WHERE. Раздел WHERE, кроме условия соединения т аблиц, может т акже содержать и условия отбора строк. Пример. Ест ест венное соединение т аблиц (ключевые слова JOIN USING ): SELECT PNUM, P.PNAME, PD.DNUM, PD.VOLUME FROM P JOIN PD USING PNUM; Ключевое слово USING позволяет явным образом указат ь, по кот орым из общих колонок т аблиц будет производит ься соединения. Пример. Ест ест венное соединение т аблиц ( ключевое слово NATURAL JOIN): SELECT P.PNUM, P.PNAME, PD.DNUM, PD.VOLUME FROM P NATURAL JOIN PD; В разделе FROM не указано, по кот орым полями производит ся соединения. NATURAL JOIN авт омат ически соединяет за всеми одинаковыми полями в т аблицах. Пример. Ест ест венное соединение т рех т аблиц: SELECT P.PNAME, D.DNAME, PD.VOLUME FROM P NATURAL JOIN PD NATURAL JOIN D; В результате получим такую таблицу: PNAME DNAME PNAME иванов болт 100 иванов рощици 200 иванов винт 300 пет ров болт 150 пет ров рощици 250 сидоров винт 1000 Пример. Прямое произведение т аблиц: SELECT P.PNUM, P.PNAME, D.DNUM, D.DNAME FROM P, D; В результате получим такую таблицу: PNUM PNAME DNUM DNAME 1 иванов 1 болт 1 иванов 2 рощици 1 иванов 3 винт 2 пет ров 1 болт 2 пет ров 2 рощици 2 пет ров 3 винт
49 Тема 7 - Введение в структурированный язык запросов SQL 49 3 сидоров 1 болт 3 сидоров 2 рощици 3 сидоров 3 винт Поскольку не указанное условие соединения т аблиц, т о каждая ст рока первой т аблицы соединяет ся с каждым рядышком вт орой т аблицы. Пример. Соединение т аблиц по произвольному условию. Рассмот рим т аблицы пост авщиков и деталей, которыми присвоен некоторый статус: Таблица 7.1 Отношение P (Поставщики) PNUM PNAME PSTATUS 1 иванов 4 2 пет ров 1 3 сидоров 2 Таблица 7.2 Отношение D (Детали) DNUM DNAME DSTATUS 1 болт 3 2 рощици 2 3 вінт 1 От вет на вопрос "какие пост авщики имеют право пост авлят ь какие дет али?", дает т акой запрос: SELECT P.PNUM, P.PNAME, P.PSTATUS, D.DNUM, D.DNAME, D.DSTATUS FROM P, D WHERE P.PSTATUS >= D.DSTATUS; В результате получим такую таблицу: Таблица 7.3 Результаты запроса PNUM PNAME PSTATUS DNUM DNAME DSTATUS 1 иванов 4 1 болт 3 1 иванов 4 2 рощици 2 1 иванов 4 3 винт 1 PNUM PNAME PSTATUS DNUM DNAME DSTATUS 2 пет ров 1 3 болт 1 3 пет ров 2 2 рощици 2 3 сидоров 3 3 винт Вст роенные функции Арифмет ические функции и функции для обработ ки дат ы SQL поддерживает полный набор арифмет ических операций и мат емат ических функций для пост роения арифмет ических выражений над колонками БД (+, -, *, /, ABS, LN, SQRT и т.д.). Если вам необходим список новых служащих, кот орые появились за последний кварт ал в организации, то вы можете написать запрос в таком виде: SELECT ENAME, HIREDATE, HIREDATE + 92 DAYS FROM EMPLOYEE WHERE HIREDATE + 92 DAYS > SYSDATE AND DEPNO=30; Ключевое слово SYSDATE всегда возвращает т екущую дат у. Использование агрегат ных функций в запросах В языке SQL предусмот ренные т акие операт оры агрегат ных функций: AVG(X) = AVG(ALL X) AVG(DISTINCT X) Вычисляет среднее значение аргумент а, кот орый может быт ь выражением любого т ипа. Ноль-значения игнорируют ся, ключевое слово DISTINCT подавляет дубликат ы. COUNT(*) COUNT(X) = COUNT(ALL X) COUNT(DISTINCT X)Вычисляет числа ит емов. При указанию * всегда поворачивает ся число ст рок в т аблице. Указание DISTINCT подавляет дубликат ы. MAX(X) = MAX(ALL X) MAX (DISTINCT X) Вычисляет максимальное значение аргумент а, кот орый может быт ь выражением любого т ипа. Ноль- значения игнорируют ся, ключевое слово DISTINCT подавляет дубликат ы. MIN(X) = MIN(ALL X) MIN (DISTINCT X) Вычисляет минимальное значение аргумент а, кот орый может быт ь выражением любого т ипа. Ноль- значения игнорируют ся, ключевое слово DISTINCT подавляет дубликат ы. SUM(X) = SUM(ALL X) SUM (DISTINCT X) Вычисляет сумму значения аргумент а, кот орый может быт ь выражением любого т ипа. Ноль- 1
50 Тема 7 - Введение в структурированный язык запросов SQL 50 значения игнорируют ся, ключевое слово DISTINCT подавляет дубликат ы.stddev([distinct ALL]X) Вычисляет ст андарт ное от клонение на множест ве значений аргумент а, кот орый может быт ь выражением любого т ипа. Ноль-значения игнорируют ся, ключевое слово DISTINCT подавляет дубликат ы. VARIANCE([DISTINCT ALL]) Вычисляет квадрат дисперсии. Пример. Получит ь общее количест во пост авщиков (ключевое слово COUNT): SELECT COUNT(*) AS N FROM P; В результ ат е получим т аблицу с одним ст олбцом и одним рядышком, чт о содержит количество строк из таблицы P: Пример. Получит ь общую, максимальную, минимальное и среднее количест ва дет алей, кот орые пост авляют ся, (ключевые слова SUM, MAX, MIN, AVG): SELECT SUM(PD.VOLUME) AS SM, MAX(PD.VOLUME) AS MX, MIN(PD.VOLUME) AS MN, AVG(PD.VOLUME) AS AV FROM PD; В результате получим такую таблицу с одной строкой: SM MX MN AV Использование агрегат ных функций с группированием. В одном запросе могут вст рет ит ься как условия отбора строк в разделе WHERE, так и условия отбора групп в разделе HAVING. Условия от бора групп нельзя перенест и из раздела HAVING в раздел WHERE. Аналогично и условия отбора строк нельзя перенести из раздела WHERE в раздел HAVING, за исключением условий, кот орые включают поля из списка группировки GROUP BY. Пример. Для каждой дет али получит ь суммарное количест во, кот орое пост авляет ся (ключевое слово GROUP BY ): SELECT..DNUM, SUM(PD.VOLUME) AS SM GROUP BY PD.DNUM; Эт от запрос будет выполнят ься т аким образом. Сначала ст роки исходной т аблицы будут сгруппированы т ак, чт обы в каждую группу попали ст роки с одинаковыми значениями DNUM. Пот ом внут ри каждой группы будет проссумировано поле VOLUME. От каждой группы к результ ирующей т аблице будет включенная одна ст рока. Пример. Получит ь номера дет алей, суммарное количест во пост авки кот орых превышает 400 (ключевое слово HAVING ): Условие, чт о суммарное количест во пост авки должна быт ь больше 400, не может быт ь сформулированная в разделе WHERE, пот ому чт о в эт ом разделе нельзя использоват ь агрегат ные функции. Условия, кот орые используют агрегат ные функции, должны быт ь размещенные в специальном разделе HAVING: SELECT PD.DNUM, SUM(PD.VOLUME) AS SM GROUP BY PD.DNUM HAVING SUM(PD.VOLUME) > 400; Использование подзапросов Очень удобным средст вом, кот орое позволяет формулироват ь запросы более понят ным образом, являет ся возможност ь использования подзапросов, вложенных в основной запрос. Пример. Получит ь список пост авщиков, ст ат ус кот орых меньше максимального ст ат уса в т аблице пост авщиков (сравнение с подзапросом): SELECT * FROM P WHERE P.STATYS < (SELECT MAX(P.STATUS) FROM P); Поскольку поле P.STATUS сравнивает ся с результ ат ом подзапросу, т о подзапрос должен быт ь сформулирован т ак, чт обы возвращат ь т аблицу, кот орая сост авляет ся ровно с одной строки и одной колонки. Результ ат выполнения запроса будет эквивалент ный результ ат у т акой последоват ельност и дейст вий: 1. Выполнит ь один раз вложенный подзапрос и получит ь максимальное значение ст ат уса. 2. Просканироват ь т аблицу пост авщиков P, каждый раз сравнивая значение ст ат уса поставщика с результатом подзапросу, и отобрать только те строки, в которых статус меньше максимального. Пример. Использование предикат а IN. Получит ь перечень пост авщиков, кот орые пост авляют деталь номер 2: SELECT * FROM P WHERE P.PNUM IN (SELECT DISTINCT PD.PNUM FROM PD WHERE PD.DNUM = 2);
51 Тема 8 - Целостность и безопасность данных 51 В эт ом случае вложенный подзапрос может возвращат ь т аблицу, кот орая содержит несколько ст рок. Результ ат выполнения запроса будет эквивалент ный результ ат у т акой последоват ельност и дейст вий: 1. Выполнит ь один раз вложенный подзапрос и получит ь список номеров пост авщиков, которые поставляют деталь номер Просканироват ь т аблицу пост авщиков P, каждый раз проверяя, удерживает ся ли номер пост авщика в результ ат е подзапроса. Пример. Использование предикат а EXIST. Получит ь перечень пост авщиков, кот орые поставляют деталь номер 2: SELECT * FROM P WHERE EXIST (SELECT * FROM PD WHERE PD.PNUM = P.PNUM AND PD.DNUM = 2); Результ ат выполнения запроса будет эквивалент ный результ ат у т акой последоват ельност и дейст вий: 3. Просканироват ь т аблицу пост авщиков P, каждый раз выполняя подзапрос с новым значением номера пост авщика, взят ым из т аблицы P. 4. В результат запроса включить только те строки из таблицы поставщиков, для которых вложенный подзапрос возврат ил непуст ое множест во ст рок. В от личие от двух предыдущих примеров вложенный подзапрос содержит парамет р (внешняя ссылка), переданный из основного запроса номер пост авщика P.PNUM. Такие подзапросы называют ся коррелированными (correlated). Внешняя ссылка может набират ь разных значений для каждой ст роки-кандидат а, оцениваемого с помощью подзапроса, поэт ому подзапрос должен выполняться сызнова для каждой строки, которая отбирается в основном запросе. Такие подзапросы характ ерные для предикат а EXIST, но могут быт ь использованные и в других подзапросах. Пример. Использование предикат а NOT EXIST. Получит ь перечень пост авщиков, кот орые не поставляют деталь номер 2: SELECT * FROM P WHERE NOT EXIST (SELECT * FROM PD WHERE PD.PNUM = P.PNUM AND PD.DNUM = 2); Также как и в предыдущем примере, здесь использует ся коррелированный подзапрос. От личие сост оит в т ом, чт о в основном запросебудут от обраны т е ст роки из т аблицы пост авщиков, для кот орых вложенный подзапрос не выдаст ни одной ст роки Использование объединения, пересечения и разност и Для выполнения объединения двух запросов используют ся ключевые слова UNION (объединение) т а INTERSECT (пересечение) и EXCEPT (разност ь). Пример. Получит ь имена пост авщиков, кот орые имеют ст ат ус, больший 3, или кот орые пост авляют хот я бы одну дет аль номер 2 (объединение двух подзапросов - ключевое слово UNION): SELECT P.PNAME FROM P WHERE P.STATUS > 3 UNION SELECT P.PNAME FROM P, PD WHERE P.PNUM = PD.PNUM AND PD.DNUM = 2; Результирующие таблицы объединяемых запросов должны быть совместимы, то есть иметь одинаковое количест во ст олбцов и одинаковые т ипы ст олбцов в порядке их перечисления. Не нужно, чт обы объединяемые т аблицы имели одинаковые имена колонок. Эт о от личает операцию объединения запросов в SQL от операции объединения в реляционной алгебре. Наименование колонок в результ ирующем запросе будут авт омат ически взят ы из результ ат а первого запроса в объединении Пример. Получит ь имена пост авщиков, кот орые имеют ст ат ус, больший 3, и одновременно пост авляют хот я бы одну дет аль номер 2 (пересечение двух подзапросов - ключевое слово INTERSECT): SELECT P.PNAME FROM P WHERE P.STATUS > 3 INTERSECTSELECT P.PNAME FROM P, PD WHERE P.PNUM = PD.PNUM AND PD.DNUM = 2; Пример. Получит ь имена пост авщиков, кот орые имеют ст ат ус, больший 3, за исключением
52 Тема 8 - Целостность и безопасность данных 52 тех, кто поставляет хотя бы одну деталь номер 2 (различие двух подзапросов - ключевое слово EXCEPT): SELECT P.PNAME FROM P WHERE P.STATUS > 3 EXCEPT SELECT P.PNAME FROM P, PD WHERE P.PNUM = PD.PNUM AND PD.DNUM = 2; Выводы Язык SQL стал фактически стандартным языком доступа к БД, которая является реляционно полной: любой операт ор реляционной алгебры может быт ь выражен подходящим операт ором SQL Любой диалект SQL поддерживают три общих типа данных: строчный, числовой и тип для предст авления дат ы и времени. Выделяют т ри группы операт оров языки SQL: операт оры определения объект ов БД, операт оры манипулирования данными, операт оры защит ы и управление данными. SQL поддерживает полный набор арифмет ических операций и мат емат ических функций для пост роения арифмет ических выражений над колонками, кот орые используют ся в запросах для получения данных, кот орые непосредст венно не хранят ся в колонках т аблиц БД, но значения кот орых необходимые пользоват елю. Вст роенные функции обработ ки времени и дат ы позволяют выполнят ь запросы даже с операциями вычислениями над данными. Язык SQL являет ся не процедурным, а декларат ивным. Эт о означает, чт о пользоват ель, кот орый формулирует запрос, прост о описывает, кот орым должен быт ь результ ат запроса, а как этот результат будет получен за это отвечает самая СУБД. Примеры, приведенные в лекции, наглядно иллюст рируют использования основных конст рукций запросов к БД. Более дет альную информацию по данной т еме смот рит е в рекомендованной лит ерат уре. Вопросы для самокнтроля 5. Назовит е основные т ипы данных языка SQL? 6. На какие группы разделены операт оры языки SQL? 7. Назовит е основные операт оры группы определения объект ов БД. 8. Назовит е основные операт оры группы манипулирования данными в БД 9. Назовит е основные операт оры группы защит ы и управление данными. 10.Какое ключевое слово позволяет избежат ь дублирования ст рок в результ ирующей таблице? 11.Каким образом можно упорядочит ь записи в результ ирующей т аблице? 12.Как реализоват ь соединение т аблиц? 13.Или можно упорядочит ь данные за несколькими полями? Тема 8 - Целостность и безопасность данных 8 ЦЕЛОСТНОСТЬ И БЕЗОПАСНОСТЬ ДАННЫХ ДАННЫХ 8.1 Целосность данных Понят ие об ограничении целост ност и. Классификация ограничений Термином целостность данных обозначают достоверность и точность информации, которая хранится в базе. Целост ност ь дост игает ся обеспечением соот вет ст вия данных определенным дополнит ельным ограничением, кроме т ех, кот орые накладывают ся схемой базы на ст рукт уру данных и их типы. Ограничение целост ност и эт о правила, кот орые ограничивают все возможные сост ояния базы данных, а т акже переходы с одного ст ана в другого. Таким образом, ограничение целост ност и определяют множест во «допуст имых» ст анов и переходів между ними. База
53 Тема 8 - Целостность и безопасность данных 53 данных находит ся в целост ном ст ане, если она от вечает всем определенным для нее т ребованиям целост ност и. Классификация ограничений целост ност и Ограничение целост ност и классифицируют по: происхождению; образу поддержки; сроку проверки; област и дейст вия; возможност и ограничиват ь переходы базы данных с одного сост ояния в другое. По происхождению ограничения целост ност и разделяют на: ст рукт урные; семант ические. Ст рукт урные ограничения целост ност и эт о ограничения, кот орые выт екают из свойст в структуры данных, которые хранятся в базе. Семант ические ограничения целост ност и эт о ограничения, кот орые накладывают ся предмет ной област ью, кот орая моделирует ся. По способу поддержки выделяют т акие классы ограничений целост ност и: декларат ивные процедурные. Декларат ивные ограничения целост ност и эт о ограничения, кот орые фиксируют условия, которым должен отвечать база данных. Задача СКБД не допускать нарушение этих условий. Обычно декларат ивные ограничения целост ност и определяют ся языком описания ст рукт уры данных. Примером такого ограничения есть: «Фонд зарплаты факультета должен быть равным сумме фондов зарплат ы всех его кафедр». Декларат ивные ограничения целост ност и специфицируют ся фразой CONSTRAINT в описании т аблицы или ее полей. Процедурные ограничения целост ност и эт о описания дейст вий, направленных на обеспечение целост ност и. Примером т акого ограничения ест ь: «Во время изменения фонда зарплаты любой из кафедр автоматически изменить фонд зарплаты факультета так, чтобы он равнялся сумме фондов зарплат ы всех кафедр». Процедурные ограничения целост ност и специфицируют ся т риггерами. По времени проверки ограничения целостности делятся на такие, что: проверяют ся немедленно; имеют от ложенную проверку. Ограничения, кот орые проверяют ся немедленно, проверяют ся непосредст венно в момент выполнения операции, кот орая может нарушит ь целост ност ь. Например, неповт оряемост ь названия факульт ет а проверяет ся во время добавления красной ст роки к т аблице, кот орая содержит информацию о факульт ет ах, или во время замены имени факульт ет а в сущест вующей ст роке т аблицы. Если ограничения возбуждает ся, т о операция блокирует ся. Ограничение целост ност и с от ложенной проверкой используют ся в т ом случае, когда для поддержания базы данных в непрот иворечащем ст ане нужно выполнит ь две или больше операции. Примером ограничения целост ност и, кот орое не может быт ь проверено немедленно, ест ь декларат ивное ограничение от носит ельно фондов заработ ной плат ы факульт ет а и его кафедр. После добавления новой кафедры с заданным фондом финансирования база данных переходит в прот иворечащее сост ояние, поскольку фонд финансированияфакульт ет а становится не равным сумме фондов финансирования его кафедр. Для того чтобы возвратить базу данных в непротиворечащее состояние, нужно выполнить еще одну операцию обновить фонд финансирования факульт ет а. В т аком случае эт и две операции объединяют ся в одну т ранзакцию и ограничение целост ност и проверяет ся после ее завершения. За област ью дейст вия различают ограничение, кот орые касают ся: от ношение; атрибута; связей между от ношениями; связей между ат рибут ами. За возможност ью ограничиват ь переходы базы данных с одного сост ояния в другого ограничения целост ност и делят ся на: ст ат ические; динамические. Ст ат ические ограничения целост ност и накладывают ограничения на возможные сост ояния базы данных. Например, декларат ивные ограничения целост ност и, кот орые описывают ся дальше, являют ся ст ат ическими. Динамические ограничения целост ност и задают ограничение на возможные переходы базы данных с одного сост ояния в другого. Следует отметить, что механизмы защиты данных, о которых будет идти речь далее, также содейст вуют поддержанию целост ност и базы данных. Ограничивая дост уп или
54 Тема 8 - Целостность и безопасность данных 54 манипулирование данными для т ех или других пользоват елей, мы обеспечиваем «недост упност ь» определенных данных. Не все можно описат ь ограничениями целост ност и. Невозможно указат ь и проконт ролироват ь все допуст имые изменения базы данных. Поэт ому, ограничивая дост уп к базы, мы значит ельно снижаем возможност ь неправильного изменения ее состояния. Если той или другому лицу запрещено менять состояние базы данных, а разрешено лишь выбирать данные, то она будет не в состоянии нарушить целостность Декларат ивные ограничения целост ност и Во время рассмот рения декларат ивных ограничений целост ност и возникают т акие вопросы: на какие объект ы модели данных распрост раняют ся ограничения целост ност и; которыми есть эти ограничения; как т е или другие ограничения целост ност и специфицируют ся; кот орые сущест вуют механизмы поддержания целост ност и. В реляционных базах данных к объект ам, на кот орые распрост раняют ся ограничения целост ност и, принадлежат т акие: от ношение; атрибуты; связи между от ношениями; связи между ат рибут ами. В современных СУБД ест ь и много других объект ов базы данных, от носит ельно кот орых специфицируют ся ограничения целост ност и. Рассмот рим, как задают ся ограничения целост ност и для объект ов реляционных СУБД Спецификация будет предст авлена языком PL/SQL, кот орая применяет ся в СУБД Oracle и в кот орой для спецификации ст рукт урных ограничений целост ност и использует ся фраза CONSTRAINT ( сост авная част ь предложений CREATE TABLE и ALTER TABLE) Целост ност ь от ношений В реляционной СКБД целост ност ь от ношений определяет ся по помощи первичного ключа, для кот орого должны выполнят ься т акие ограничения целост ност и: ат рибут ы первичного ключа не могут содержат ь Null-Значений; значение первичного ключа (как от дельного ат рибут а или совокупност и ат рибут ов) не могут дублироват ься в пределах от ношения. целост ност ь по первичному ключу специфицирует ся т ак: CONSTRAINT <имя ограничения> PRIMARY KEY (<перечень полей>)где <перечень полей> поля, кот орые сост авляют первичный ключ Эт а спецификация указывает, какие именно поля являют ся ключевыми. Например: CREATE TABLE КАФЕДРА ( #D NUMBER(2), Название VARCHAR2(9), Заведующий VARCHAR2(10), CONSTRAINT Deppk PRIMARY KEY (#D) ); Для спецификации возможных ключей использует ся фраза UNIQUE. Механизм поддержки целост ност и от ношений реализует СКБД Целостность атрибутов В реляционной СКБД целост ност ь ат рибут ов может обеспечиват ься: указанием т ипов данных и их размеров (обязат ельное свойст во); определением, ест ь ли обязат ельным значение ат рибут а (NULL/NOT NULL); определением, может ли значение ат рибут а дублироват ься (UNIQUE): изменением значения ат рибут а после него введения; заданием условий, кот орым должны от вечат ь значение ат рибут а. Для производных ат рибут ов целост ност ь должна гарант ироват ься процедурой их вычисления.целост ност ь ат рибут ов специфицирует ся фразами NULL/NOT NULL и UNIQUE в определении ат рибут а (поля). Если уникальными должны быть значение не отдельных полей, а совокупности полей, то это указывается так: CONSTRAINT <имя ограничения> UNIQUE (<перечень полей>) Целост ност ь ат рибут ов специфицирует ся т акже указанием ограничения CONSTRAINT <и м'я ограничение> CHECK (<условие>) Условие определяется на атрибутах отношения. Фраза CHECK может также указываться в определении ат рибут а. Рассмот рим пример спецификации целост ност и ат рибут ов: CREATE TABLE ГРУПА ( #GNUMBER(3), #D NUMBER(3). Курс NUMBER(l) CHECK (Course IN( )). Номер NUMBER(3) CHECK (Номер > 0). Количест во NUMBER(2J CHECK (Количест во > 0).
55 Тема 8 - Целостность и безопасность данных 55 #курат ор NUMBER(3) UNIQUE. CONSTRAINT Grppk PRIMARY KEY (#G). CONSTRAINT Grpunq UNIQUE (Курс. Номер)) Замет им, чт о когда UNIQUE указывает ся для группы ат рибут ов, т о речь идет об уникальности именно группы атрибутов, каждый из них отдельно не обязательно должны быть уникальным. С помощью фразы UNIQUE специфицируют ся т акже возможные ключи т аблицы, т огда она должна использоват ься вмест е с ограничением NOT NULL. Механизм поддержки целост ност и ат рибут ов реализует СУБД Целост ност ь связей между от ношениями Целост ност ь связей между от ношениями определяет ся внешними ключами. Во время спецификации внешнего ключа указывает ся соот вет ст вующий ему первичный ключ другого от ношения. Такой первичный ключ называет ся референційним. От ношение, на кот орое осущест вляет ся ссылки с помощью внешнего ключа, называет ся родительским, а то, которое ссылается, дочерним Если внешний ключ определенного от ношения может содержат ь Null- Значение, эт о означает, чт о связь данного от ношения с другим ест ь факульт ат ивным. NOT NULLспецификация ст олбцов внешнего ключа свидет ельст вует, чт о связь ест ь обязат ельной Определение внешнего ключа свидет ельст вует о наличии ссылочной целост ност и: значение внешнего ключа должны ссылат ься на значение первичного ключа другого от ношения. То ест ь сит уация, когда внешний ключ имеет значение, от сут ст вующее среди значений соот вет ст вующего первичного ключа, рассмат ривает ся как сит уация, кот орая возбуждает ся целост ност ь за ссылкой. Целостность за ссылкой в Oracle специфицируется так: CONSTRAINT <название ограничения> FOREIGN KEY («перечень полей 1>) REFERENCES <имя т аблицы>(<перечень полей 2>) [ON DELETE ] где «перечень полей 1> поля, которые представляют внешний ключ, <имя таблицы> имя т аблицы референційного ключа, <перечень поле в 2> поля, из кот орых сост авляет ся референційний ключ. В Oracle допускает ся, чт обы «перечень полей 2> был не первичным ключом, а списком произвольных полей, кот орые имеют спецификацию UNIQUE. Механизм поддержки ссылочной целосност и реализует СУБД. Рассмот рим, как дейст вует механизм во время удаления ст роки из родит ельской т аблицы. Возможные т ри вариант а: строка родительской таблицы может быть удаленный лишь в том случае, если нет внешних ключей, кот орые ссылают ся на значение референциального ключа эт ой ст роки; во время удаления строки родительской таблицы удаляются также все строки в других т аблицах, значение внешних ключей кот орых ссылают ся на значение референциального ключа эт ой ст роки (каскадное удаление); во время удаления ст роки родит ельской т аблицы все ссылки на значение удаленного референциального ключа заменяют на NULL. Отсутствие фразы [ON DELETE ] указывает на первый вариант. Фраза ON DELETE CASCADE в спецификации референциальной целост ност и указывает на вт орой вариант, a ON DELETE SET NULL - на третий Целост ност ь связей между ат рибут ами Целостность связей между атрибутами определяется условием, которому должна отвечать совокупност ь ат рибут ов одного или нескольких от ношений. Такие условия специфицируют ся т риггерами. Например, чт обы указат ь, чт о количест во ст удент ов на лекции не может превышать количество мест в аудитории, нужно назначить такой триггер: CREATE TRIGGER Лекция Вст авка Обновления BEFORE INSERT, UPDATE ON ЛЕКЦИЯ WHEN (SELECT Места FROM АУДИТОРИЯ WHERE АУДИТОРИЯ.#R =ЛЕКЦИЯ.#R) < (SELECT Количество FROM ГРУПА WHERE ГРУПА.#Є = ЛЕКЦИЯ.#Є) BEGIN ROLLBACK TRANSACTION END Динамические ограничения целост ност и Динамические ограничения целост ност и эт о ограничения, кот орые усост ояниявливают зависимость между разными частями базы данных в разные моменты времени. Выделяют такие разновидност и динамических ограничений: сит уационно- ориент ированные; операційно ориент ированные Сит уационно-ориент ированные ограничения целост ност и
56 Тема 8 - Целостность и безопасность данных 56 Сит уационно - ориент ированные ограничения задают ся в виде т ребований, кот орым должны от вечат ь последоват ельные сост ояния базы данных, т о ест ь благодаря т аким ограничениям фиксируют ся допуст имые переходы базы данных с одного сост ояния в другого. Пример возможных переходів значения ат рибут а Семейное положение можно увидет ь на рис Рисунок Возможные переходы значения ат рибут а «Семейное положение» Для спецификации сит уационно-ориент ированных ограничений применяют ся т е же самые средст ва, чт о и для спецификации ст рукт урных ограничений. Кроме т ого, использует ся возможност ь ссылат ься на значение базы данных к ее обновлению и после. Эт о дост игает ся с помощью ут очняющих фраз ОLD и NEW, чт о уживают ся в ссылках на значение, кот орые хранились в базе данных к и после изменения ее сост ояния. Обычно для описания динамических ограничений используют ся т риггеры, кот орые инициируют ся во время изменения сост ояния базы данных командами INSERT, UPDATE и DELETE. Например, допуст имые переходы ат рибут а Семейное_положение могут быт ь специфицированы в виде такого триггера: CREATE TRIGGER Лицо_Семейное_положение BEFORE INSERT. UPDATE ON ЛИЦО WHEN (OLD. Семейное_положение = 'Неженат ый' AND NEW. Семейное_положение IN ('Разведенный'. 'Вдовец') ) OR (OLD. Семейное_положение =' Женат ый' AND NEW. Семейное_положение = 'Неженат ый') OR (OLD. Семейное_положение ='Разведен' AND NEW. Семейное_положение IN ('Неженат ый'.'вдовец') ) ОR (OLD. Семейное_положение ='Вдовец' AND NEW. Семейное_положение IN ('Неженат ый'.'разведенный') BEGIN ROLLBACK TRANSACTION END Эт о ограничения можно специфицироват ь в определении т аблицы ЛИЦО при условии, кот орое допускает ся использования квалификат оров NEW и 0LD: CONSTRAINT Семейный_состояние СНЕСК (OLD.Семейный_сост ояние='неженат ый' AND NEW.Ciмeйний_cт aн=' Женат ый') ОR (OLD.Семейный_сост ояние=' Женат ый' AND NEW.Ciмeйний_cт aн = IN ('Разведенный'.'Вдовец') ) ОR (OLD.Семейный_сост ояние='разведен' AND NEW.Ciмeйний_cтaн = ' Женатый') OR (OLD.Семейный_сост ояние = 'Вдовец' AND NEW.Ciмeйний_cт aн = ' Женат ый') Замет им, чт о новое сост ояние базы данных может зависет ь не т олько от предыдущего сост ояния, но и от цепочки предыдущих сост ояний. Например, в учебном заведении может дейст воват ь т акое правило: «На должност ь профессора можно принимат ь т олько т ех, кт о работ ал в учебном заведении на должност ях преподават еля, ст аршего преподават еля и доцент а». Как правило, СУБД не предост авляют возможност и сохранят ь предыст орию состояний. Если такое ограничение формулируется, то нужно спроектировать базу данных так, чтобы множество состояний атрибутов хранилось в специальных отношениях. В частности для приведенного выше примера дост ат очно будет вмест о ат рибут а Должност ь в от ношении ПРЕПОДАВАТЕЛЬ(#Т #D, Название, Должност ь, Тел) ввест и новое от ношение ПРЕПОДАВАТЕЛЬ_ДОЛЖНОСТЬ(#Т, Должност ь, Дат а), в кот ором будут хранит ься все
57 Тема 8 - Целостность и безопасность данных 57 должност и, на кот орых преподават ель работ ал раньше Операционно-ориент ированные ограничения целост ност и Операционно-ориент ированные ограничения целост ност и задают ся в виде допуст имых последоват ельност ей операций. Допуст имост ь операции или последоват ельност и операций может зависет ь от т екущего сост ояния базы данных. Приведем пример операционноориент ированного ограничения целост ност и: «Добавление в базу данных информации о т ом, что х является мужчиной в допустимое лишь в том случае, когда и х, и у в данный момент не являют ся женат ыми». Обычно подобные ограничения реализуют ся с помощью определения т риггеров для соот вет ст вующих операций манипулирования т аблицами. Например, если ест ь от ношения СУПРУГ (Мужчина, Жена) и ЛИЦО(Фамилия, Семейное положение), т о описанное высшее ограничение можно специфицироват ь т ак: CREATE TRIGGER Супруги_Проверка BEFORE INSERT ОN СУПРУГИ WHEN (СУПРУГИ. Мужчина=ЛИЦО.Фамилия AND ЛИЦО.Семейное_положение = ' Женат ый') AND NEW (СУПРУГИ.Женщина = ЛИЦО.Фамилия AND ЛИЦО. Семейное_положение = Замужем ) BEGIN ROLLBACK TRANSACTION END Семант ические ограничения целост ност и Семант ические ограничения целост ност и, или прикладные правила целост ност и, эт о правила, кот орые характ еризуют ограничение, кот орые дейст вуют в предмет ной област и. Примерами семант ических ограничений могут быт ь: описанное выше правило изменения сост ояния ат рибут а Семейное положение; «письмо, кот орое пост упило, полагает обработ анным, когда с ним ознакомленные все заинтересованные лица и относительно него принятое соответствующее решение»: «размер должност ных окладов должны варьироват ься в пределах от 3000 до 5000 грн.»; «ст удент может перейт и на следующий курс или ост ат ься на т ом самому, но не на предыдущему»; «одна и та же лицо не может быть заведующим двух кафедр». Для спецификации семант ических ограничений используют фразу C0NSTRAINT и т риггеры. В некот орых случаях для поддержки семант ических ограничений целост ност и пишут ся специальные процедуры, кот орые хранят ся в СУБД, или специальные процедуры, кот орые входят в сост ав внешнего применения Поддержка целост ност и в случае возникновения перебоев Напомним, что целостность базы данных это ее соответствие моделированной предметной област и в любой момент времени. Механизмы описания ограничений целост ност и обеспечивают поддержку целост ност и с «логической» т очки зрения. Однако перебои в программном или аппарат ном обеспечении т акже могут привест и к нарушению целост ност и (а в некот орых случаях к полному разрушению базы данных). Для обеспечения целост ност и базы данных на эт от случай предлагают ся т акие механизмы: периодическое создание резервной копии базы данных; ведение журнала всех изменений сост ояния базы данных. Общая схема поддержки целост ност и на случай перебоев являет ся т акой. В определенный момент времени создает ся резервная копия базы данных. Начиная с эт ого момент а в журнале фиксируют ся все изменения, кот орые выполняют ся в базе. Если в какой-либо момент времени база данных оказывает ся наст олько испорченной, чт о ее невозможно воссост ояниеовит ь, т о берет ся резервная копия и к нее применяют ся все зафиксированные в журнале операции. Таким образом резервная копия сост ояниеовит ся акт уальной. 8.2 ЗАЩИТА ДАННЫХ Безопасност ь данных Данные в сист емах баз данных должны хранит ься с гарант ированием конфиденциальност и и безопасност и. Информация не может быт ь ут ерянной или похищенной. Под безопасност ью данных в базе понимают защит у данных от случайного или спланированного дост упа к ним лиц, кот орые не имеют на эт о права, от несанкционированного раскрыт ия, изменения или удаление. Безопасност ь данных поддерживает ся комплексом мер и средст в. Организационно-мет одические меры предусмат ривают разработ ку инст рукций и правил, кот орые регламент ируют дост уп к данным и их использование, а т акже создание соот вет ст вующих служб и подразделов, кот орые следят за соблюдением эт их правил. Правовая и юридическая меры предусмат ривают юридическое упрочение прав и обязанност ей от носит ельно хранения, использование и передача в элект ронном виде данных, кот орые подлежат защит е, на уровне государст венных законов и других нормат ивных документ ов. Технические средства защиты это комплекс технических средств, которые содействуют решению проблемы защит ы данных. Программные средст ва защит ы эт о комплекс
58 Тема 8 - Целостность и безопасность данных 58 мат емат ических, алгорит мических и программных средст в, шо содейст вуют решению проблемы защит ы данных. Дальше будет идт и лишь о программных средст вах защит ы. Сист ема защит ы эт о совокупност ь мер, кот орые уживают ся в сист еме баз данных для гарант ирования необходимого уровня безопасност и. В современных СУБД поддерживает ся один из двух наиболее распрост раненных мет одов обеспечения защит ы данных: выборочный или обязат ельный. Выборочный мет од защит ы предусмат ривает, чт о пользоват ели имеют разные права (привилегии, полномочие) дост упа к разным или одних т ех самых объект ов базы данных. Обязат ельный мет од защит ы предусмат ривает, чт о каждому объект у базы данных предост авляет ся определенный уровень секрет ност и, а каждому пользоват елю определенный уровень допуска. Дост уп к объект у данных ест ь лишь у т ех пользоват елей, кот орые имеют соот вет ст вующий для эт их данных уровень допуска Замет им, чт о выборочный мет од гнучкіший, чем обязат ельный. Безопасност ь данных может гарант ироват ься т акими механизмами. Регист рация пользоват елей. Любой пользоват ель для получения дост упа к базы данных должны быт ь зарегист рирован в сист еме под определенным именем и определенным паролем. Управление правами дост упа. Админист рат ор может определит ь, каким пользоват елям к каким данным разрешает ся дост уп и какие именнооперации над эт ими данными (выбирание, введение, изменение или удаление) он может выполнят ь. Идент ификация и подт верждения аут ент ичност и всех пользоват елей или приложений, кот орые получают дост уп к базы данных. Любой пользоват ель или приложение, обращаясь к сист емы баз данных, должны указат ь свое имя и пароль Имени идент ифицирует пользоват еля, а пароль подт верждает аут ент ичност ь имени. Эт и два шага идент ификация и подт верждения аут ент ичност и выполняют ся лишь один раз во время соединения с базой данных и остаются действующими к завершению сеанса работы с базой данных конкретного пользоват еля или применения. Автоматическое ведение журналов доступа к данным. В этих журналах протоколируются операции, выполненные над данными пользоват елями, с целью дальнейшего анализа на случай получения доступа к базы в обход системы защиты. Шифрование данных на внешних носит елях. Осущест вляет ся крипт ографическими мет одами на случай несанкционированного копирования данных из внешних носит елей. Припускает ся, чт о админист рат ор базы данных имеет все необходимые полномочия на выполнение функций, связанных с защит ой данных. Доверит ельное и админист рат ивное управление дост упом Доверительное управление доступом к данным это такой тип управления, когда система защит ы дает возможност ь обычным пользоват елям не т олько получат ь дост уп к определенным данным, но и передават ь полномочия на дост уп к ним другим пользоват елям без админист рат ивного вмешат ельст ва. Админист рат ивное управление дост упом к данным эт о т акое управление, за кот орого сист ема защит ы дает возможност ь передават ь полномочия на дост уп к данным лишь специально авт оризованному пользоват елю (админист рат ору) Регист рация пользоват елей Любой пользователь для получения доступа к базы данных должны быть зарегистрирован в сист еме под определенным именем и паролем. Регист рация необходимая для т ого, чт обы знать, с кем имеет дело система в каждый момент времени. Заметим, что под пользователем понимает ся не т олько физическое лицо, но и любой ист очник, кот орый в возможност и обрат ит ься к базы данных (прикладная программа, операционная сист ема, инт ернетприложение и т.п.). Упрощенный вид конст рукции, кот орая применяет ся для определения пользоват еля, ест ь таким: CREATE USER <пользоват ель> UDENTIFIED <пароль> Здесь <пользоват ель> имя пользоват еля, а <пароль> пароль. Сначала пользователь не имеет никаких полномочий. Чтобы пользователь мог выполнять те или другие операции над базой данных, ему необходимо передат ь соот вет ст вующие полномочия Управление правами дост упа Определит ь права дост упа пользоват елей эт о означает зафиксироват ь информацию от носит ельно: лиц, кот орым предост авляют ся права дост упа; условий предост авления прав дост упа; объекта, на которые распространяются права доступа; операций, от носит ельно кот орых специфицируют ся права дост упа;
59 Тема 8 - Целостность и безопасность данных 59 возможности передачи прав доступа другим лицам Кому предост авляют ся права дост упа Права дост упа предост авляют ся всем, кт о обращает ся к базы данных. Эт о могут быт ь пользоват ели, прикладные программы, операционные сист емы и т.п. Каждый, кт о обращает ся к базы данных, должны вначале указат ь свое имя и пароль. Для СУБД не важно, кт о именно обращается к базы данных, главное, чтобы все, кто хочет получить возможность работать с ней, были заранее зарегист рированы в сист еме В некот орых случаях может понадобит ься выделит ь пользоват елей сист емы, кот орые имеют одинаковые полномочия. Например, все сотрудники отдела кадров могут иметь одни и те же права, а сот рудники планового от дела другие, причем т акже одинаковые. Для реализации т акого распределения прав вводит ся понят ия роли. Роль эт о совокупност ь полномочий, кот орые могут передават ься пользоват елям или другим ролям. Можно присвоит ь полномочие ролям, а со временем приписыват ь роли пользоват елям. Когда пользоват елю присвоенная роль, он имеет т е полномочия, кот орые приписаны роли. Роль имеет все полномочия, кот орые присвоены ей явным образом, и все полномочия, кот орые переданы ей другими ролями. Упрощенный синт аксис определения роли ест ь т аким: CREATE ROLE <роль> IDENTIFIED <пароль> Здесь <роль> имя роли. Сначала роль есть пустой, то есть не имеет никакого полномочия Условия предост авления прав дост упа Иногда целесообразно специфицироват ь дополнит ельные условия, за соблюдения кот орых пользоват елям предост авляют ся определенные права дост упа. Речь идет об условиях, которые не определяются другими составными прав доступа (кому предоставляется доступ, к кот орым данным, кот орые операции разрешают ся). Примеры дополнит ельных условий: временные характ ерист ики (например, «права дост упа дейст вуют лишь между 16 и 17 часами первого понедельника каждого месяца»): локализация компьют еров в локальной сет и (например, «права дост упа дейст вуют лишь для компьют еров, усост ояниеовленных в плановом от деле») В большинст ве СУБД нет средст в явного описания дополнит ельных условий, кот орые ограничивают права дост упа. За необходимост и т акие условия могут быт ь специфицированы в прикладных системах Объекты, на которые распространяются права доступа Обычно в контексте прав доступа различают объекты двух классов: системные и объекты базы данных. К сист емным объект ам принадлежат: база данных, класт еры, т риггеры, т ранзакции и т.п. К объект ам базы данных принадлежат т аблице, вирт уальные т аблицы и процедуры. Кроме того, в таблицах и виртуальных таблицах могут дополнительно указываться ст олбцы, от носит ельно кот орых специфицируют ся права дост упа. В некот орых случаях возникает необходимост ь специфицироват ь ст роки определенной таблицы, которые касаются лица, для которого определяются права доступа. Например: любой пользоват ель может менят ь в от ношении СЛУЖАЩИЙ значения полей лишь т ого строки, которая касается его самого ( то есть он может менять лишь свои личные лани), за исключением величины его зарплат ы; в от ношении СЛУЖАЩИЙ менят ь зарплат у может лишь т от пользоват ель, кот орый являет ся начальником от дела данного служащего. В рассмот ренной сит уации возникает необходимост ь ссылат ься на т екущего пользоват еля в условии выбирания записей из вирт уальной т аблицы. Для эт ого в некот орых СУБД предост авляет ся возможност ь использоват ь специальную консост ояниет у, кот орая идент ифицирует т екущего пользоват еля (т о ест ь пользоват еля, кот орый инициирует выполнение соот вет ст вующего запроса на выбирание или обновление данных) Операции, от носит ельно кот орых специфицируют ся права дост упа К операциям, от носит ельно кот орых специфицируют ся права дост упа, принадлежат ст андарт ные операции по манипулированию объект ами базы данных, а именно: определение, переопределение и удаление т аблицы или вирт уальной т аблицы; выборка, добавление, удаление, обновление ст рок в т аблице или вирт уальной т аблице: выполнение сохраненных процедур. В каждой конкрет ной СУБД приведенный список операций над объект ами базы данных может расширят ься Возможност ь передачи прав дост упа другим лицам Иногда пользоват елю предост авляют ся не т олько права на манипулирование т еми или другими объектами базы данных, но и возможность передавать эти права другим. Например, пользователю передается право создать таблицу, вводить у нее данные, менять и удалять их, даже удалить всю таблицу. Он состояниеовится полноправным владельцем таблицы и может с
60 Тема 8 - Целостность и безопасность данных 60 ней делат ь чт о угодно. Поэт ому не удивит ельно, чт о ему предост авляют разрешение на передачу любых прав на эту таблицу другим пользователям Спецификация полномочий в СУБД Oracle Рассмот рим, как определяют права дост упа к данным в СУБД Oracle. Только чт о созданный пользоват ель не имеет никаких полномочий. Предост авления полномочий пользоват елю осущест вляет ся командой GRANT. Передача полномочий пользоват елям или ролям Команда GRANT дает возможност ь передат ь полномочие пользоват елям или ролям. Упрощенный синт аксис команды ест ь т аким: GRANT < <операция> ALL>[(<список ст олбцов>)] ON <список объект ов> ТО WITH GRANT OPTION Спецификат ор <операция> указывает, от носит ельно кот орых операций описывает ся полномочия. Такими операциями могут быт ь: SELECT, INSERT, UPDATE, DELETE и прочие. Фраза ALL указывает, чт о полномочия передают ся от носит ельно всех операций. В списке объект ов от мечают ся все объект ы базы данных, от носит ельно кот орых специфицируют ся полномочия. Эт от список включает ссылку на т аблице и вирт уальные таблицы. С помощью параметра <список столбцы в> можно дополнительно указать столбцы таблиц. Полномочие может быт ь передано пользоват елю, роле или всем, кт о указывает ся в фразе ТО. Если полномочия передает ся пользоват елю, он получает право выполнят ь операции согласно эт ому полномочию. Когда полномочие передает ся роли, она им пополняет ся. Фраза WITH GRANT OPTION означает, чт о получат ель полномочия получает т акже право передават ь эт о полномочие другому пользоват елю или роли Рассмот рим несколько примеров предост авления и передача прав дост упа: Предост авит ь пользоват елю на имя Джона права на выполнение любых операций над т аблицей ФАКУЛЬТЕТ и разрешение на передачу эт их прав другим пользоват елям. GRANT ALL ON ФАКУЛЬТЕТ ТО Джон WITH GRANT OPTION Предост авит ь всем пользоват елям право просмат риват ь данные из т аблицы Лекция. GRANT SELECT ON ЛЕКЦИЯ ТО PUBLIC Предоставить пользователю на имя Джона право менять столбец фонд в таблице КАФЕДРА. GRANT UPDATE (Фонд) ON КАФЕДРА ТО Джон Обязательные методы защиты Обязат ельные мет оды защит ы, или мет оды обязат ельного управления дост упом применяют ся к базам, в кот орых данные имеют ст ат ическую или жест кую ст рукт уру, характ ерную, например, для правит ельст венных или военных организаций. Как уже подчеркивалось, основная идея заключает ся в т ом, чт о каждый объект данных имеет определенный уровень секрет ност и, а каждый пользоват ель определенный уровень дост упа. Предполагает ся, чт о эт и уровне образовывают ст рогий иерархический порядок (например, целиком т айно, т айно, для служебного пользования и т.п.). В последнее время мет оды обязат ельного управления дост упом приобрели популярност ь в США, поскольку согласно т ребованиям минист ерст ва обороны эт ой ст раны т акой мет од управления доступом должны поддерживаться в любой системе, которая используется в этом ведомст ве.поэт ому разработ чикам и пост авщикам СУБД пришлось прибавит ь многому усилий для разработ ки подобных мет одов управления дост упом. Требования к т акое управление предст авлено в двух важных публикациях минист ерст ва, кот орые неформально называют ся «оранжевой» и «розовой» книгами (Orange Book и Lavender Book). В «оранжевой» книге приведен перечень т ребований к безопасност и определенного «надежного вычислит ельного среды», а в «розовой» книге эт и т ребования инт ерпрет ируют ся от носит ельно сист ем управления базами данных Ведение журналов дост упа Не бывает неуязвимых сист ем защит ы. Назойливый злоумышленник всегда может найт и образ преодолет ь все сист емы конт роля и защит ы. Поэт ому во время работ ы по очень важными данными необходимо регист рироват ь в соот вет ст вующем журнале все событ ия, кот орые касают ся функционирования сист емы защит ы. В связи с эт им сист ема защит ы должны предост авлят ь возможност ь выполнят ь приведенные далее дейст вия. Регист рироват ь все попыт ки получения дост упа к сист емы баз данных, в т ом числе и безуспешные. Эт а регист рация должна быт ь максимально полного ( должны регист рироват ься сведения о том, кто получал доступ или старался его получить, из какого терминала или узла сети, в которому часу и т.п.). Регист рироват ь дейст вия пользоват елей из использования всех ресурсов сист емы, в частности и данных, а также другие действия и события, которые могут повлиять на защиту данных. Предост авлят ь пользоват елям, кот орые имеют админист рат ивные полномочия,
61 Раздел 3 - Общие сведения о других видах баз данных и баз знаний 61 возможност ь просмат риват ь и анализироват ь результ ат ы регист рации, выявлят ь опасные сит уации, усост ояниявливат ь причины их возникновения и находит ь пользоват елей, от вет ст венных за нарушения полит ики безопасност и. Даже самая лишь констатация факта, который в системе поддерживается регистрация всех дейст вий пользоват елей, в некот орых случаях имеет сущест венное значение для предот вращения несанкционированного проникновения в сист ему Обход системы защиты К носит елям, на кот орые записанные данные, можно получит ь дост уп в обход сист емы защиты. Если получить доступ к файлам операционной системы, которые содержат данные с базы, т о можно прочит ат ь содержимое эт их файлов, поскольку фирмы-разработ чики подавляющего большинст ва СУБД создают формат ы хранения данных т акими, чт о они являют ся дост упными широкому кругу пользоват елей и применений. Более т ого, т от, кт о получил дост уп к файлам базы, может изменит ь их содержимое или даже удалит ь их. Наиболее эффект ивными средст вами борьбы с т акой угрозой являет ся использования методов криптографии, то есть шифрование информации. Когда данные записанные в базе в зашифрованном виде, т огда т от, кт о получил дост уп к ним в обход сист емы защит ы, ст алкивает ся с проблемой дешифровки. В идеальном случае мет од шифрования должны быт ь т аким, чт обы зат рат ы на дешифровку превышали выигрыш от владения информацией или чт обы время дешифровки превышало час. на прот яжении какого данные рассмат ривают ся как секрет ные. В сист емах распределенных баз данных, когда информация пересылает ся каналами связи, опасными ест ь разные формы перехват а данных, кот орые передают ся. Единой конт рмерой, кот орая дает змоіу предот врат ит ь подобный перехват ы, ест ь шифрования данных перед их передачей каналами связи. Выводы Главными аспект ами проект ирования и функционирование базы данных являет ся обеспечение целост ност и и безопасност и данных. Под целост ност ью понимает ся дост оверност ь данных в любой момент времени, под безопасност ью защит а от несанкционированного дост упа. Целост ност ь данных обеспечивает ся ограничениями целост ност и, безопасност ь распределением прав дост упа между группами пользоват елей данными. Ограничение целост ност и дейст вуют на т акие основные объект ы базы данных, как отношение, атрибуты, связи между отношениями и между атрибутами. Механизмы поддержки целост ност и от ношений реализует СУБД. Особым аспект ом функционирования базы данных являет ся поддержка целост ност и в случае возникновения перебоев, для чего используют ся т акие механизмы, как периодическое создание резервной копии базы данных и ведение журнала всех изменений сост ояния базы данных. Безопасност ь данных поддерживает ся целым комплексом мер и средст в: организационномет одические и юридические меры, т ехнические и программные средст ва защит ы. В современных СУБД поддерживает ся один из двух наиболее распрост раненных мет одов обеспечения защит ы данных: выборочный или обязат ельный. Нужно акцент ироват ь внимание на двух т ипах управления дост упом к данным, кот орые от личают ся друг от друга возможност ью передават ь полномочия на дост уп к данным: доверит ельное и админист рат ивное управления дост упом к данным Определит ь права дост упа пользоват елей эт о значит зафиксироват ь информацию от носит ельно: лиц, кот орым предост авляют ся права дост упа; условий предост авления прав дост упа; объекта, на которые распространяются права доступа; операций, от носит ельно кот орых специфікуют ься права дост упа; возможност и передачи прав дост упа другим лицам. Вопросы для самоконтроля 1. Что такое целостность данных? 2. Какими средст вами можно обеспечит ь целост ност ь данных? 3. По каким показат елями классифицируют ограничение целост ност и? 4. С помощью кот орых средст в поддерживает ся безопасност ь данных? 5. Чем от личает ся доверит ельное управление дост упом от админист рат ивного? 6. Как специфицируют ся полномочия в Огасlе? 7. В чем состоит идея обязательных методов защиты? 8. Каким образом ведение журналов дост упа может повысит ь безопасност ь данных? 9. Как защитить данные, доступ к которым возможен вне системы защиты СУБД? Рекомендованная литература 1 К. Дж. Кейт Введение в системы баз данных Перьев. с англ. 8-е изд. М.: Издательский дом «Вильямс», С.
62 Раздел 3 - Общие сведения о других видах баз данных и баз знаний 62 2 Пушников А.Ю. Введение в сист емы управления базами данных. Част ь 1. Реляционная модель данных: Учебное пособие/ Изд-Е Башкирского ун- та. - Уфа, с. 3 Томас Коннолли, Каролин Бегг. Базы данных. Проект ирование, реализация и сопровождение. Теория и практ ика.- 3-е изд. М.: Издат ельский дом «Вильямс», 2003, 1436 с. 4 Джен Л. Харрингтон Проектирование реляционных баз данных М.: Издательство «Лори», с. 5 Пасечник В.В.Организация баз данных и знаний: учебник для ВНЗ/ В.В. Пасечник, В.А. Резніченко.- К.: Издат ельская группа BHV, с. 6 В.Е. Туманов. Основы проект ирования реляционных баз данных 7 Д.В. Кознов. Визуальное моделирование: т еория и практ ика 1. К. Дж. Кейт Введення в системи баз даних Пер. с англ. 8-е изд. М.: Издательский дом «Вильямс», С. 2. Томас Коннолли, Каролин Бегг. Базы данных. Проект ирование, реализация и сопровождение. Теория и практ ика. 3-е изд. М.: Издат ельский дом «Вильямс», 2003, 1436 с. 3. Джен Л. Харрингт он Проект ирование реляционных баз данных М.: Издат ельст во «Лори», с. 4. Пасічник В.В.Організація баз даних т а знань: підручник для ВНЗ/ В.В. Пасічник, В.А. Резніченко. К.: Видавнича група BHV, с. 5. В.Е. Туманов. Основы проект ирования реляционных баз данных 6. Д.В. Кознов. Визуальное моделирование: т еория и практ ика 7. Пушников А.Ю. Введение в сист емы управления базами данных. Част ь 2. Нормальные формы от ношений и т ранзакции: Учебное пособие/изд-е Башкирского ун-т а. - Уфа, с 8. Март ин Грубер. Понимание SQL. /Пер. Лебедева В.Н. М., с. 9. В.В. Кириллов, Г.Ю. Громов. Учебное пособие по SQL: Ст рукт урированный язык запросов (SQL) Раздел 3 - Общие сведения о других видах баз данных и баз знаний Тема 9 - Распределенные базы данных 9 РАСПРЕДЕЛЕННЫЕ БАЗЫ ДАННЫХ
63 Раздел 3 - Общие сведения о других видах баз данных и баз знаний Основные определения Распределенная база данных (РБД) эт о множест во логически взаимозависимых баз данных, распределенных в компьют ерной сет и. Распределенная сист ема управления базами данных (РСУБД) эт о программное обеспечение, кот орое руководит РБД и предост авляет т акие механизмы дост упа к ним, чт о их применение дает пользователю возможность работать с РБД как с одной целостной базой данных. Распределенная сист ема баз данных (РСБД) эт о РБД вмест е из РСУБД. Не следует пут ат ь РСБД с цент рализованной базой данных, кот орая использует ся в сет и (рис. 9.1). В эт ом случае база данных расположена на одному з компьют еров, а все другие имеют дост уп к нее через коммуникационную сет ь. Не являет ся распределенной т акже база данных, кот орая работ ает в среде многопроцессорных компьют еров. В эт ом случае мы имеем дело с параллельной БД. Рисунок 9.1 Цент рализованная база данных в компьют ерной сет и Архит ект ура распределенной СУБД приведена на рис Каждый из узлов сет и содержит свою базу данных, однако они рассмат ривают ся как логически единая база, а не как совокупност ь разбросанных в сет и файлов. Все данные ест ь логически взаимозависимыми. Распределенная СУБД эт о полноценная СУБД, чт о выполняет все необходимые функции из управления данными. В зависимост и от т ипа программного обеспечения различают два т ипа РСУБД: однородные; неоднородные. Рисунок Распределенная база данных В однородных РСУБД предполагает ся, как минимум, кот орый на всех узлах используют ся
64 Раздел 3 - Общие сведения о других видах баз данных и баз знаний 64 однот ипные СУБД (например, реляционные), кот орые имеют похожие функциональные возможност и. Как максимум, припускает ся, чт о на всех узлах используют ся одинаковые т ехнические средст ва, т о ест ь одинаковые т ипы компьют еров и программного обеспечения. Эт о касает ся операционных сист ем, программного обеспечения СУБД и моделей данных, кот орые поддерживают ся. В неоднородных РСУБД узлы базируют ся на разных программно-т ехнических плат формах, кот орые могут содержат ь разные т ипы СУБД. Кроме т ого, т акие СУБД могут поддерживат ь разные модели данных. В эт ом случае усложняет ся решения проблемы их взаимодейст вия. Одной из важных проблем РСУБД ест ь дост ижения логической независимост и данных от мест а хранения, т о ест ь прозрачност ь дост упа к данным. Эт о означает, чт о пользоват ель должен имет ь возможност ь воспринимат ь все необходимые ему данные как единое целое, не счит аясь с т ем, каким образом они распределены в сет и. 9.2 Свойства распределенных баз данных Впервые задача об исследовании основ и принципов создания и функционирование распределенных информационных сист ем была пост авлена извест ным специалист ом в област и баз данных Д. Дейт ом. Локальная авт ономия (local autonomy). Эт о качест во означает, чт о управление данными на каждом из узлов распределенной сист емы выполняет ся локально. База данных, расположенная на одному из узлов, являет ся неот ъемлемым компонент омраспределенной сист емы. Будучи фрагментом общего пространства данных, она в то же время функционирует как полноценная локальная база данных, а управление ею осущест вляет ся локально, независимо от других узлов сист емы. Независимост ь узлов (no reliance on central site) Все узлы равноправные и независимые, а расположенные на них БД являют ся равноправными пост авщиками данных в общее прост ранст во данных. База данных на каждом из узлов включает полный собст венный словарь данных и полност ью защищенная от несанкционированного дост упа. Беспрерывные операции (continuous operation) Эт о возможност ь беспрерывного дост упа к данным в рамках распределенной БД независимо от них расположение и независимо от операций, кот орые выполняют ся на локальных узлах. Прозрачност ь расположения (location independence) Пользоват ель, кот орый обращает ся к БД, ничего не должен знат ь о реальном, физическое размещение данных в узлах информационной сист емы. Прозрачная фрагмент ация (fragmentation independence) Возможност ь распределенного (т о ест ь на разных узлах) размещение данных, логически объединенных в единое целое. Сущест вует фрагмент ация двух т ипов: горизонт альная и верт икальная. Первая означает, чт о ст роки т аблицы хранят ся на разных узлах. Друга означает распределение ст олбцов логической т аблицы по нескольким узлам. Прозрачное т иражирование (replication independence) Тиражирование данных - эт о асинхронный процесс перенесения изменений объект ов исходной базы данных в базы, расположенные на других узлах распределенной сист емы Обработ ка распределенных запросов (distributed query processing) Возможност ь выполнения операций выборки данных с распределенной БД, с помощью запросов, сформулированных на языке SQL Обработ ка распределенных т ранзакций (distributed transaction processing) Возможност ь выполнения операций обновления распределенной базы данных, кот орые не возбуждают ся целост ност ь и согласованност ь данных. Эт а цель дост игает ся упот реблением двухфазного прот окола фиксации т ранзакций. Независимост ь от оборудования (hardware independence) Эт о свойст во означает, чт о как узлы распределенной сист емы могут выст упат ь ПК любых моделей и производит елей Независимост ь от операционных сист ем (operationg system independence) - Эт о качест во выт екает с предыдущего и означает многообразие операционных сист ем, управляющих узлами распределенной сист емы Прозрачност ь сет и (network independence) Дост уп к любым базам данных происходит по сет и. Спект р поддерживаемых конкрет ной СУБД сет евых прот околов не должны быт ь ограничением сист емы, основанной на распределенной БД Независимост ь от баз данных (database independence) Эт о качест во означает, чт о в распределенной сист еме могут работ ат ь СУБД разных производит елей, и возможные операции поиска и обновление в базах данных разных моделей и формат ов. 9.3 Логическая архит ект ура распределенных баз данных Логическая архит ект ура распределенных баз данных эт о архит ект ура логически взаимозависимых данных. Графическое изображение логической архит ект уры распределенных баз данных приведено на рис Особенност ь архит ект уры РБД заключает ся в т ом, чт о возникает еще один уровень, глобальный концепт уальный, задачам кот орого ( как и в модели ANSI/SPARC) ест ь изображения концепт уальной модели предмет ной област и в целом. На эт ом
65 Раздел 3 - Общие сведения о других видах баз данных и баз знаний 65 уровне описывает ся характ ер распределения данных. Рисунок 9.3 Логическая архит ект ура распределенной СУБД На локальном концепт уальном уровне осущест вляет ся локальное описание ПО. То ест ь схема этого уровня содержит описание только той части ПО, которая является специфической для конкрет ного узла распределенной ПО; данные других узлов распределенной ПО в схеме не указывают ся. От ображение «глобальный- концепт уальный/локальный-концепт уальный» дают возможност ь изобразит ь глобальную концепт уальную схему в виде совокупност и локальных концепт уальных схем, и наоборот. Глобальная внешняя схема изображает данные, необходимые пользоват елям и приложениям, в желат ельном для них виде, независимо от образа распределения данных за узлами. Эт а задача решает ся благодаря т ому, чт о глобальные внешние схемы базируют ся на глобальной концепт уальной схеме. Локальные внешние схемы базируют ся на локальных концепт уальных схемах, зат ем они могут ссылат ься лишь на т е данные, кот орые расположены на соот вет ст вующем узле распределенной ПО. Локальные внут ренние схемы эт о схемы хранения данных на конкрет ных узлах распределенной ПО. Они связаны с соот вет ст вующими локальными концепт уальными схемами. 9.4 Архит ект урапрограммно-т ехническихсредст враспределенныхсубд Свойства архитектуры Архит ект ура программно-т ехнического комплекса распределенных СУБД имеет т ри главные характ ерист ики: распределенност ь; неоднородност ь; авт ономност ь. Рассмот рим эт и характ ерист ики дет альнее. Распределенность Способ распределения компонент ов сист емы баз данных за компьют ерами сет и определяет ся т ем, ест ь ли в сет и единый компьют ер с полномочиями распределенной СУБД, или же их несколько. Если т аких компьют еров несколько, т о или ест ь между ними взаимодействие и т.п. Неоднородность Важной характ ерист икой являет ся мера однородност и программно- т ехнических средст в СУБД. Речь идет о т ехническом обеспечении (т ипы компьют еров), коммуникационные средст ва связи, операционные сист емы и т ипы баз данных (модели данных, языки запросов, алгорит мы управления транзакциями и т.п.). Автономность Авт ономност ь характ еризует, насколько самост оят ельно компонент ы СУБД могут выполнят ь свои функции. К вопросам авт ономност и принадлежат: авт ономност ь проект ных решений (насколько самост оят ельно компонент ы СУБД могут решат ь задачи, кот орые были спроект ированы для них); авт ономност ь решением коммуникационных проблем (насколько самост оят ельно компонент ы СУБД могут уст анавливат ь связи с другими компонент ами); авт ономност ь вычислений (насколько самост оят ельно компонент ы СУБД могут принимат ь решение от носит ельно выполнения локальных операций). Диамет рально прот ивоположными подходами к решению эт их вопросов являет ся создание единой цент рализованной СУБД и установление СУБД в каждом из узлов сети. Замет им, чт о перечисленные характ ерист ики имеют не т олько распределенные СУБД, но и
66 Раздел 3 - Общие сведения о других видах баз данных и баз знаний 66 все распределенные сист емы обработ ки данных Разновидност и архит ект уры Основными разновидност ями архит ект уры программно-т ехнических средст в распределенной СУБД являют ся: клиент-серверная архит ект ура; архит ект ура с многими независимыми серверами; архит ект ура со взаимодейст вующими серверами; архит ект ура одноранговой сет и. Клиент-Сервернаяархитектура Такая архит ект ура предусмат ривает наличие единого компьют ера-сервера и многих компьют еров-клиент ов, кот орые взаимодейст вуют между собой через каналы связи. На сервере расположенная СУБД и инт егрированная (цент рализованная) БД. Никакого распределения баз данных за узлами сет и нет. На клиент ских компьют ерах выполняют ся приложения, кот орые работ ают с серверной базой данных, а т акже размещенное программное обеспечение для связи с от даленной СУБД. Как клиент ы, т ак и сервер оснащенные коммуникационным программным обеспечением. Архитектура с многими независимыми серверами Эт а архит ект ура предусмат ривает сущест вование многих серверов, кот орые имеют дост уп к своим локальным БД. В таком случае на компьютерах клиентов должна храниться информация относительно того, какие данные на которых серверах расположены, а также должны быть размещено программное обеспечение, кот орое дает возможност ь декомпозуват и запит ь для их выполнения на разных серверах и пот ом объединит ь результ ат ы. Архитектура со взаимодействующими серверами В эт ом случае предполагает ся, чт о каждый из серверов содержит полную информацию относительно того, какие данные на каких серверах хранятся, а также способен обрабатывать распределенные запросы. В случае необходимост и один сервер может обрат ит ься к другому для получения необходимых данных. Каждыйклиент имеет свой сервер, к кот орому обращает ся для выполнения операций над распределенной базой данных. Архитектура одноранговой сети Все компьют еры сет и являют ся серверами. На каждом компьют ере размещено распределенную СУБД и базу данных, из каждого компьют ера можно прислат ь к другому запрос на получение необходимых данных. 9.5 Распределенное хранение данных В распределенной СУБД данные распределяют ся за узлами сет и. Сущест вуют два основных механизма распределенного хранения данных: фрагмент ация; репликация Рассмот рим их реализацию в реляционной модели данных Фрагмент ация Сут ь фрагмент ации заключает ся в т ом, чт обы поделит ь логическую базу данных на фрагмент ы с целью хранения каждого фрагмент а на определенном узле сет и. Единицами фрагмент ации могут быт ь от ношения и сост авленные от ношения. В случае, когда единицей фрагмент ации являет ся от ношения, решает ся проблема, какое от ношение в какой базе данных должны хранит ься. При другом подходе допускает ся, чт о любое от ношение может быт ь изображено в виде совокупност и фрагмент ов, кот орые распределяют ся за разными базами данных. Фрагмент ацию, кот орая осущест вляет ся распределением от ношений за базами данных, т еорет ически осущест вит ь несложно, поэт ому рассмот рим проблему фрагмент ации собст венное от ношений. Фрагментация отношений. Задача фрагмент ации от ношений формулирует ся т аким способом. Пуст ь заданное отношение R. Его нужно изобразить в виде совокупности отношений R1. Rn так, чтобы эта совокупност ь от вечала крит ериям эффект ивност и (по времени дост упа, памят ью, загруженност ью компьют еров и т.п.). Фрагмент ация являет ся коррект ной, если она полная, не содержит сечений и может быт ь реконст руированная. Объясним эт и т ермины. Декомпозиция отношения R на фрагменты R1, R2, Rn является полной тогда и лишь тогда, когда каждый элемент данных с R принадлежит некот орому из от ношений Ri. Декомпозиция от ношения R на фрагмент ы R1, R2, Rn может быт ь реконст руированная, если сущест вует такое реляционное выражение φ(r1, R2, Rn), что R=φ(R1, R2, Rn). Декомпозиция отношения R на фрагменты R1, R2, Rn не содержите сечений, если любой элемент данных с R содержит ся не более чем в одном фрагмент е. Есть три типа фрагментации отношений: горизонт альная;
67 Раздел 3 - Общие сведения о других видах баз данных и баз знаний 67 вертикальная; смешанная Рассмот рим каждый из эт их разновидност ей фрагмент ации. Горизонтальная фрагментация Горизонт альная фрагмент ация сост оит в распределении корт ежей от ношения за фрагмент ами. Формально горизонт альную фрагмент ацию можно определит ь т аким способом. Пуст ь заданное от ношение R и на нем определенный предикат Fi. Тогда горизонт альный фрагмент Rі от ношения определяет ся т ак: То есть горизонтальный фрагмент Rі это множество кортежей R, которые удовлетворяют условие Fi. Рассмот рим несколько примеров. Пуст ь задано от ношение ПРОЕКТ (Рном, Название, Тип, Ст оимост ь). Очевидно, чт о множест во предикат ов < Стоимость < Стоимость = Стоимость > >порождает полную фрагмент ацию от ношения ПРОЕКТ, кот орая не содержит сечений. Предикат ы < Стоимость < Стоимость > >порождают полную фрагмент ацию, кот орая содержит сечение. А предикаты < Стоимость < 200. Стоимость > 300>порождают неполную фрагмент ацию, кот орая не содержит сечений. Преимущест ва горизонт альной фрагмент ации: дает возможност ь параллельно обрабат ыват ь фрагмент ы от ношения; дает возможность разделять отношение так, чтобы кортежи располагались там, где они будут использоват ься чаще всего. Вертикальная фрагментация Сут ь верт икальной фрагмент ации заключает ся в т ом, чт о от ношения делит ся на две или больше проекций, то есть схема отношения делится на определенное множество подсхем. Для восст ановления исходного от ношения из фрагмент ов необходимо, чт обы все подсхемы содержали первичный ключ. Сущест вует другой подход, когда во время деления схемы к каждому фрагмент у авт омат ически добавляет ся поле с идент ификат ором корт ежа. Значение этого идентификатора по обыкновению устанавливаются системой автоматически. Рассмот рим пример.пуст ь задано от ношения СНАБЖЕНИЕ(#рном, Пост авщик, Оборудование, Проект). СНАБЖЕНИЕ #Рном Пост авщик Оборудование Проект р1 иванов двигат ель АН-24 р2 иванов двигат ель ЯК -40 р3 иванов шасси АН-24 р4 пет ров двигат ель АН-24 р5 пет ров елект рооборудование ЯК -40 р6 пет ров елект рооборудование АН-70 Преимущест ва верт икальной фрагмент ации: дает возможность разделять кортежи отношения так, чтобы их части располагались там, где они будут использоват ься чаще всего; дает возможност ь проводит ь параллельную обработ ку от ношений; наличие идент ификат ора корт ежа дает возможност ь осущест влят ь эффект ивное соединение верт икальных фрагмент ов. Смешанная фрагментация Смешанная фрагмент ация предусмат ривает последоват ельное применение верт икальной и горизонт альной фрагмент аций. Распределение данных за узлами сети После получения всех необходимых фрагмент ов от ношений возникает проблема распределения этих фрагментов по узлам сети. Единых рекомендаций относительно того, как это делать, нет. Нужно найти оптимальное распределение фрагментов F по узлам сети S при условии, кот орое извест ное распределение приложений Q за узлами сет и. Определяя оптимальность, нужно учитывать разные параметры, в частности: ст оимост ь передачи, хранение и обработ ки данных; временные характ ерист ики; производит ельност ь; ограничение (например, емкост ные характ ерист ики узлов сет и). Для т ого чт обы распределит ь фрагмент ы по узлам сет и, необходима дополнит ельная
68 Раздел 3 - Общие сведения о других видах баз данных и баз знаний 68 информация, кот орая касает ся базы данных и размеров фрагмент ов; приложений (мест их расположения, част от ы использования т ех или других фрагмент ов для выбирания данных, част от ы использования фрагмент ов для восст ановления данных); узлов сети (стоимости хранения и обработки данных в узлах); сет и (ст оимост и и временных характ ерист ик передачи данных между двумя узлами) Репликация Репликация эт о механизм распределения данных по узлам, кот орый позволяет сохранят ь копии одним и т ех же данных на разных узлах сет и с целью ускорения поиска и повышение стойкости к отказам. Отношение или фрагмент есть реплікованим, если его копии хранятся на двух или больше узлах (копии еще называют репликами). При полной репликации от ношения его копии хранятся на всех узлах сети. Допускается ситуация, когда вся база данных хранится на всех узлах сет и эт о называет ся полною репликацией базы данных. Преимущест ва репликации: дост упност ь (в случае перебоя в работ е узла, кот орый содержит от ношение R, его дост упност ь на других узлах сохраняет ся); параллелизм (выполнение запросов к от ношению R может быт ь распараллелено по всем репликам отношения); снижение стоимости передачи данных (отношение R доступно локально во всех узлах, где ест ь его реплики). Недост ат ки репликации: повышает ся ст оимост ь хранения, создание и восст ановление данных; повышают ся т ребования к ресурсам; усложняет ся поддержания целост ност и данных, например одновременное восст ановление разных реплик одного и того же отношение Механизмы репликации Для реализации репликации используют ся т ри сервера: издат ель, дист рибьют ор и подписчик. Издат елем называют сервер, кот орый предост авляет размещенные на нем данные для копирования на другие сервера. Кроме создания копии данных, издат ель от слеживает внесенные в его базы данных изменения и гот овит новую копию. Дист рибьют ором называет ся сервер, кот орый поддерживает распределенную базу данных. Он выполняет роль посредника, копирует все публикации, подгот овленные издат елем, и пересылает их подписчикам. Дист рибьют ором может быт ь выделенный сервер или сервер, сконфигурированный как издат ель или подписчик. Конкрет ные функции, кот орые их выполняет дист рибьют ор, зависят от мет одов репликации. Подписчиком называет ся сервер, кот орый получает копии данных, предост авленные видавцем. Механизмы изменения данных подписчиком от личают ся от механизмов изменения данных видавцем. Модели репликации Ест ь т акие модели репликации: репликация момент альных снимков; репликация т ранзакций. Репликация момент альных снимков являет ся прост ейшей моделью репликации. Момент альный снимок эт о полная копия данных, избранных для репликации; она рассылает ся подписчикам. Во время репликации т ранзакций использует ся журнал т ранзакций базы данных. Избранные т ранзакции копируют ся в базу данных дист рибьют ора с сохранением информации о последоват ельност и их выполнения, пот ом рассылают ся серверам- подписчикам и выполняют ся на них в т ом же порядке, в кот ором выполнялись на сервере-издат еле Эт от механизм уменьшает загрузку сет и, его рекомендует ся использоват ь в больших базах данных с небольшим количеством изменений. Топология репликаций Топология репликаций описывает характ ер взаимосвязей между участ никами репликации: репликация «один-ко-многим» предусмат ривает наличие одного издат еля и нескольких подписчиков; репликация «много-к-одному» имеет мест о, когда данные от нескольких издат елей пересылают ся одному подписчику; репликация «много-ко-многим» означает, чт о данные от нескольких издат елей пересылают ся нескольким подписчикам. 9.6 Обработка распределенных транзакций Транзакция набор команд, который выполняется как единое целое. В транзакции или все команды будут выполнены, или ни одна из них не выполнится. Если хотя бы одна из команд т ранзакции не может быт ь выполненная, осущест вляет ся от кат ы (восст анавливает ся ст ан сист емы, в кот ором она находилась к началу выполнения т ранзакции).
69 Тема 10 - Объектно-ориентированные базы данных 69 Транзакции должны удовлет ворят ь т ребования ACID (Atomicity, Consistency, Isolation, Durability ат омарност ь, непрот иворечивост ь, изолированност ь, долговечност ь), чт о гарант ируют правильность и надежность работы системы. Атомарность предусмат ривает т акое: выполняются все операции транзакции или ни одна из них не выполняется; если выполнение т ранзакции было прервано, т о все сделанные т ранзакцией изменения должны быт ь упраздненные Дейст вия, направленные на обеспечение ат омарност и т ранзакции во время ее аварийного завершения в связи с ошибками введения/вывода, перегрузками сист емы или блокированиями, называют ся восст ановлением т ранзакции. Дейст вия, направленные на обеспечение ат омарност и во время выхода из ст роя сист емы, называют ся восст ановлением в случае возникновения перебоев. Непротиворечивость Непротиворечивость означает, что транзакция, которая работает с непротиворечивой базой данных, после завершения работ ы ост авляет ее т акже в непрот иворечивом сост оянии. Транзакция не должна нарушат ь целост ност базы данных. Для решения проблем одновременного дост упа инст ит ут ANSI разработ ал специальный ст андарт, кот орый определяет чет ыре уровне блокирования (более высокий уровень предусмат ривает выполнение условий всех низших уровней): Уровень 0. Запрет «загрязнения» данных. На этом уровне требуется, чтобы менять данные могла лишь одна транзакция. Если другой транзакции необходимо изменить эти же данные, то она должна ожидат ь завершение первой т ранзакции. Уровень 1. Запрет некоррект ного счит ывания. Если определенная т ранзакция начала менят ь данные, то никакая другая транзакция не сможет считать эти данные до тех пор, пока первая не завершит ся. Уровень 2. Запрет неповт оряемого счит ывания. Если определенная т ранзакция счит ывает данные, т о никакая другая т ранзакция не сможет их изменит ь. Ит ак, во время повт орного счит ывания данные будут находит ься в начальном сост оянии. Уровень 3. Запрет «фантомов». Если транзакция обращается к данным, то никакая другая транзакция не сможет добавить или удалить строки, которые могут быть считаны во время выполнения т ранзакции. Реализация эт ого уровня блокирования выполняет ся блокированием диапазона ключей. Это блокирование накладывается не на конкретные строки таблицы, а на ст роки, кот орые от вечают определенному логическому условию. Изолированность Свойство изолированности означает, что на работу транзакции не должны влиять другие транзакции. Транзакция «видит» данные в том состоянии, в котором они находились к началу работ ы другой т ранзакции, или в т ом сост оянии, в кот ором они находят ся после ее завершения. Одна т ранзакция не может просмат риват ь промежут очные сост ояния данных, которые используются другими транзакциями. Если транзакция считывает несколько раз те же самые данные, то она должна получать их каждый раз в том состоянии, в котором они были во время первого счит ывания. Еще одним аспект ом изолированност и являет ся невозможност ь работ ы с неполными результ ат ами незавершенная т ранзакция не может передават ь свои результ ат ы другим т ранзакциям к подт верждению своего успешного завершения. Долговечность После т ого, как было подт верждено успешное завершение работ ы т ранзакции (Commit), система должна гарантировать, что ее результаты не будут утрачены, несмотря на возможные перебои. Эт о и называет ся долговечност ью. Для обеспечения долговечност и применяют ся механизмы восст ановления базы данных. Выводы В отличие от сети с централизованной базой данных каждый из узлов сети с распределенной базой данных содержит свою базу данных. Каждая БД рассмат ривает ся как логически единая база. Распределенная СУБД эт о полноценная СУБД, чт о выполняет все необходимые функции из управления данными. В зависимост и ипа программного обеспечения различают однородные и неоднородные РСУБД Одной из важных проблем РСУБД являет ся дост ижение логической независимост и данных от мест а хранения, т о ест ь прозрачност ь дост упа к данным. Эт о означает, чт о пользоват ель должен имет ь возможност ь воспринимат ь все необходимые ему данные как единое целое, не счит аясь с т ем, каким образом они распределены в сет и. К основным характ ерист икам РСУБД нужно от нест и т акие, как: распределенност ь, неоднородност ь и авт ономност ь. Они определяют взаимодейст вие компьют еров, средст ва связи и самостоятельность каждого отдельного узла. Разновидност и архит ект уры программно-т ехнических средст в распределенной СУБД определяют распределение баз данных между узлами сет и, мест о сохранения информации в
70 Тема 10 - Объектно-ориентированные базы данных 70 сети. Определяют два основных механизма распределенного хранения данных: фрагмент ация и репликация. От личие между ними сост оит в распределения логической базы данных на фрагмент ы: фрагмент ация определяет деление базы на от дельные блоки, кот орые хранят ся на определенном узле сет и, а репликация сохранение копий базы данных на кождом узле. Транзакции к распределенным базам данных должны удовлет ворят ь т ребованиям ат омарност и, непрот иворечивост и, изолированност и и долговечност и. Вопросы для самоконтроля 1. Чт о т акое однородные и неоднородные распределенные базы данных? 2. От вечает ли логическая архит ект ура распределенных баз данных архит ект уре ANSI/ SPARC? 3. Что такое розподіленість, неоднородность и автономность баз данных? 4. Какие механизмы распределенного хранения данных вы знает е? 5. Какие разновидност и фрагмент ации баз данных вы знает е? 6. Что такое репликация? Которые существуют механизмы и модели репликации? 7. Что такое правила ACID выполнение транзакций? Тема 10 - Объектноориентированные базы данных 10.1 Объектно-ориентированная модельodmg В объект но-ориент ированной модели данные и мет оды, кот орые их обрабат ывают, объединяют ся в ст рукт уры, кот орые называют ся объект ами. Типы объект ов называют ся классами. С точки зрения баз данных есть такие важные особенности ООМ: поддержка ст рукт ур данных, кот орые имеют произвольный уровень сложност и; идент ифицируемост ь и уникальност ь объект ов; принадлежност и объект ов классам; инкапсуляция; наследование и иерархии классов; полиморфизм. Сложные ст рукт уры данных Сложные объект ы ст роят ся из более прост ых с помощью конст рукт оров. Прост ейшими объект ами являют ся: числа, символы, символьные ст роки произвольной длины, булевые переменные и т.п. Существуют разные конструкторы сложных объектов (кортежей, множеств, мульт имножест в, списков и массивов). Минимальный набор конст рукт оров, кот орый должна имет ь сист ема, эт о конст рукт оры множест в, списков и корт ежей. Множест ва необходимы, поскольку благодаря им наборы объект ов реального мира изображают ся ест ест венным способом. Корт ежи предост авляют способ изображения свойст в сущност ей. Списки и массивы нужны для от ображения благоуст роенност и объект ов реального мира, а т акже для изображения широкого круга мат емат ических объект ов. Любой конст рукт ор должен быт ь применимым к любому объект у (например, должна предост авлят ься возможност ь пост роения множест ва из массивов или массива из множест в). Конст рукт оры реляционной модели не имеют т акого свойст ва, поскольку конст рукция множест ва может быт ь применена лишь к корт ежам, а конст рукция корт ежа лишь к ат омарным значениям. Дажереляционная модель, кот орая поддерживает ненормализованные от ношения (от ношения, кот орые не находят ся в первой нормальной форме), не имеет указанного свойст ва, поскольку конст рукцией верхнего уровня всегда должны быт ь от ношение. Манипулирование сложными объект ами обеспечивает ся соот вет ст вующими операциями, которые часто распространяются на все компоненты таких объектов. Примером может быть выборание или удаление сложного объект у или созданныее его копии. Сущест вует возможност ь определят ь дополнит ельные операции над сложными объект ами.
71 Тема 10 - Объектно-ориентированные базы данных 71 Идентифицируемость, уникальность и состояние объектов Каждый объект являют ся уникальным, т.е. обеспечивает ся уникальная идент ификация объект ов. Сост ояние объект а эт о т екущее значение, приписанное объект у. Объект может имет ь единст венное сост ояние на прот яжении своего жизненного цикла или переходит ь из одного ст ана в другого. Поскольку объект ы имеют свойст во инкапсуляции, т о сост ояние объект а являет ся абст ракцией, кот орая определяет ся лишь через него поведение (мет оды). Уникальност ь объект а не зависит от его сост ояния. Два объект а, кот орые находят ся в одном и том же состоянии, являются равными, но не идентичными. Не может существовать двух или больше экземпляров одного объекта (двух копий одного и того же объекта с одним и т ем самым идент ификат ором). В модели с идент ифицированием объект ов объект сущест вует независимо от своего значения. Итак, есть два понятия эквивалентности объектов: объекты могут быт ь идент ичными (быт ь одним и т ем же объект ом) или они могут быт ь равными (находит ься в одном и т ом же сост оянии). В эт ом конт екст е нужно рассмот рет ь т акие два аспект а: различение и изменение объект ов. Различение объектов. В модели с объект ами, кот орые идент ифицируют ся, два объект ы могут совмест но использоват ь компонент ы (в част ност и другие объект ы). Ит ак, схемат ическим от ображением сложного объект а являет ся граф, вмест о эт ого в сист еме без идент ифицированност и объект ов эт о дерево. Рассмот рим т акой пример: человек имеет имя, возраст и детей. Предположим, чтоиван и Мария имеют сына по имени Петр. В реальной жизни могут иметь место две ситуации: Иван и Мария являются родителями одного и того же ребенка или каждый из них имеет по сыну. В модели с идентифицированностью объектов адекватно отображаются обе сит уации. Изменение объект ов. Предположим, чт о Иван и Мария являют ся родит елями мальчика по имени Петр. Тогда изменения, которые касаются сына Марии, будут выполняться с объект ом Пет р, зат ем и с сыном Ивана. Поведение объект ов. Поведение объект а эт о совокупност ь операций (мет одов), кот орые он предост авляет. Лишь через эт и операции раскрывает ся семант ика объект а. Выполнение операций являет ся единым способом взаимодейст вия между объект ами. Все возможные операции объект а образовывают его инт ерфейс. Лишь используя операции, можно изменит ь ст ан объект а. Классы объектов В объект но-ориент ированной модели класс обобщает общие черт ы объект ов, кот орые имеют одинаковые свойст ва, и от вечает понят ию абст ракт ного т ипа данных. Класс определяет образ реализации множест ва объект ов, уст анавливая их ст рукт уру, поведение и инт ерфейс, т о являют ся образ запоминания информации об их ст анах. Однако собственно стан должен запоминать сам объект. Класс являет ся одновременно фабрикой и хранилищем объект ов. Как фабрика объект ов класс используется для созданныея новых объектов. Срок хранилище объектов означает, что к классу присоединяет ся набор объект ов, кот орые являют ся его экземплярами. Ит ак, классы используют ся для созданныея объект ов и манипулирования ими. Одной из основных свойст в класса, зат ем и его объект ов, являют ся инкапсуляция. Инкапсуляция. Инкапсуляция т ребует, чт обы данные и программные коды для манипулирования данными были скрыты. С этой точки зрения объект делится на интерфейсную и реализационную части. Інт ерфейсная част ь являет ся спецификацией набора операций, допуст имых над объект ом. Лишь эт а част ь объект а видима для мет одов других объект ов. Реализационная част ь сост авляет ся с данных, чт о описывают сост ояние объект а, и процедур, кот орые реализуют операции над объект ом. Инкапсуляция специфицирует ся на уровне объявления класса. Наследование. Наследование являет ся механизмом, кот орый дает возможност ь создават ь новые классы с использованием данных и мет одов других классов. Эт о дает возможност ь некот орые свойст ва, общие для многих классов, описыват ь в базовом классе. Например, если необходимо добавит ь новый класс Одежда, кот орая полност ью совпадает с классом Товар, за исключением наличия дополнит ельных сведений о размере, языком Java эт о можно записат ь т ак: public class Одежда extends Товар < int размер: >Таким образом мы указали, чт о Одежда эт о Товар, поэт ому первый имеет все данные и мет оды вт орого, а т акже собст венные данные, кот орые хранят ся в сменной размер. Наследование дает возможност ь ст роит ь иерархию классов. Полиморфизм. Принцип полиморфизма являет ся расширением принципа наследования и дает возможност ь переопределят ь мет оды в унаследованных классах. Например, ест ь несколько разновидност ей т оваров, для кот орых присущий специфические правила вычисления цены. В част ност и т оварами могут быт ь продукт ы, на кот орые не дейст вуют наценки, и одежда, на кот орую наценка уст ановлена. Все т овары наследуют мет од Суммарная цена() из
72 Тема 10 - Объектно-ориентированные базы данных 72 базового класса Товар, но правила вычисления цены могут быт ь разными. Эт о означает, чт о каждый класс, кот орый являет ся пот омком класса Товар, может имет ь собст венную реализацию мет ода Суммарная_цена(). Тому вираз х. Суммарная цена () может означат ь разные правила вычисления цены в зависимост и от т ого, экземпляром какого класса являет ся объект х Языкописанияобъект овodl ODMG Любая СУБД имеет язык описания данных, кот орый использует ся для описания схем баз данных. Язык описания объект ов ODL ODMG рассмат ривает ся как расширения языка описания объект ов, предназначенное для описания объект ов,их ат рибут ов, связей и операций. Основой эт ого языка ст ал язык IDL (Interface Definition Language), разработ анный группой OMG Основные положения ODL эт о язык, предназначенный прежде всего для спецификации классов. Он поддерживает объект ный язык описания объект ов ODMG и не являет ся языком программирования. Более т ого, ODL независим от языков программирования. Основная цель разработки этого языка создать единую основу для описания объектов и тем самым обеспечить перенесение схем объектных данных между разными ООСУБД. Основные положения объект ного языка описания объект ов данных ODMG: базовым понят ием языка описания объект ов являет ся объект; поведение объект а определяет ся при помощи множест ва его операций; состояние объекта определяется при помощи множества его свойств: объект ы принадлежат к классам, именно через классы они специфицируют ься; класс имеет инт ерфейсную и реализационную част и; класс являет ся объект ом; ODL специфицирует классы. В объектном языке описания объектов ODMG речь идет прежде всего о типах, а уже потом о классах. Класс рассмат ривает ся как разновидност ь т ипа, кот орый имеет одну реализацию. В общем случае допускает ся, чт о т ип имеет несколько реализаций. Множест венност ь реализаций т ипа необходимо для поддержки неоднородных баз данных, распределенных в сет и, и сред с разными языками программирования и компилят орами Система типов ODL Базовыми т ипами языка являют ся: integer, float, string, boolean, перечисляемые т ипы, кот орые создают ся с помощью ключевого слова enum, и классы. Производные т ипы создают ся с помощью конст рукт оров т ипов. Являют ся конст рукт ор Struct для ст рукт ур и чет ыре конст рукт оры для т ипов коллекций: Set, Bag, List, Array. Описание ст рукт ур и коллекции приведены дальше Объект ы Основные характ ерист ики объект ов. OID уникально идент ифицирует объект, от личая его от других объект ов т ой предмет ной област и, где он был создан. Любой объект имеет лишь один OID, но может имет ь больше одного имени. Объект ы могут идент ифицироват ься предикат ами, определенными на их свойст вах. Удаление объект а не приводит к рекурсивному удалению связанных с ним объект ов. На рис приведенная классификация объект ов.
73 Тема 10 - Объектно-ориентированные базы данных 73 Рисунок 10.1 Классификация объект ов в ODL Лит ералы Литералы это объекты, экземпляры которых нельзя менять. Для заведомо определенных типов литералов нельзя менять операции.
74 Тема 10 - Объектно-ориентированные базы данных 74 Рисунок 10.2 Классификация лит ералов 10.3 Объектны й язык запросов OQL ODMG OQL ODMG это независимый язык запросов к объектной модели данных ODMG, синтаксис кот орой базирует ся на языке SQL. Кроме т ого, предполагает ся возможност ь его использования в языках программирования. Язык запросов ориент ирован на пост роение выражений, ее конструкции имеют такие свойства: любой запрос является выражением, которое имеет тип объект или литерал; выражения и операции над ними могут вкладыват ься одно в одно; результ ат ом выполнения запроса являют ся объект ы, кот орые принадлежат т ипам, обозначенным в язык описания объект овели ODMG, и могут принимат ь участ ие в формировании выражений. Язык имеет высокоурвневые примит ивы для манипулирования множест вами, объект ами, ст рукт урами, массивами и списками. В ней от сут ст вуют операт оры обновления, вмест о них используют ся операции, определенные для объект ов. Предполагает ся, чт о все создаваемые объект ы имеют OID, а лит ералы уникально идент ифицируют ся своим значением Запит и OQL В OQL запросом может быт ь любое выражение, кот орое возвращает объект, коллекцию объект ов, лит ерал или коллекцию лит ералов. Поскольку запрос эт о выражение, а любое выражение имеет тип, то и любому запросу ставится в соответствие тип. Наиболее распрост раненной разновидност ью запроса, как и в SQL, являют ся select-запрос. Например, приведенный ниже запрос находит множество лиц мужского пола, и при этом типом значения, кот орое возвращает ся, будет Bag : SELECT х FROM persons x WHERE x.sex = M' Замет им, чт о select-выражение возвращает коллекцию т ипа Bag, т.е. являют ся мульт имножест вом (множест во со значениями, кот орые повт оряют ся). Использование слова DISTINCT приводит к т ому, чт о т ип коллекции, кот орая возвращает ся, - Set, т о являют ся множест во. Приведенный ниже запрос возвращает список номеров факульт ет ов для людей по
75 Тема 10 - Объектно-ориентированные базы данных 75 имени Pete, то являются литерал типа Set. SELECT DISTINCT x.faculty_id FROM persons x WHERE x.name = 'Pete' Заметьте, что в запросах нужно обращаться именно к екстентів, а не к классам Вычисление промежут очных результ ат ов Запрос можно не т олько сформулироват ь для выполнения, но и определит ь для дальнейшего использования в других запросах (определенный аналог вирт уальных т аблиц, создаваемых командой CREATE VIEW в языке SQL). Эт одост игает ся с помощью определения запроса, кот орый имеет т акой вид: define имя_запроса as выражение Например define Joe as element ( SELECT x FROM students x WHERE x.name = 'Joe') Здесь element являет ся преобразоват елем т ипа, кот орый сводит т ип одноэлемент ной коллекции к типу элемента. Итак, Joe является именем объекта класса students со значением атрибута name равным 'Joe'. Теперь к объекту Joe можно обратиться, например, для получения значений его ат рибут ов. Так, выражения Joe.Віrthdate. Joe.faculty_id.Joe.passport возвращают дату рождения, номер факультета и номер паспорта студента по имени Joe. Имя запроса рассмат ривает ся как элемент арное выражение, как и переменные, ат омы и поименованы объект ы. Примеры элемент арных выражений: 27, nil, students, Joe Архитектура ООСУБД Ест ь разные подходы к созданнию ООСУБД. Кроме разработ ки собст венно об'єкт ноориент ированных СУБД, являют ся многочисленные способы объединения объект ноориент ированной и реляционной моделей данных. Все эт и подходы мы рассмот рим дальше Расширение реляционных СУБД Реляционные СУБД предост авляют возможност ь обращат ься к ним программам, написанным разными, в част ност и объект но-ориент ированными, языками программирования. В эт ом случае объект но-ориент ированные прикладные программы выполняют все функции, связанные с от ображением объект ной модели в реляционную, т.е. превращают объект ы в ст рукт уры данных, кот орые могут быт ь непосредст венно записанны в т абличные БД, поддерживают свойст ва наследования, инкапсуляции, связывание с объект ами их методов. РСУБД берет на себя единст венную функцию хранение данных, кот орые связаны с объект ами, причем хранение в виде реляционных т аблиц, все другое выполняет прикладная программа. Данный подход предусмат ривает включения в сост ав РСУБД средст в, кот орые облегчают процесс от ображения объект ов в базе данных и манипулирование ими. Т.е. сама РСУБД совершенст вует ся, облегчая обработ ку объект ов, но ост ает ся при эт ом реляционной. К возможным расширениям РСУБД принадлежат т акие. Предост авления возможност и авт омат ического создания уникальных идент ификат оров кортежей отношений. Например, в Огасlе являются тип rowid, который выполняет эту функцию. Такой т ип содейст вует решению проблемы поддержки ОID, хот я и не решает ее полност ью, поскольку ОID должны быт ь уникальным во всей базе данных, а не в пределах одного от ношения, как rowid. Создание механизмов определения новых т ипов данных (т акие механизмы ест ь в языках программирования). Введение новых т ипов, даже если они от вечают довольно сложным ст рукт урам данных, не прот иворечит реляционной модели данных. Другое дело, чт о реляционная модель в «чист ом» виде не предост авляет возможност и работ ат ь с сост авленными ст рукт урами данных, они рассмат ривают ся как ат омарные. Преимущест во подхода, кот орый базирует ся на расширении реляционных СУБД, заключает ся в том, что предоставляется возможность использовать всю мощность реляционных систем баз данных. Недост ат ок слабая развит ост ь средст в изображения объект ов и манипулирование ими, много из эт их функций выполняют прикладные программы Созданныее самост оят ельных ООСУБД Объект но-ориент ированные СУБД реализуют гибкую модель данных, кот орая базирует ся на т ой же парадигме, чт о и объект но-ориент ированные языки программирования. ООБД обеспечивают более глубокую инт еграцию с объект но- ориент ированными приложениями, чем реляционные базы данных, и минимизируют объем работ ы по программированию сохранения и выбирание объект но-ориент ированных данных. Преимущест ва использования одинаковых моделей в приложениях и базе данных оказывают ся т огда, когда объект но-ориент ированные язык описания объект овели являют ся сложными. Самост оят ельные ООСУБД обеспечивают полную поддержку объект но- ориент ированной парадигмы. Эт о предусмат ривает непосредст венную инт еграцию с объект ноориент ированными языками программирования, поддержку объект ных т ипов, связей между
76 Тема 10 - Объектно-ориентированные базы данных 76 объектами и операций базы данных, которые интерпретируют объекты (чаще всего объекты инт ерпрет ируют ся как записи). Примерами объект но- ориент ированных операций базы данных могут быт ь: создание ссылок на объект ы и загрузку с базы данных объект ов, на кот орые являют ся ссылки, обеспечение блокирования на объект ном уровне и возвращение объект ов как результ ат ов запросов или операций с курсорами. Инкапсуляция. Ст абильное (persistent) поведение класса являют ся независимым от проект ирования базы данных, кот орое не нуждает ся в изменении реализаций классов. Наследование. Объект инт ерпрет ирует ся одной записью независимо от т ого, насколько глубокой являет ся иерархия наследования. Все данные объект а запоминают ся в единой записи. Когда объект выбирает ся из базы данных, все данные базового класса и все даны производных классов всегда дост упные. Полиморфизм. Концепция полиморфизма т есно связана с наследованием. От носит ельно об'єкт но-ориент ированных баз данных эт о означает, чт о можно оперироват ь разными классами с помощью общего базового класса, получая данные из объект ов необходимого производного класса. То являют ся объект базового класса может имет ь т ип производного класса. Если вы последоват ельно просмат ривает е все экземпляры базового класса, т о будет е получат ь все объект ы эт ого класса, независимо от т ого, кот орого они т ипа. Удаление экземпляра базового класса приводит к удалению всего объект у, включая данные производных объект ов. Ідент ифицируемост ь объект а. ООСБД объединяют идент ифицируемост ь объект а в базе данных с идент ифицируемост ью объект а в операт ивной памят и. Программист у не нужно собственноручно поддерживать соответствие между объектами базы данных и объектами в памят и. Ссылка на объект ы. Самост оят ельные ООСУБД дают возможност ь создават ь в памят и ссылки на объекты, а потом отображать их в базе данных и наоборот. Преимущества и недостатки. Преимуществом ООСУБД являются их полная согласованность с объект но-ориент ированной парадигмой программирования, кот орое снимает все проблемы, связанные с хранением и манипулированием объект ами в базе данных. Основной недостаток связан с тем, что для самостоятельных ООСУБД нужно решать весь комплекс проблем, связанных из СУБД, кот орые уже решены в имеющихся реляционных СУБД Объект но-реляционные СУБД Особенност ь данного подхода заключает ся в т ом, чт о на базе имеющихся реляционных СУБД реализует ся объект но-ориент ированный инт ерфейс. Работ а по эт им инт ерфейсом осущест вляет ся т ак же, как и в ООСУБД, но все проблемы, связанные с созданныеем и ведением баз данных, решают ся в реляционной СУБД. Основная проблема, связанная с созданныеем т акого инт ерфейса, от ображение объект ноориент ированной модели в реляционную. Ест ь несколько способов инт еграции объект ного и реляционного подходов, которые будут рассмотрены далее. Объектно-реляционный шлюз. Объект но-реляционный шлюз авт омат ически выделяет объект ы программы и сохраняет их в реляционной базе данных. Объект но-ориент ированное приложение работ ает как обычный пользоват ель СУБД (рис. 10.3). Такой вариант дает возможност ь программист ам полност ью сконцент рироват ься на объект но-ориент ированном проект ировании Рисунок 10.3 Использование объект но-реляционного шлюза Объект но-реляционная прослойка между объект ной и реляционной СУБД. В случае использования объект но-ориент ированной прослойки программа взаимодейст вует с БД с помощью языка ООСУБД, а прослойка заменяет все объект но-ориент ированные элемент ы эт ого языка на их реляционные эквивалент ы (рис. 10.4).
77 Тема 11 - Общая характеристика баз знаний 77 Рисунок 10.4 Использование объект но-реляционной прослойки За эт о приходит ся расплачиват ься производит ельност ью. Кроме т ого, прослойка должна превращат ь объект ы в наборы связанных от ношений, генерироват ь уникальные OID объект ов и передавать эти данные к реляционной БД. Унифицированная объектно-реляционная СУБД. Эт от подход предусмат ривает создание гибридных объект но-реляционных СУБД, кот орые могут сохранят ь как т абличные данные, т ак и объект ы. Полагает ся, чт о будущее именно за гибридными СУБД. Сегодня разработ чики реляционных СУБД начинают прибавлят ь к своим продукт ам объект ноориент ированы средст ва Выводы Ныне ООСУБД отводится много внимания как с теоретической, так и с практической точек зрения. Можно выделит ь т ри характ ерные особенност и современного ст ана исследований в этой области: отсутствие общепринятой модели данных; отсутствие единой формальной теории; акт ивная эксперимент ат орская деят ельност ь. Реляционная и объект ная модели от личают ся одна от одной и пот ому в приложениях необходимо поддерживат ь две разных модели данных. Создав иерархическую ст рукт уру классов, нужно спроект ироват ь под них реляционную схему базы данных. После создания схемы базы данных необходимо вернут ься к проект ирования классов и определит ь, каким образом реализоват ь ст абильное поведение каждого из них с учет ом созданной схемы базы данных Создание от ображения между объект но-ориент ированным приложением и реляционной схемой базы данных эт о не т ривиальная задача. Реляционная модель может лишь аппроксимироват ь объект но-ориент ированную иерархию, поэт ому мноние из ее преимущест в т еряют ся во время сохранения и виборки данных. Необходимо разработ ат ь сложный программный продукт для сохранност и объект ной модели в т аблицах, дальнейшей выборки данных из них и восст ановление объект ной модели в операт ивной памят и. Возникает т акже проблема производит ельност и, связанная с необходимост ью пост оянного реконст руирования сложных связей между объектами. Язык манипулирования и запросов имеет высокоуровневые примит ивы для манипулирования множествами, объектами, структурами, массивами и списками. В нем отсутствуют операторы обновления, вмест о них используют ся операции, определенные для объект ов. Предполагает ся, чт о все создаваемые объект ы имеют OID, а лит ералы уникально идент ифицируют ся своим значением Ест ь разные подходы к созданию ООСУБД. Кроме разработ ки собст венное объект ноориент ированных СУБД, ест ь многочисленные способы объединения объект но-ориент ированной и реляционной моделей данных, среди кот орыхобъект но-реляцийной подход имеет значит ельные преимущест ва в сравнинии с другими. Вопросы для самопроверки 1. Перечислит е основные сост авляющие объект но-ориент ированной модели данных. 2. Назовит е основные положения объект ной модели данных ODMG. 3. Какие т ипы данных обозначены в языке описания объект ов ODL ODMG?
78 Тема 11 - Общая характеристика баз знаний Какие т ипы данных обозначены в языке описания объект ов ODL ODMG? 4. Какие существуют разновидности объектов в ODL ODMG? 5. Что такое «коллекция»? Какие есть встроенные типы коллекций? 6. Что такое «структура»? Какие стандартные операции обозначенны для структуры? 7. Что такое «класс»? Какие существуют характеристики класса? 8. Как специфицируют ся связи между двумя классами? Какие сущест вуют т ипы связей? 9. Чт о т акое «выражения конст руирования»? 10.Как используют ся конст рукт оры т ипов? Тема 11 - Общая характеристика баз знаний 11 ОБЩАЯ ХАРАКТЕРИСТИКА БАЗ ЗНАНИЙ 11.1 Базовые понятия Знания связаны с данными, базируют ся на них, но предст авляют результ ат умст венной деят ельност и человека, обобщают его опыт, полученный в ходе выполнения какой-нибудь практ ической деят ельност и. Они являют ся результ ат ом эмпирического опыт а. Знания эт о выявленные закономерност и предмет ной област и (принципы, связи, законы), чт о позволяют решать задачу в этой области. При обработке на ЭВМ знания трансформируются аналогично данным: знание в памят и человека как результ ат мышления; мат ериальные носит ели знаний (учебники, мет одические пособия); поле знаний - условное описание основных объект ов наглядной област и, их ат рибут ов и закономерност ей, кот орые их связывают; знание, описанные на языках предст авления знаний (продукционные языки, семант ические сет и, фреймы); базы знаний. Част о используют ся т акие определения знаний: знания - эт о хорошо ст рукт урированные данные, или данные о данных, или мет аданные. Сущест вует множест во образов определят ь понят ие. Один из широко упот ребляемых образов, основанный на идее инт енсионала. Инт енсионал понят ия эт о определение через понят ие более высокого уровня абст ракции с указанием специфических свойст в. Эт от образ определяет знание. Другой образ определяет понят ие через перечисление понят ий низшего уровня иерархии или фактов, которые относятся к определяемому. Это есть определения через данные, или экст енсионал понят ия. Знания могут быт ь классифицированы по следующим кат егориям: поверхност ные знание о видимых взаимосвязях между от дельными событ иями и факт ами у наглядной област и; глубинные абст ракции, аналогии, схемы, кот орые от ображают ст рукт уру и процессы у наглядной област и. Знание можно разделит ь на процедурные и декларат ивные. Ист орически первичными были процедурные знания, т о ест ь знание, "раскрыт ые" в алгорит мах. Они управляли данными. Для них изменения необходимо было менят ь программы. Однако с развит ием искусст венного инт еллект а приорит ет данных пост епенно менялся, и все большая част ь знаний сосредоточивалась в структурах данных (таблицы, списки, абстрактные типы данных), то есть увеличивалась роль декларат ивных знаний. Сегодня знание приобрели чист о декларат ивную форму, т о ест ь знаниями полагают предложения, записанные на языках предст авления знаний, приближенных к ест ест венным и понят ным неспециалист ам. Сущест вуют десят ки моделей (или языков) предст авление знаний для разных предмет ных област ей. Большинст во из них может быт ь сведенные к следующим классам: продукционные; семант ические сет и; фреймы; формальные логические модели и много других.
79 Тема 11 - Общая характеристика баз знаний 79 Эт и и другие модели мы рассмот рим в следующей лекции раздела Стратегии получения знаний Сущест вует несколько ст рат егий получения знаний. Наиболее распрост раненные: приобрет ение; выт ягивание; формирование. Под приобрет ением знаний понимает ся способ авт омат изированного пост роения базы знаний с помощью диалога эксперт а и специальной программы (при эт ом ст рукт ура знаний заранее закладывает ся в программу). Эт а ст рат егия т ребует сущест венной предыдущей обработ ки предмт еной област и. Сист емы приобрет ения знаний дейст вит ельно приобрет ают гот овые фрагмент ы знаний согласно ст рукт урам, заложенным разработ чикам сист ем. Большинст во эт их инст румент альных средст в ориент ированная на конкрет ные эксперт ные сист емы с жест ко определенной предмет ной област ью и моделью предст авления знаний, т о ест ь не являют ся универсальными. Термин выт ягивание знаний касает ся непосредст венного живого конт акт а инженера по знаниям и ист очника знаний. Авт оры склонны использоват ь эт от т ермин как более ёмкий и т акой, чт о более т очно выражает смысл процедуры перенесения компет ент ност и эксперт а через инженера по знаниям в базу знаний эксперт ной сист емы. Термин формирование знаний т радиционно закрепился за чрезвычайно перспект ивной област ью инженерии знаний, кот орая занимает ся разработ кой моделей, мет одов и алгорит мов анализа данных для получения знаний и учения, кот орые акт ивно развивает ся. Эт а област ь включает индукт ивные модели формирования гипот ез на основе поучит ельных выборок, учения аналогично и другие мет оды Вывод на знаниях База знаний совокупност ь знаний, кот орые от носят ся к некот орой предмет ной област и, формально предст авленным т ак, чт обы на них основе можно было осущест влят ь размышления. Базы знаний чаще всего используют ся в конт екст е эксперт ных сист ем, где с них помощью подаются навыки и опыт экспертов, занятых практической деятельностью у соответствующей област и (например, в медицине или в мат емат ике). По обыкновению база знаний являет ся совокупност ью правил вывода. Не смот ря на все недост ат ки, самое большое распрост ранение приобрела продукционная модель предст авления знаний. При использовании продукционной модели база знаний сост авляет ся из набора правил. Программа, кот орая управляет перебором правил, называет ся машиной вывода. Машина вывода (инт ерпрет ат ор правил) выполняет две функции: во-первых, просмотр существующих фактов из рабочей памяти (базы данных) и правил из базы знаний и добавления (по мере возможност и) в рабочую памят ь новых факт ов, а во-вт орых, определение порядка просмот ра и упот ребление правил. Эт от механизм управляет процессом консульт ации, сохраняя для пользоват еля информацию о полученных выводах, и приглашает у него информацию, когда для срабат ывания очередного правила в рабочей памят и оказывает ся недост ат очно данных В подавляющем большинст ве сист ем, основанных на знаниях, механизм вывода являет ся небольшой за объемом программой и включает два компонент аодин реализует собст венный вывод, другой управляет эт им процессом. Дейст вие компонент а вывода основанно на упот реблении правила, кот орое называет ся modus ponens. Правило modus ponens. Если извест но, чт о доподлинно ут верждение A, т о сущест вует правило вида «Если А, т о В», т огда ут верждение В т оже ист инно. Правила срабат ывают, когда находят ся факт ы, кот орые удовлет воряют их левой част и: если ссылка ист инна, т о должен быт ь ист инный и вывод. Компонент вывода должен функционироват ь даже при недост ат ке информации. Полученное решение может и не быт ь т очным, однако, сист ема не должна ост анавливат ься из-за т ого, чт о от сут ст вует любая част ь входной информации. Компонент, кот орый управляет, определяет порядок упот ребления правил и выполняет чет ыре функции: 1. Сопост авление образец правила сопост авляет ся с имеющимися факт ами. 2. Выбор если в конкретной ситуации может быть применено сразу несколько правил, то из них выбирает ся одно, наиболее соот вет ст вующее по заданному крит ерию (решение конфликт а). 3. Срабат ывание если образец правила при сопост авлении совпал с какими-нибудь факт ами из рабочей памяти, то правило срабатывает. 4. Дейст вие рабочая памят ь подвергает ся изменению пут ем добавления в нее вывода сработ анного правила. Если в правой част и правила содержит ся указание на любое дейст вие, т о оно выполняет ся (как, например, в сист емах обеспечения безопасност и информации). Инт ерпрет ат ор продукций работ ает циклически. В каждом цикле он просмат ривает все правила, чт обы указат ь т е, ссылки кот орых совпадают с извест ными на данный момент факт ами из рабочей памят и, После выбора правило срабат ывает, его вывод заносит ся в
80 Тема 11 - Общая характеристика баз знаний 80 рабочую памят ь, и пот ом цикл повт оряет ся сначала. В одном цикле может сработ ат ь лишь одно правило. Если несколько правил успешно сопост авлены с факт ами, т о инт ерпрет ат ор выполняет выбор по определенному крит ерию единого правила, кот орое срабат ывает в данном цикле. Цикл работы интерпретатора схематично представлен на рис Рисунок 11.1 Цикл работы интерпретатора Информация из рабочей памят и последоват ельно сопост авляет ся со ссылками правил для выявления успешного сопост авления. Совокупност ь от обранных правил сост авляет т ак называемое конфликт ное множест во. Для решения конфликт а инт ерпрет ат ор имеет крит ерий, с помощью кот орого он выбирает единое правило, после чего правило срабат ывает. Эт о выражает ся в занесении факт ов, кот орые создают вывод правила, в рабочую памят ь или в изменении крит ерия выбора конфликт ующих правил. Если же по окончанию правила упоминает ся название какого-нибудь дейст вия, т о оно выполняет ся. Работ а машины вывода зависит лишь от сост ояния рабочей памят и и от сост ояния базы знаний. На практ ике по обыкновению учит ывает ся ист ория обработ ки, т о ест ь поведение механизма выпада в предыдущих циклах. Информация о поведении механизма вывода запоминает ся в памят и сост ояний. По обыкновению памят ь сост ояний содержит прот окол сист емы. От выбранного мет ода поиска, т о ест ь ст рат егии вывода, будет зависет ь порядок упот ребления и срабат ывание правил. Процедура выбора сводит ся к определению направления поиска и образа его осущест вления. Процедуры, кот орые реализовывают поиск, по обыкновению заложенные в механизм вывода, поэт ому в большинст ве сист ем инженеры знаний не имеют к ним доступа и, итак, не могут у них ничего менять по собственному желанию. При разработ ке ст рат егии управления выводом почт енно определит ь дна вопроса: 1. Какую т очку в прост ранст ве сост ояний принят ь как начальную? От выбораэт ой т очки зависит и мет од осущест вления поиска в прямом или обрат ном направлении. 2. Какими мет одами можно повысит ь эффект ивност ь поиска решения? Эт и мет оды определяют ся избранной ст рат егией перебора глубину, ширину, по подзадачам или др. При обрат ном порядке вывода сначала выдвигает ся некот орая гипот еза, а пот ом механизм вывода как бы поворачивает ся назад, переходя к факт ам, ст араясь найт и т е, кот орые подт верждают гипот езу (рис. 11.2, слева). Если она оказалась правильной, т о выбирает ся следующая гипот еза, кот орая дет ализирует первую и являет ся по от ношению к ней подцелью. Дальше от ыскивают ся факт ы, подт верждающие ист инност ь подчиненной гипот езы. Вывод т акого т ипа называет ся управляемым целями, или управляемым консеквент ами. Обрат ный поиск применяет ся в т ех случаях, когда целые извест ные и их сравнит ельно немного. В системах с прямым выводом по известным фактам отыскивается вывод, который из этих факт ов выходит (см. рис. 11.2, слева). Если т акие выводы удает ся найт и, т о они высокомерничают в рабочую памят ь. Прямой вывод част о называют выводом, управляемому данными, или управляемым ант ецедент ами. Сущест вуют сист емы, в кот орых вывод грунт уєт ься на объединении упомянут ых выше мет одов, обрат ного и ограниченного прямого. Такой комбинированный мет од получил название циклического.
81 Тема 11 - Общая характеристика баз знаний 81 Рисунок 11.2 Стратегии вывода Пример. Ест ь фрагмент базы знаний с двух правил: П1. ЕСЛИ «отдых летом» и «человек активный», ТО «ехать в горы». П2. Если «любит солнце», ТО «от дых лет ом». Предположим, что в систему поступили факты «человек активный» и «любит солнце». ПРЯМОЙ ВЫВОД - исходя из факт ических данных, получит ь рекомендацию. 1-й проход: Шаг 1. Пробуем П1, не работает (не хватает данных «отдых летом») Шаг 2. Пробуем П2, работает, в базу поступает факт «отдых летом». 2-й проход: Шаг 2. Пробуем П2, работ ает, акт ивирует ся цель «ехат ь в горы», кот орая и выступает как совет, который предлагает экспертная система. ОБРАТНЫЙ ВЫВОД - подт вердит ь выбранную цель с помощью имеющихся правил и данных. 1-й проход. Шаг 1. Цель «ехат ь в горы»: пробуем П1 данных «от дых лет ом» нет, они становятся новой целью и пишется правило, где цель в левой части. Шаг 2. Цель «отдых летом»: правило П2 подтверждает цель и активирует ее. 2-й проход: Шаг 3. Пробуем П1, подт верждает ся искомая цель. В сист емах, база знаний кот орых насчит ывает сот ни правил, желат ельным ест ь использования ст рат егии управления выводом, кот орый позволяет минимизироват ь время поиска решения и т ем самым повысит ь эффект ивност ь вывода. К т аким ст рат егиям
82 Тема 11 - Общая характеристика баз знаний 82 принадлежат: поиск в глубину; поиск в ширину; разбивка на под задачи; альфа-бет а. При поиске в глубину как очередное подлежащее выбирает ся т о, чт о от вечает следующему, более дет альному уровню описания задачи. Например, диагност ирующая сист ема, сделав на основе извест ных симпт омов предположения о наличии определенного заболевания, будет продолжат ь запрашиват ь ут очняющие признаки и симптомы этой болезни до тех пор, пока полностью не опровергнет выдвинутую гипотезу. При поиске в ширину, наоборот, сист ема сначала проанализирует все симпт омы, кот орые находят ся на одном уровне прост ранст ва сост ояния, даже если они от носят ся к разным заболеваниям, и лишь пот ом перейдет к симпт омам следующего уровня дет альност и. Разбивка на подзадачи выполняет выделение подзадач, решения кот орых рассмат ривает ся как дост ижения промежут очных целей на пут и к конечной цели. Примером, подт верждающим эффект ивност и разбивки на подзадачи, ест ь поиск неисправност ей в компьют ере сначала определяет ся от казавшая подсист ема (пит ание, памят ь и т.д.), чт о значит ельно суживает пространство поиска. Если удается правильно понять суть задачи и оптимально разбить ее на сист ему иерархически связанных целей-подцелей, т о можно добит ься минимального пут и решения в прост ранст ве поиска. Альфа-бета алгоритм позволяет уменьшить пространство состояния путем удаления ветвей, неперспект ивных для успешного поиска. Поэт ому являют ся видимыми лишь т е вершины, в кот орые можно попаст ь в результ ат е следующего шага, после чего неперспект ивные направления исключают ся. Альфа-бет а алгорит м нашел широкое применение в основном в сист емах, ориент ированных на разные игры, например в шахмат ных программах Элемент ыэксперт ныхсист ем Эксперт ная сист ема эт о комплекс компьют ерного программного обеспечения, кот орое помогает человеку принимат ь обоснованные решения. Эксперт ные сист емы используют информацию, полученную заранее от эксперт ов людей, кот орые в какой-нибудь област и являют ся лучшими специалист ами. Все эксперт ные сист емы включают, по крайней мере, т ри основных элемент а: базу знаний, машину вывода и инт ерфейс пользоват еля (рис. 11.3). Рисунок 11.3 Элементы экспертной системы База знаний. База знаний содержит извест ные факт ы, выраженные в виде объект ов, атрибутов и условий. Кроме описательных представлений о действительности, она включает выражения неопределенности ограничение на достоверность факта. В этом отношении она от личает ся от т радиционной базы данных вследст вие своего символьного, а не числового или буквенного содержимого. При обработ ке информации базы данных пользуют ся заранее определенными логическими правилами Соот вет ст венно, база знаний, кот орая предст авляет высший уровень абстракции, имеет дело с классами объектов, а не с самыми объектами. База знаний создает ся людьми консульт ант ами. Машина вывода. Главным в эксперт ной сист еме ест ь механизм, кот орый осущест вляет поиск в базе знаний по правилам рациональной логики для получения решений. Эт а машина вывода приводит ся в дейст вие при получении запроса пользоват еля и выполняет т акие задачи: сравнивает информацию, кот орая содержит ся в запросе пользоват еля, с информацией базы знаний; ищет определенную цель или причинные связи; оценивает от носит ельную определенност ь факт ов, опираясь на соот вет ст вующие коэффициент ы доверия, связанные с факт ом. Как следует из ее названия, машина вывода предназначена для пост роения выводов. Ее дейст вие аналогично соображением эксперт а-человека, кот орый оценивает проблему и
83 Тема 12 - Модели знаний 83 предлагает гипот ет ические решения. В поиске целей на основе предложенных правил, машина вывода обращается к базе знаний до тех пор, пока не найдет достоверный путь к получению приемлемого результ ат а. Интерфейс пользователя. Задача инт ерфейса пользоват еля сост оит в организации обмена информацией между операт ором и машиной вывода. Инт ерфейс с использованием ест ест венного языка создает видимост ь произвольной беседы, применяя повседневные выражения в правильно пост роенных предложениях. Очевидно, чт о чем ест ест веннее т акой интерфейс, тем выше требования к внешней и оперативной памяти. Ит ак, сист емы, кот орые предост авляют пользоват елю максимум удобст в, т рат ят больше ресурсов основной машины, дост упных из удаленных рабочих ст анций. Инст румент альные средст ва, предназначенные для работ ы на персональных компьют ерах, кот орые имеют ограниченные возможност и, неизбежно приносят "дружест венност ь" в жерт ву эффект ивност и. Инт ерфейс прямого ввода должен умет ь распознават ь язык, или, по крайней мере, достаточное количество ключевых слов и фраз, чтобы улавливать их связь с данной проблемой и ее предлагаемыми решениями. Аспект человеческий. В работ е с эксперт ными сист емами принимают участ ие как минимум т ри группы людей. Во-первых, админист рация уст анавливает назначение эксперт ной сист емы, ограничивает предметную область, которую должна охватывать система, и точно определяет, какие выгоды организация сможет получат ь из ее использования. Во-вт орых, специалист из сбора знаний (инженер - когнит олог) собирает информацию, необходимую для базы знаний, сравнивает соот вет ст вующие дани и эврист ически организовывает информацию. В-т рет ьих, пот енциальный пользоват ель указывает, как будет использоват ься сист ема, кот орого рода проблемы предст оит решат ь, и каким образом будет осущест влят ься взаимодейст вие программы с оператором. И, в конце концов, системе нужен эксперт (чаще группа экспертов) в определенной предмет ной уст ановленной наглядной област и, для получения от него знаний, как в форме фактической информации, так и относительно аналитических методов, которые применяют ся для решения проблем в эт ой област и. Машинный аспект. Компьют ерную част ь сист емы предст авляют компонент ы программного обеспечения, кот орые обрабат ывают полученную информацию о дейст вит ельност и, заложенной в символьном виде в базу знаний. В базу знаний пост упают факт ы. Связь между факт ами предст авлена эврист ическими правилами выражениями декларат ивного знания об отношениях между объектами. Каждое такое правило имеет составную "если и компонент "то" (вывод-дейст вие), кот орые определяют прямая или обрат ная причинно-следст венная связь. Дейст вит ельные ут верждения лишь дост оверные, другими словами, мера их определенност и не всегда абсолют ная. Количест венные коэффициент ы определенност и увеличивают т очност ь соображения эксперт ных сист ем. Общепринят ая схема заключает ся в т ом, чт обы варьироват ь уровень доверия от 0, чт о предст авляет минимальную меру определенност и, до 100 высшая мера. Выводы Знания связаны с данными, опирают ся на них, но предст авляют результ ат умст венной деят ельност и человека, обобщают его опыт, полученный в ходе выполнения какой-нибудь практ ической деят ельност и. Базы знаний чаще всего используются в контексте экспертных систем, где с них помощью подаются навыки и опыт экспертов, занятых практической деятельностью в соответствующей област и. Современные эксперт ные сист емы работ ают в основном с поверхност ными знаниями. Эт о связано с т ем, чт о на данный момент нет адекват ных моделей, кот орые позволяют работ ат ь с глубинными знаниями. В подавляющем большинст ве сист ем, основанных на знаниях, механизм вывода являет ся небольшой по объему программой и включает два компонент а один реализует собст венный вывод, другой управляет эт им процессом. Дейст вие компонент а вывода основано на использовании правила, кот орое называет ся modus ponens. Машина вывода являет ся основным рабочим компонент ом эксперт ных сист ем, она применяет логику, чет кие рассуждения, уст ановленные правилами, для проверки вывода и получение выводов. Вопросы для самоконтроля 1. Дайт е определение понят ия «Знание». 2. Назовит е основные преобразования знаний при машинной обработ ке? 3. Объясните понятие интенсионал и экстенсионал понятия. 4. Приведит е классификацию знаний. 5. Какие образа получения знаний вы знает е? 6. Дайт е определение базы знаний. 7. Как вы понимаете правило modus ponens? 8. Какие методы вывода вы знаете? 9. Какие ст рат егии управления выводом вы знает е?
84 Тема 12 - Модели знаний Дайт е определение понят ия «Эксперт ная сист ема». 11.Укажите состав экспертной системы? 12.Назовит е основные функции эксперт ной сист емы? Тема 12 - Модели знаний 12 МОДЕЛИ ЗНАНИЙ 12.1 Общие понятия Моделирование процесс предст авления исследуемого объект а некот орой последоват ельност ью других объект ов или предст авлений, кот орые реализуют т е или другие ст ороны изучаемого объект а с необходимой т очност ью. Модель всегда преследует определенную цель, и в зависимост и от цели меняет ся сама модель. Модель никогда не от ображает всю глубину изучаемого объект а. Различают следующие виды моделей: модель предмет ной област и; модель базы данных; модель базы знаний. Каждая модель сохраняет знание о моделируемом фрагмент е предмет ной област и (информационной модели) и выполняет языковую функцию. Эт от языковой компонент имеет большое значение при активизации модели на ЭВМ. Первый этап построения модели связан с выявлением структуры модели на основе априорной информации, а второй этап - с вводом в нее эмпирической информации и являет ся результ ат ом обобщения наблюдений за реальным объект ом. При моделировании знаний и данных сущест вует два аспект а: мат емат ический и инструментальный. С точки зрения математики модель может быть представлена множеством отношений. Возникновение и развитие инструментального аспекта обусловлено тем, что из-за от сут ст вия в т еории банков информации формальных мет одов пост роения моделей, ЭВМ приняла на себя функции построения моделей и стала инструментом построения моделей. Эта модель предназначена для описания на семант ическом (смысловом) уровне ПО и окружающей среды. Она являет ся средст вом инт ерпрет ации содержимого базы знаний. С т очки зрения инст румент ального аспект а моделирования знаний, инт ерес предст авляют языковые средст ва описания модели. Языки предст авления знаний можно разбит ь на т ри группы: логические, реляционные, продукционные. К логическим от носят ся языки, основанные на исчислении выражений и предикат ов. Основой реляционных языков являет ся учет связей (от ношений) между предмет ами реального мира и их свойст вами. Наиболее перспект ивным среди языков данного т ипа являет ся язык основанный на фреймах. Фрейм выст упает как единица информации, кот орая рассмат ривает минимальное необходимое число признаков в описании предмету, без которых этот предмет не существует. Основой языка продукционного типа есть понятия продукции, которая составляется из двух част ей: условия и дейст вия. Условием являет ся описание некот орой сит уации, а дейст вие определяет набор операций, кот орые необходимо осущест вит ь, если входные парамет ры от вечают описанной сит уации Продукционная модель знаний Продукционная модель модель, основанная на правилах, позволяет предст авит ь знание в виде предложений типа «Если (условие), то (действие)». Под «условием» (ант ецедент) понимает ся некот орое предложение-образец, по кот орому осуществляется поиск в базе знаний, а под «действием» (консеквентом) - действия, которые выполняются при успешном результате поиска (они могут быть промежуточными, такими, что наст упают дальше как условия, и т ерминальными или целевыми, кот орые завершают работ у сист емы). Наиболее част ый вывод на т акой базе знаний бывает прямым (от данных до поиска цели) или обратным ( от цели для ее подтверждения - к данным). Данные это исходные факты, хранящиеся в базе фактов, на основании которых запускается
85 Тема 12 - Модели знаний 85 инт ерпрет ат ор правил, перебирающий правила из продукционной базы знаний. Продукционная модель чаще всего применяет ся в промышленных эксперт ных сист емах. Она привлекает разработ чиков своей наглядност ью, высокой модульност ью, легкост ью внесения дополнений и изменений и прост от ой механизма логического вывода. Сущест вует большое количест во программных средст в, кот орые реализуют продукционный подход Семантическая модель знаний Термин семант ическая означает «смысловая», а самая семант ика эт о наука, кот орая уст анавливает от ношение между символами и объект ами, кот орые они обозначают, т о ест ь наука, которая определяет смысл знаков. Сеть это ориентированный граф, вершины которого понят ие, а дуги от ношение между ними. Как понят ия по обыкновению выст упают абстрактные или конкретные объекты, а отношения это связи типа: «это» («АКО A-kind-of» «is»), «имеет частью» («has part»), «принадлежит», «любит». Характерной особенностью семантических сетей является обязательное наличие трех типов от ношений: класс элемент класса (цветок роза); свойство значение (цвет желтый); пример элемент а класса (роза чайная). Можно предложит ь несколько классификаций семант ических сет ей, связанных с т ипами от ношений между понят иями. По количест ву т ипов от ношений: 1. Однородные (с единст венным т ипом от ношений). 2. Неоднородные (с разными т ипами от ношений). По типами отношений: 1. Бинарные (у кот орых от ношения связывают два объект а). 2. N-арные (в кот орых ест ь специальные от ношения, кот орые связывают больше двух понятий). Чаще всего в семант ических сет ях используют ся т акие от ношения: связи типа «часть целое» («класс подкласс», «элемент множество» и т.д.); функциональные связи, кот орые определяют ся по обыкновению глаголами выполняет, количест венные (больше, меньше, равняет ся); пространственные (далеко от, близко от, за, под, над); времени (раньше, позднее, на прот яжении); атрибутивные связи (иметь свойство, иметь значения); логические связи (И, ИЛИ, НЕ); лингвист ические связи и др. Проблема поиска решения в базе знаний типа семантической сети сводится к задаче поиска фрагмента сети, которая отвечает некоторой подсети, что отображает поставленный запрос. Пример. На рис предст авленна семант ическая сет ь. Как вершины здесь выст упают понят ия «ЭВМ ПЕОМ - Ноут бук», «Toshiba Satellite C660-1EM», «Процессор» и «Мат еринская плат а». Данная модель предст авления знаний была предложена американским психологом Киллианом. Основным ее преимущест вом являет ся т о, чт о она более других от вечает современным предст авлениям об организации продолжит ельной памят и человека. Недост ат ком эт ой модели ест ь сложност ь организации процедуры поиска вывода на семант ической сет и. Для реализации семант ических сет ей сущест вуют специальные сет евые языки, например NET (Цейт ин, 1985), язык реализации сист ем Simer+mir (Осипов, 1997) и др. Широко извест ные эксперт ные сист емы, кот орые используют семант ические сет и как язык предст авления знаний, - PROSPECTOR, CASNET, TORUS (Хейес-Рот и др. 19S7; Durkin, 1998). Рисунок 12.1 Семантическая сеть 12.4 Фрейм Термин фрейм (от английской «frame», чт о означает «каркас» или «рамка») был предложенный Марвином Ли Минским в 70-ые года как обозначения ст рукт уры знаний для восприят ия прост ранст венных сцен. Эт а модель, как и семант ическая сет ь, имеет глубокое психологическое обоснование. Фрейм эт о абст ракт ный образ для предст авления некот орого ст ереот ипа. Например, проговаривание вслух слова «комнат а», порождает у слушающих образ комнат ы:
86 Тема 12 - Модели знаний 86 «помещение с чет ырьмя ст енами, полом, пот олком, окнами и дверями, определенной площади». Из этого описания ничего нельзя убрать (например, убрав окна, мы получим уже каморку, а не комнат у), но в нем ест ь «дырки» или «слот ы» эт о незаполненные значения некот орых ат рибут ов например, количест во окон, цвет ст ен, высот а пот олка, покрыт ие пола и др. В теории фреймов такой образ комнаты называется фреймом комнаты. Фреймом т акже называет ся и формализованная модель для от ображения образа. Различают фреймы-образцы, или прот от ипы, кот орые хранят ся в базе знаний, и фреймы-экземпляры, кот орые создают ся для от ображения реальных факт ических сит уаций на основе данных, которые поступают. Модель фрейма являет ся довольно универсальной, поскольку позволяет от ображат ь все многообразие знаний о мире через т акие элемент ы: фреймы-ст рукт уры, кот орые используют ся для обозначения объект ов и понят ий (заем, залог, вексель); фреймы-роли (менеджер, кассир, клиент); фреймы-сценарии (банкрот ст во, собрание акционеров, празднование именин); фреймы-сит уации (т ревога, авария, рабочий режим уст ройст ва) и др. Традиционно структура фрейма может быть представлена как список свойств: (ИМЯ ФРЕЙМА; (имя 1-го слота; значение 1-го слота), (имя 2-го слота: значение 2-го слота), (имя N-го слота: значение N-гo слота)). При использовании т абличной формы предст авления фрейма можно использоват ь дополнит ельные ст олбцы, предназначенные для описания способа получения слот ом его значения и возможного присоединения к т ому или другому слот у специальных процедур, который допускается в теории фреймов. Как значение слот а может выст упат ь имя другого фрейма, т ак образовывают ся сет и фреймов. Сущест вует несколько способов получения слот ом значений в фрейме-экземпляре: по умолчанию от фрейма-образца ( Default-Значение); через наследственность свойств от фрейма, указанного в слоте АКО; по формуле, указанной в слот е; через присоединенную процедуру; явным образом из диалога с пользоват елем; из базы данных. Самым важным свойст вом т еории фреймов ест ь заимст вования из т еории семант ических сет ей т ак называемая наследст венност ь свойст в. Наследст венност ь происходит по АКОсвязях (A Kind of = это). Слот АКО указывает на фрейм более высокого уровня иерархии, откуда неявно наследуют ся, т о ест ь переносят ся, значение аналогичных слот ов. Пример. На рис приведен пример фреймовой модели иерархического т ипа. Фреймы образовывают иерархию, последняя порождает многоуровневую ст рукт уру, описывающую или объект при условии описания слот ами лишь свойст в объект а, или сит уацию или процесс при условии описания от дельными слот ами процедур, кот орые подсоединенные к фрейму и вызывают ся после него акт уализации. Рисунок 11.2 Фреймовая модель