Г. П. Токмаков АВТОМАТИЗИРОВАННОЕ ...venec.ulstu.ru/lib/disk/2015/167.pdf · 2015. 10. 2. · Пособие предназначено для студентов

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ федеральное государственное бюджетное образовательное учреждение

высшего профессионального образования «УЛЬЯНОВСКИЙ ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ»

Г. П. Токмаков

АВТОМАТИЗИРОВАННОЕ ПРОЕКТИРОВАНИЕ

ИНФОРМАЦИОННЫХ СИСТЕМ

Учебное пособие

Ульяновск УлГТУ

2015

Рецензенты: д-р техн. наук, профессор Егоров Ю. П.; канд. техн. наук Царевский А. В.

Утверждено редакционно-издательским советом университета в качестве учебного пособия

УДК 004.9(075) ББК 32.973-018.2я73 Т 51

Токмаков, Г. П. Т 51 Автоматизированное проектирование информационных сис-

тем: учебное пособие / Г. П. Токмаков. – Ульяновск : УлГТУ, 2015. − 121 с.

ISBN 978-5-9795-1406-2 Учебное пособие подготовлено по материалам лекционных курсов по

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

Пособие предназначено для студентов специальности 230100, а также может использоваться студентами специальностей 230400 и 231000.

УДК 004.9(075)

ББК 32.973-018.2я73 Токмаков Г. П., 2015 ISBN 978-5-9795-1406-2 Оформление. УлГТУ, 2015

3

ОГЛАВЛЕНИЕ

ПРЕДИСЛОВИЕ…………………………………………………..……6

КОНТРОЛЬНЫЕ ВОПРОСЫ .................................................................. 9

ГЛАВА 1. ВВЕДЕНИЕ В ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННЫХ СИСТЕМ .................................................... 10

1.1 ОСНОВЫ СОЗДАНИЯ И ФУНКЦИОНИРОВАНИЯ ИНФС .... 11 1.1.1 Основные понятия ИнфС ........................................................ 11 1.1.2 Проблемы проектирования ИнфС .......................................... 12

1.2 ЭТАПЫ РАЗРАБОТКИ ИНФС ...................................................... 13 1.2.1 Предпроектный этап: формирование требований к системе ................................................................................................ 13 1.2.2 Проектирование ИнфС ............................................................ 14 1.2.3 Разработка приложений, тестирование и отладка ИнфС ..... 14 1.2.4 Развертывание ИнфС ............................................................... 14

1.3 СТАДИИ ПРОЕКТИРОВАНИЯ ИНФС ........................................ 14 1.3.1 Концептуальное (Инфологическое) проектирование ........... 16 1.3.2 Логическое проектирование .................................................... 17 1.3.3 Физическое проектирование ................................................... 18

КОНТРОЛЬНЫЕ ВОПРОСЫ ................................................................ 18

ГЛАВА 2. ПРОЕКТИРОВАНИЕ РЕЛЯЦИОННЫХ БАЗ ДАННЫХ С ИСПОЛЬЗОВАНИЕМ СЕМАНТИЧЕСКИХ МОДЕЛЕЙ: МОДЕЛЬ «СУЩНОСТЬ-СВЯЗЬ» ............................. 19

2.1 МЕТОДОЛОГИЧЕСКАЯ ОСНОВА РЕАЛИЗАЦИИ МОДЕЛИ «СУЩНОСТЬ-СВЯЗЬ» ........................................................................... 20

2.1.1 Методологии и стандарты моделирования сложных систем .................................................................................................. 20 2.1.2 Методология IDEF1X .............................................................. 21 2.1.3 Преимущества IDEF1X ............................................................ 22

2.2 ОСНОВНЫЕ ЭЛЕМЕНТЫ СЕМАНТИЧЕСКОЙ МОДЕЛИ ENTITY-RELATIONSHIP (СУЩНОСТЬ-СВЯЗЬ) .............................. 23

2.2.1 Атрибуты ................................................................................... 23 2.2.2 Сущности................................................................................... 27 2.2.3 Отношения ................................................................................ 34 2.2.4 Подтипы и супертипы сущностей .......................................... 39

4

2.3 ПОЛУЧЕНИЕ РЕЛЯЦИОННОЙ СХЕМЫ ИЗ ER-ДИАГРАММЫ ............................................................................ 41 КОНТРОЛЬНЫЕ ВОПРОСЫ ................................................................ 43

ГЛАВА 3. ПРОЕКТИРОВАНИЕ РЕЛЯЦИОННЫХ БАЗ ДАННЫХ С ИСПОЛЬЗОВАНИЕМ СЕМАНТИЧЕСКИХ МОДЕЛЕЙ: ДИАГРАММЫ КЛАССОВ ЯЗЫКА UML ................ 45

3.1 ВВЕДЕНИЕ ...................................................................................... 45 3.2 ОСНОВНЫЕ ПОНЯТИЯ ДИАГРАММ КЛАССОВ UML .......... 46

3.2.1 Классы ....................................................................................... 47 3.2.2 Атрибуты ................................................................................... 47 3.2.3 Операции ................................................................................... 48

3.3 ЗАВИСИМОСТИ, ОБОБЩЕНИЯ И АССОЦИАЦИИ ................ 49 3.3.1 Зависимости .............................................................................. 49 3.3.2 Обобщения и механизм наследования классов ..................... 50 3.3.3 Ассоциации: роли, кратность, агрегация, композиция ........ 51

3.4 ОГРАНИЧЕНИЯ ЦЕЛОСТНОСТИ И ЯЗЫК OCL ...................... 55 3.4.1 Общая характеристика языка OCL ......................................... 56 3.4.2 Инвариант класса ..................................................................... 57 3.4.3 Операции над множествами, мультимножествами и последовательностями....................................................................... 59 3.4.4 Примеры инвариантов ............................................................. 60 3.4.5 Плюсы и минусы использования языка OCL при проектировании реляционных баз данных ..................................... 63

3.5 ПОЛУЧЕНИЕ СХЕМЫ РЕЛЯЦИОННОЙ БАЗЫ ДАННЫХ ИЗ ДИАГРАММЫ КЛАССОВ UML .......................................................... 63 КОНТРОЛЬНЫЕ ВОПРОСЫ ................................................................ 64

ГЛАВА 4. МОДЕЛИРОВАНИЕ ДАННЫХ В ФОРМАЛИЗМЕ СПЕЦИФИКАЦИИ XSD...................................................................... 65

4.1 XML КАК СПОСОБ ЛОГИЧЕСКОГО ПРЕДСТАВЛЕНИЯ ИНФОРМАЦИИ ...................................................................................... 65

4.1.1 Становление языка XML ........................................................... 65 4.1.2 Простой пример XML-документа .......................................... 67 4.1.3 XML-процессоры ..................................................................... 69

4.2 ОПРЕДЕЛЕНИЕ XML-СХЕМЫ .................................................... 71 4.2.1 Простые и сложные типы ........................................................ 71 4.2.2 Кардинальность ........................................................................ 72 4.2.3 Определение новых типов ....................................................... 73 4.2.4 Элементы-составители Choice и All ....................................... 74

5

4.2.5 Ограничения .............................................................................. 74 4.2.6 Пример XML-схемы ................................................................. 76

4.3 СТИЛИ И ФОРМАТИРОВАНИЕ ДАННЫХ XML ..................... 79 КОНТРОЛЬНЫЕ ВОПРОСЫ ................................................................ 85

ГЛАВА 5. АВТОМАТИЗАЦИЯ ПРОЕКТИРОВАНИЯ И РАЗРАБОТКИ ИНФОРМАЦИОННЫХ СИСТЕМ НА ОСНОВЕ XML-ТЕХНОЛОГИЙ ................................................. 86

5.1 МОДЕЛИРОВАНИЕ ДАННЫХ НА БАЗЕ XSD .......................... 86 5.1.1 XSD-модель компонента Resource ......................................... 86 5.1.2 Композиция против агрегации ................................................ 91

5.2 ПРОЕКТИРОВАНИЕ КОМПОНЕНТОВ СИСТЕМЫ НА ОСНОВЕ XML-СХЕМЫ ........................................................................ 95

5.2.1 Генерирование шаблона экземпляра XML-документа ........ 96 5.2.2 Генерирование постоянного хранилища данных ................. 98 5.2.3 Создание пользовательского интерфейса .............................. 99 5.2.4 Отображение XML-документа в базу данных .................... 104 5.2.5 Отображение базы данных в XML-документ ..................... 106

5.3 ПРЕОБРАЗОВАНИЕ XML-СХЕМЫ В ДИАГРАММУ КЛАССОВ UML ................................................................................... 107 КОНТРОЛЬНЫЕ ВОПРОСЫ .............................................................. 109

ЗАКЛЮЧЕНИЕ ................................................................................... 110

СПИСОК ЛИТЕРАТУРЫ ................................................................. 112

ГЛОССАРИЙ ....................................................................................... 113

ПРЕДМЕТНЫЙ УКАЗАТЕЛЬ ......................................................... 119

6

ПРЕДИСЛОВИЕ

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

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

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

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

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

– необходимость интеграции существующих и вновь разрабаты-ваемых приложений;

– функционирование в неоднородной среде на нескольких аппа-ратных платформах;

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

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

7

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

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

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

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

ные качества; – затяжной цикл и неудовлетворительные результаты тестирова-

ния. Потребности разработчиков ИнфС в более удобных и мощных

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

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

8

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

Развитие семантических моделей данных привело к появлению программно-технологических средств специального класса − CASE-средств, реализующих автоматизированную технологию создания и сопровождения ИнфС. Термин CASE (Computer Aided Software Engineering) используется в настоящее время в весьма широком смысле. Под тер-мином CASE-средства понимаются программные средства, поддержи-вающие процессы создания и сопровождения ИнфС, включая проек-тирование баз данных, генерацию кода, тестирование, документиро-вание, обеспечение качества, а также другие процессы. CASE-средства вместе с системным программным обеспечением и техническими средствами образуют полную среду разработки ИнфС.

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

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

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

CASE-системы позволяют естественно (и достаточно просто) пройти путь от интуитивного представления структуры и поведения

9

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

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

КОНТРОЛЬНЫЕ ВОПРОСЫ 1. Каковы особенности современных крупных проектов ИнфС? 2. Каковы недостатки ручной разработки ИнфС? 3. Какая связь между семантическими моделями данных и CASE-

технологиями?

10

ГЛАВА 1. ВВЕДЕНИЕ В ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННЫХ СИСТЕМ

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

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

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

– существенное повышение скорости разработки за счет мощного редактора диаграмм, автоматической генерации базы данных, автома-тической подготовки документации;

– нет необходимости ручной подготовки SQL-предложений для создания базы данных;

– возможность легко вносить изменения в модель при разработке и расширении системы;

– возможность автоматической подготовки отчетов по базе дан-ных; важно, что эти отчеты всегда в точности соответствуют реальной структуре БД;

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

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

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

11

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

1.1 ОСНОВЫ СОЗДАНИЯ И ФУНКЦИОНИРОВАНИЯ ИНФС

1.1.1 ОСНОВНЫЕ ПОНЯТИЯ ИНФС Информационная система − организационно-упорядоченная со-

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

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

– структуру, представленную множеством элементов системы и взаимосвязями между ними;

– функцию каждого элемента, а также системы в целом; – цели и ограничения системы, задаваемые материальными и ин-

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

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

– свойство целостности указывает на согласование целей функ-ционирования всей системы с целями ее подсистем и элементов.

В процессе декомпозиции ИнфС на подсистемы выделяют функ-циональную и обеспечивающую части.

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

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

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

Программное обеспечение − это совокупность программ на но-сителях информации с программной документацией [3].

12

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

Информационное обеспечение (ИО) автоматизированной систе-мы – это совокупность форм документов, классификаторов, норма-тивной базы и реализованных решений по объемам, размещению и формам существования информации, применяемой в автоматизи-рованной системе (АС) [2].

ИО включает в себя внемашинное и внутримашинное обеспечение. В н е м а ш и н н о е И О составляют унифицированная система

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

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

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

1.1.2 ПРОБЛЕМЫ ПРОЕКТИРОВАНИЯ ИНФС Под проектом ИнфС понимается комплекс проектно-конструк-

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

Под проектированием ИнфС подразумевается процесс преобра-зования входной информации об объекте проектирования в проект ИнфС.

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

13

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

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

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

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

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

– аналитик сталкивается с чрезмерным количеством подробных сведений о предметной области и о новой системе;

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

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

1.2 ЭТАПЫ РАЗРАБОТКИ ИНФС Прежде чем приступить к рассмотрению вопросов автоматизи-

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

– предпроектный; – проектирования ИнфС; – разработки приложений ИнфС; – тестирования и отладки приложений ИнфС; – развертывания ИнфС.

1.2.1 ПРЕДПРОЕКТНЫЙ ЭТАП: ФОРМИРОВАНИЕ ТРЕБОВАНИЙ К СИСТЕМЕ Предпроектный этап включает в себя обследование или систем-

ный анализ предметной области и разработку технического задания на ИнфС.

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

14

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

ническое задание на ИнфС. Работы на предпроектном этапе выполняются, как правило, в об-

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

1.2.2 ПРОЕКТИРОВАНИЕ ИНФС На этапе проектирования ИнфС готовятся модели будущего про-

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

Ниже, в подразделе 1.3, данный этап проектирования будет рас-смотрен более подробно.

1.2.3 РАЗРАБОТКА ПРИЛОЖЕНИЙ, ТЕСТИРОВАНИЕ И ОТЛАДКА ИНФС Этапы разработки приложений, их тестирование и отладка отно-

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

1.2.4 РАЗВЕРТЫВАНИЕ ИНФС Этап развертывания заключается в установлении ИнфС на объек-

тах заказчика, также не относится к сфере нашей дисциплины.

1.3 СТАДИИ ПРОЕКТИРОВАНИЯ ИНФС Итак, предметом нашей дисциплины являются этап проектирова-

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

15

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

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

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

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

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

Описанные на ЕЯ(инфологическая модель)

Формализация абстракт-ных понятий в терминах типизированных данных

Преобразование типизи-рованных данных в ма-шинное представление

Формализация абстрактных понятий в тер-минах типизированных данных выполняется

разработчиком с помощью CASE-средства

Выполняется CASE-средством автоматически

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

Физическая модель

Логическая модель

Рис. 1.1 Стадии и объекты процесса проектирования БД

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

16

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

2. Далее это описание отображается в компьютерно-ориентиро-ванное представление, относящееся к логической области моделиро-вания.

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

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

1.3.1 КОНЦЕПТУАЛЬНОЕ (ИНФОЛОГИЧЕСКОЕ) ПРОЕКТИРОВАНИЕ Начальной стадией проектирования информационной системы

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

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

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

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

17

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

Таким образом, концептуальные модели обладают следующими особенностями:

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

зированной обработки; – дружественностью, обеспечивающей возможность использова-

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

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

1.3.2 ЛОГИЧЕСКОЕ ПРОЕКТИРОВАНИЕ Так как доступ к данным осуществляется с помощью конкретной

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

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

В общем случае на этапе логического проектирования: – принимают решение об интеграции в БД всех или части данных

предметной области; – выбирают модель данных (иерархическую, сетевую, реляцион-

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

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

18

возможность развития проектируемой компьютерной информацион-ной системы.

1.3.3 ФИЗИЧЕСКОЕ ПРОЕКТИРОВАНИЕ Задачей следующей стадии проектирования системы является

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

– разработку спецификации внутренней схемы средствами модели данных ее внутреннего уровня;

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

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

КОНТРОЛЬНЫЕ ВОПРОСЫ 1. Каковы преимущества, получаемые при применении CASE-

средств? 2. Дайте определение информационной системы и перечислите ее

компоненты. 3. Опишите части информационной системы. 4. Дайте определение проекта и процесса проектирования ИнфС. 5. Каковы этапы процесса проектирования и разработки ИнфС? 6. Каковы стадии проектирования ИнфС? 7. Дайте определение концептуального (инфологического) проек-

тирования. 8. Дайте определение логического проектирования. 9. Дайте определение физического проектирования.

19

ГЛАВА 2. ПРОЕКТИРОВАНИЕ РЕЛЯЦИОННЫХ БАЗ ДАННЫХ С ИСПОЛЬЗОВАНИЕМ СЕМАНТИЧЕСКИХ МОДЕЛЕЙ: МОДЕЛЬ «СУЩНОСТЬ-СВЯЗЬ»

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

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

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

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

Может возникнуть вопрос, почему мы говорим про «автоматизи-рованное», а не про «автоматическое» преобразование? Все дело в том, что в типичной схеме SQL-ориентированной БД могут содер-жаться определения многих объектов (ограничений целостности об-

20

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

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

В этой главе мы рассмотрим наиболее популярную (на сегодняш-ний день) семантическую модель данных, предложенную Питером Ченом (Peter Chen) в 1976 г., на основе которой и были реализованы CASE-средства. Эту модель называют ER-моделью (Entity-Relationship) или моделью «Сущность-Связь». На использовании разных вариантов ER-модели основано большинство современных подходов к проекти-рованию баз данных (главным образом, реляционных).

2.1 МЕТОДОЛОГИЧЕСКАЯ ОСНОВА РЕАЛИЗАЦИИ МОДЕЛИ «СУЩНОСТЬ-СВЯЗЬ»

2.1.1 МЕТОДОЛОГИИ И СТАНДАРТЫ МОДЕЛИРОВАНИЯ СЛОЖНЫХ СИСТЕМ С появлением на рынке сложных программных продуктов, пред-

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

Комплексные обследования предприятий всегда являются слож-ными и существенно отличающимися от случая к случаю задачами. Но для решения задач моделирования сложных систем существуют хорошо обкатанные методологии и стандарты [6]. К таким стандартам относятся методологии семейства IDEF. С их помощью можно эффек-тивно отображать и анализировать модели деятельности широкого спектра сложных систем в различных разрезах. В настоящий момент к семейству IDEF можно отнести следующие стандарты (здесь приве-дены только некоторые из них):

– IDEF0 – методология функционального моделирования. С помо-щью наглядного графического языка IDEF0 изучаемая система пред-стает перед разработчиками и аналитиками в виде набора взаимосвя-

21

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

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

– IDEF1X (IDEF1 Extended) – методология построения реляционных структур. IDEF1X относится к типу методологий «Сущность-взаимосвязь» (ER – Entity-Relationship) и, как правило, используется для моделирова-ния реляционных баз данных, имеющих отношение к рассматривае-мой системе;

– IDEF2 – методология динамического моделирования развития систем. В связи с весьма серьезными сложностями анализа динамиче-ских систем от этого стандарта практически отказались, и его разви-тие приостановилось на самом начальном этапе;

– IDEF3 – методология документирования процессов системы; – IDEF4 – методология построения объектно-ориентированных

систем; – IDEF5 – методология онтологического исследования сложных

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

2.1.2 МЕТОДОЛОГИЯ IDEF1X В рамках данного курса лекций рассмотрим только методологию

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

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

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

22

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

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

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

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

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

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

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

2.1.3 ПРЕИМУЩЕСТВА IDEF1X Основным преимуществом IDEF1X, по сравнению с другими мно-

гочисленными методами разработки реляционных баз данных, явля-ется жесткая и строгая стандартизация моделирования. Установлен-

23

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

2.2 ОСНОВНЫЕ ЭЛЕМЕНТЫ СЕМАНТИЧЕСКОЙ МОДЕЛИ ENTITY-RELATIONSHIP (СУЩНОСТЬ-СВЯЗЬ) Наиболее известной семантической моделью данных, реализо-

ванной на основе методологии IDEF1X, является ER-модель. Основны-ми понятиями ER-модели являются атрибуты, сущности и связи.

2.2.1 АТРИБУТЫ Атрибуты описывают характеристики сущностей, представляются

именами существительными и служат для описания состояния экзем-пляра сущности. Конкретным экземпляром атрибута является значе-ние. Например, атрибут с названием ИМЯ задает область определения для фактов о сущности с названием ПЕРСОНА. Примеры конкретных значений имени для конкретных экземпляров ПЕРСОНЫ − Федор, Де-нис, Иван и Петр.

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

Но имеется и важное отличие. Напомним, что в реляционной моде-ли данных атрибут определяется как упорядоченная пара <имя_атрибута, имя_ домена> или <имя_атрибута, тип_данных>. Заголовок отношения, оп-ределяемый как множество таких пар, представляет собой полный ана-лог структурного типа данных в языках программирования. При опре-делении атрибутов в ER-модели указание доме-на атрибута не является обязательным, хотя это и возможно.

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

Рис. 2.1. Первичные ключи

Имя сущности/№Сущности

Первичный_ключ_1 (PK)

. . .Имя_атрибута_j

Имя_атрибута_N

Имя_атрибута_1

. . .

. . .Первичный_ключ_М (PK)

24

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

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

2.2.1.1 К л а с с и ф и к ац и я а т р и б ут о в Атрибуты делятся на две группы и являются либо ключом, либо

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

значения других атрибутов. Значения ключевых атрибутов не зависят от значений никаких других атрибутов.

Ключевые атрибуты, в свою очередь, подразделяются на: – первичные ключи; – составные первичные ключи; – искусственные первичные ключи; – альтернативные ключи; – внешние ключи. Первичным ключом служит атрибут или набор атрибутов, уни-

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

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

25

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

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

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

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

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

Рис. 2.2. Примеры внешних ключейа) б)

Пример внешнего ключа -неключевого атрибута

Пример внешнего ключа -ключевого атрибута

Номер_брокера (PK)

Номер_отдела (FK)Имя_атрибутаИмя_атрибутаИмя_атрибута

. . .

Номер_заказа (PK)Номер_товара (FK)

Имя_атрибутаИмя_атрибутаИмя_атрибута

. . .

26

Обратите внимание на термин «связанная сущность». Он отра-жает тот факт, что внешние ключи представляют связи между сущно-стями.

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

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

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

2.2.1.2 О б л а с т ь о п р е д е л е н и я а т р и б ут а Область определения атрибута задает список разрешенных значе-

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

В следующем списке приведено несколько примеров логических типов данных ERwin:

– Datetime – дата/время; – Number – число; – String – строка. Многие из новых платформ баз данных поддерживают более раз-

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

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

27

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

2.2.2 СУЩНОСТИ Сущности служат для визуального представления логической

группировки атрибутов и соответствуют таблицам реляционной мо-дели данных. Сущностями могут быть вещественные объекты, такие как ПЕРСОНА или КНИГА, но они могут представлять и абстрактные концепции, такие как прием заказов или размещение клиентов в гос-тинице.

В диаграммах ER-модели сущность представляется в виде прямо-угольника, содержащего имя сущности. При этом имя сущности – это имя типа, а не некоторого конкретного экземпляра этого типа.

2.2.2.1 К л а с с и ф и к ац и я с у щ н о с т ей В модели ER различаются две группы сущностей: зависимые и не-

зависимые. Независимая сущность не нуждается в информации из другой

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

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

Зависимые и независимые сущности разделяются на несколько типов:

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

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

– ассоциативные сущности − эти сущности используются для оп-ределения отношений типа «многие-ко-многим».

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

28

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

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

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

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

2.2.2.2 В ы д е л е н и е с у щ н о ст е й Как было отмечено выше, сущности представляют собой логиче-

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

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

29

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

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

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

Широко используются пять нормальных форм. Эти формы назы-ваются просто: первая, вторая, третья и четвертая нормальные формы. На практике многие логические модели приводятся только к 3НФ.

Приведем простые правила нормализации: 1. Размещайте повторяющиеся атрибуты в

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

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

первичного ключа, в зависимых сущностях. 4. Устраняйте отношения «многие ко мно-

гим». Процесс нормализации данных рассмотрим

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

1. Размещение повторяющихся атрибутов в зависимых сущностях. Повторяющимися группами являются атрибуты, которые для каж-дого экземпляра сущности могут иметь более

Рис. 2.3 В сущнос-ти используются повторяющиеся группы

Код персоны

ФамилияИмяОтчествоСпециальность1Квалификация1Специальность2Квалификация2Название школыГеографический район

.

30

одного значения. Например, ПЕРСОНА может иметь более одной спе-циальности. Допустим, что нам нужно знать уровень владения специ-альностью для каждой ПЕРСОНЫ, и каждая ПЕРСОНА может иметь не более двух специальностей. Проблема повторяющихся групп за-ключается в том, что мы не можем точно знать, сколько спе-циальностей может иметь персона. В реальной жизни у некото-рых людей есть одна специальность, у некоторых − несколько, а у не-которых − пока ни одной.

Рис. 2.4. Модель, приведенная к первой нормальной форме

а)

б)

Ненормализованная сущность

СПЕЦИАЛЬНОСТЬ ПЕРСОНЫПЕРСОНА


Специальность Квалификация

Код специальностиКод персоны

ФамилияИмяОтчествоНазвание школыГеографический район

ПЕРСОНАКод персоны


В этом случае мы можем создать сущность СПЕЦИАЛЬНОСТЬ ПЕР-

СОНЫ, показанную на рис. 2.4б. Здесь, на рис. 2.4а, а также на после-дующих рисунках данного раздела, для сравнения представлена сущ-ность ПЕРСОНА исходной, ненормализованной базы данных.

На рис. 2.4б представлена модель, приведенная к первой нор-мальной форме. Обратите внимание: добавленный «Код специально-сти» уникально определяет каждую СПЕЦИАЛЬНОСТЬ.

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

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

31

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

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

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

В предыдущем примере сущность СПЕЦИАЛЬНОСТЬ ПЕРСОНЫ за-висит от атрибутов «Код персоны» и «Код специальности». Это значит, что у вас не появится СПЕЦИАЛЬНОСТЬ до тех пор, пока не появится ПЕРСОНА, обладающая этой специальностью. Это так же усложняет


ПЕРСОНА

Рис. 2.5. Во второй нормальной форме повторяющаяся группа вынесена в другую сущность



СпециальностьКод специальности

СПЕЦИАЛЬНОСТЬПЕРСОНАКод персоны

ФамилияИмяОтчествоНазвание школыГеографический район

СПЕЦИАЛЬНОСТЬ ПЕРСОНЫ


Квалификация Код специальности

32

изменение атрибута «Специальность». При изменении наименования необходимо найти каждую запись с названием специальности и изме-нить ее для каждой ПЕРСОНЫ, владеющей этой специальностью.

На рис. 2.5 представлена модель во второй нормальной форме. Заметьте, что добавлена сущность СПЕЦИАЛЬНОСТЬ, и атрибут «Специ-альность» перенесен в эту сущность. Уровень владения специально-стью, т. е. квалификация, остается и относится к сущностям ПЕРСОНА и СПЕЦИАЛЬНОСТЬ. В данном случае в сущности «Специальность» при-веден весь перечень наименований специальностей независимо от то-го, владеет сотрудник школы этой специальностью или нет. В случае изменения наименования специальности изменяется только значение поля специальности одной записи сущности «Специальность».




ШКОЛА

Название школыКод школы

Код района

ПЕРСОНА

Код персоныФамилияИмяОтчествоИдентификатор школы

СпециальностьКод специальностиСПЕЦИАЛЬНОСТЬ

ГЕОГРАФИЧЕСКИЙ РЕГИОН

Имя районаКод района


Рис. 2.6. Модель, приведенная к третьей нормальной форме

ПЕРСОНАКод персоны


Приведение ко второй нормальной форме означает удаление избы-

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

33

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

3. Каждый атрибут зависит от ключа. Каждый атрибут сущ-ности должен зависеть от первичного ключа этой сущности. В преды-дущем примере атрибуты «Название школы» и «Географический район» присутствуют в таблице ПЕРСОНА, но не описывают персону. Для достижения третьей нормальной формы необходимо переместить ат-рибуты в сущность, где они будут зависеть от ключа (см. Рис. 2.6).


ПЕРСОНА

ПЕРСОНА


ФамилияИмяОтчество

Рис. 2.7. Модель, приведенная к четвертой нормальной форме

ШКОЛА

Название школыКод школы

Код района

ШКОЛА ПЕРСОНЫ

Код школыКод персоны

СпециальностьКод специальности

СПЕЦИАЛЬНОСТЬ

ГЕОГРАФИЧЕСКИЙ РЕГИОН

Имя районаКод района






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

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

34

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

В данном примере правило 3 применяется дважды: – сначала по отношению к сущности ПЕРСОНА с образованием но-

вой сущности ШКОЛА; – затем по отношению к сущности ШКОЛА с образованием сущно-

сти ГЕОГРАФИЧЕСКИЙ РАЙОН. 4. Отношения «многие ко многим». Обратите внимание, что на

рис. 2.6 существует отношение «многие ко многим» между ПЕРСОНОЙ и ШКОЛОЙ. Это отношение отражает тот факт, что ПЕРСОНА может ра-ботать во многих ШКОЛАХ, а в ШКОЛЕ может работать много ПЕРСОН.

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

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

2.2.3 ОТНОШЕНИЯ Отношение или связь – это графически изображаемая ассоциация,

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

В ER-модели отношение представляется линией, соединяющей две сущности, и глагольной конструкцией, которая описывает, как две сущности зависят друг от друга. Глагольная конструкция – это механизм описания бизнес-правил, определяющих отношение. Хоро-шая глагольная конструкция описывает отношение в терминах пред-метной области, а не на языке технических спецификаций. Глагольная конструкция, описывающая взаимосвязь, позволяет вам прочесть от-ношение в форме «Сущность – Глагольная_конструкция – Сущность».

35

Приведем примеры: – поскольку каждый сотрудник работает в каком-либо отделе,

между сущностями СОТРУДНИК и ОТДЕЛ существует связь «работает в», что можно прочитать как «СОТРУДНИК работает в ОТДЕЛ»;

– так как один из работников отдела является его руководителем, то между сущностями СОТРУДНИК и ОТДЕЛ имеется связь «руководит» или «СОТРУДНИК руководит ОТДЕЛ»;

– могут существовать и связи между сущностями одного типа, на-пример, связь РОДИТЕЛЬ-ПОТОМОК между двумя сущностями ЧЕЛО-ВЕК.

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

2.2.3.1 С в о й с т в а о т н о ш е н и й Отношение обладает следующими свойствами: – степенью; – направленностью; – количеством элементов. Степень отношения представляет собой число сущностей, ассо-

циированных с отношением. В основном отношения имеют степень единица (унарные отношения) или двойка (бинарные отношения).

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

Унарные, или рекурсивные, отношения представляют случаи, ко-гда экземпляр сущности связан с другим экземпляром той же самой сущности. Рассмотрим в качестве примера сущность Служащий с по-лями Код.служащего, Фамилия, Имя и Отчество.

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

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

СЛУЖАЩИЙКод служащего

Фамилия

Имя

Отчество

Начальник.Код _служащего (FK)

Рис. 2.8. Унарная связь

36

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

Таким образом, формируется связь «Код служащего – Начальник.Код служащего». Смысл этой связи заключается в том, что значение атри-бута Начальник.Код служащего указывает на идентификатор служащего, который является начальником для данного служащего. Для высшего руководителя в поле Начальник.Код служащего содержится псевдозначе-ние NULL.

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

В отношении между независимой и зависимой сущностями отно-шение исходит из независимой и заканчивается в зависимой сущно-сти. Если обе сущности независимые, отношение симметрично. В от-ношении «один ко многим» родительской является сущность, входя-щая в отношение однократно. Отношения «многие ко многим» сим-метричны.

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

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

– «один ко многим» (1:N) – один экземпляр родительской сущно-сти связан со многими экземплярами подчиненной сущности. Сущ-ность, входящая в отношение единственным экземпляром, является родительской или исходной сущностью. Сущность, входящая в отно-шение многими экземплярами, является подчиненной или дочерней сущностью. Иногда бывает полезно определить возможное количест-во экземпляров сущности, участвующих в данной связи (например, ввести ограничение, связанное с тем, что служащему разрешается участвовать не более чем в трех проектах одновременно). Для выра-жения этого семантического ограничения разрешается указывать на

37

конце отношения его максимально допустимую или обязательную степень;

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

2.2.3.2 К л а с с и ф и к ац и я о т н о ш е н и й В ERwin отношение между сущностями может принадлежать к од-

ному из следующих типов: – идентифицирующее отношение; – неидентифицирующее отношение. Каждый тип отношений определяет поведение атрибутов первич-

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

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

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

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

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

38

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

Сущность В/1 Атрибут_PK_В

Атрибут_1. . .

Атрибут_N

Атрибут_PK_A (FK)

Сущность В/1

Атрибут_PK_ВАтрибут_1

. . . Атрибут_N Атрибут_PK_A (FK)

Сущность А/1

Сущность А/1

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

а)

б)

Атрибут_PK_A


Атрибут_M

Атрибут_PK_A


Атрибут_M

2.2.3.3 Р о л и о т н о ш е н и й Иногда имеют место отношения, когда связи между сущностями

для разных экземпляров имеет различный смысл. Рассмотрим ситуа-цию по обмену валютой, которую можно описать с помощью двух сущностей ВАЛЮТА и СДЕЛКА, приведенных на рис. 2.10. Сущность ВАЛЮТА описывается свойствами Код валюты и название валюты, а сущность СДЕЛКА – свойствами Код сделки, Сумма сделки.

Для описания процессов обмена валютой установим связь типа 1:М между этими сущностями. Но как в этом случае различить связи между экземплярами сущностей ВАЛЮТА и СДЕЛКА для проданной и купленной валюты, так как в обоих случаях в таблицу СДЕЛКА мигри-рует один и тот внешний ключ Код валюты (FK) (см. рис. 2.10а)? А раз-личать эти записи важно, так как в конце сессии обмена необходимо подвести баланс: сколько и какой валюты продано и куплено.

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

39

Но в рамках ER-модели эти связи не различаются, так как являются отношения-ми между одними и теми же атрибутами двух таблиц, а именно, между атрибутами Ва-люта.Код валюты и Сдел-ка.Код валюты. Поэтому при создании новой связи между сущно-стями ВАЛЮТА и СДЕЛ-КА в таблицу СДЕЛКА еще один вторичный ключ уже не мигрирует, т. е. на диаграмме еще одна линия рисуется, но новая связь при этом не создается.

Для разрешения подобных ситуаций в модели «сущность-связь»

введено понятие «роли» отношения, представляющие собой новые имена, под которыми мигрирующие атрибуты будут представлены в дочерней сущности. В этом случае при покупке валюты в таблицу СДЕЛКА будет мигрировать значение атрибута Купля.Код валюты (FK), а при продаже – атрибута Продажа.Код валюты (FK) (см. рис. 2.10б). Имея такую базу данных легко подсчитать, сколько и какой валюты было продано и куплено за сессию обмена валюты.

2.2.4 ПОДТИПЫ И СУПЕРТИПЫ СУЩНОСТЕЙ Подобно тому, как это делается в языках программирования с

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

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

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

Сделка

Код сделки Сумма сделки Код валюты (FK)

Валюта

Код валютыНазвание валюты

Рис. 2.10. Роли отношений

а)

б)

Сделка

Код сделки Сумма сделки Купля.Код валюты (FK)

Валюта

Код валютыНазвание валюты

Продажа.Код валюты (FK)

40

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

Пример супертипа ЛЕТАТЕЛЬНЫЙ АППАРАТ и его подтипов АЭРО-ПЛАН и ВЕРТОЛЕТ показан на рис. 2.11. У подтипа АЭРОПЛАН имеются два собственных подтипа – ПЛАНЕР и САМОЛЕТ.

ЛЕТАТЕЛЬНЫЙ АППАРАТМаксимальная дальность полета

АЭРОПЛАНРазмах крыльев

ПЛАНЕР

ПИЛОТ

АЭРОПОРТ

АЭРОКЛУБ

Рис. 2.11. Супертипы и подтипы сущности

ВЕРТОЛЕТДиаметр винта

САМОЛЕТМощность мотора

АЭРОПОРТ

Для супертипа сущности ЛЕТАТЕЛЬНЫЙ АППАРАТ определен атри-

бут «Максимальная дальность полета» и необязательная связь «многие ко многим» с типом сущности ПИЛОТ. Эти атрибут и связь наследуется всеми подтипами этого супертипа сущности.

У подтипа сущности АЭРОПЛАН определяется один дополнитель-ный атрибут, так что в совокупности у данного типа сущности имеют-ся два атрибута «Максимальная дальность полета» и «Размах крыльев» и одна унаследованная связь с типом сущности ПИЛОТ.

У подтипа сущности АЭРОПЛАН определяется один дополнитель-ный атрибут, так что в совокупности у данного типа сущности име-ются два атрибута «Максимальная дальность полета» и «Размах крыльев» и одна унаследованная связь с типом сущности ПИЛОТ.

У подтипа второго уровня САМОЛЕТ супертипа АЭРОПЛАН опреде-ляется один дополнительный атрибут «Мощность мотора» и одна допол-нительная (обязательная) связь с типом сущности АЭРОПОРТ. Тем са-мым, у типа сущности САМОЛЕТ имеются три атрибута: два унаследо-ванных – «Максимальная дальность полета» и «Размах крыльев» и один

41

собственный – «Мощность мотора», а также две связи: одна унаследо-ванная – с типом сущности ПИЛОТ и одна собственная – с типом сущ-ности АЭРОПОРТ. И так далее.

2.3 ПОЛУЧЕНИЕ РЕЛЯЦИОННОЙ СХЕМЫ ИЗ ER-ДИАГРАММЫ Целью разработки концептуальной модели является ее преобра-

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

1. Каждый простой тип сущности превращается в таблицу. (Про-стым типом сущности называется тип сущности, не являющийся под-типом и не имеющий подтипов). Имя сущности становится именем таблицы. Экземплярам типа сущности соответствуют строки соответ-ствующей таблицы.

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

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

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

5. Для поддержки связи «многие ко многим» между типами сущ-ности A и B создается дополнительная таблица AB с двумя столбцами, один из которых содержит уникальные идентификаторы экземпляров сущности A, а другой – уникальные идентификаторы экземпляров сущности B. Используя таблицы A, B и AB, с помощью стандартных реляционных операций можно найти все пары экземпляров типов

42

сущности, участвующих в данной связи. 6. Индексы создаются для первичного ключа (уникальный ин-

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

7. Если в концептуальной схеме присутствуют подтипы, то воз-можны два способа их представления в реляционной схеме:

а) собрать все подтипы в одной таблице; б) для каждого подтипа образовать отдельную таблицу. При применении способа a) таблица создается для максимального

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

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

У каждого способа есть свои достоинства и недостатки. К досто-инствам способа a), согласно которому для представления супертипа и всех его подтипов используется одна таблица, можно отнести сле-дующее:

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

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

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

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

43

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

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

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

дому подтипу соответствует одноименная таблица); – упрощается логика приложений; каждая программа работает

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

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

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

КОНТРОЛЬНЫЕ ВОПРОСЫ

1. Перечислите и опишите методологии семейства IDEF. 2. Определите характеристики методологии IDEF1X. 3. Определите сущность в ER-модели. 4. Определите атрибут в ER-модели. 5. Определите связь в ER-модели. 6. Приведите и опишите классификацию атрибутов в ER-модели. 7. Приведите и опишите классификацию сущностей в ER-модели. 8. Определите критерии различения зависимых и независимых

сущностей. 9. Опишите способ реализации ассоциативных сущностей в физи-

ческих моделях предметной области. 10. Для каких целей используется процедура нормализации

данных? 11. Приведите общие правила нормализации. 12. Приведите правило приведения схемы данных к первой нор-

мальной форме.

44

13. Приведите правило приведения схемы данных ко второй нор-мальной форме.

14. Приведите правило приведения схемы данных к третьей нор-мальной форме.

15. Приведите правило приведения схемы данных к четвертой нормальной форме.

16. Приведите и опишите свойства отношений. 17. Приведите и опишите классификацию отношений в ER-модели. 18. Опишите связь между идентифицирующими и неидентифици-

рующими отношениями и зависимыми и независимыми сущностями. 19. Дайте определение и опишите роли отношений в ER-модели. 20. Опишите способы определения нового типа сущности путем

наследования некоторого супертипа сущности ER-модели. 21. Опишите типовую процедуру преобразования ER-диаграммы в

реляционную схему базы данных

45

ГЛАВА 3. ПРОЕКТИРОВАНИЕ РЕЛЯЦИОННЫХ БАЗ ДАННЫХ С ИСПОЛЬЗОВАНИЕМ СЕМАНТИЧЕСКИХ МОДЕЛЕЙ: ДИАГРАММЫ КЛАССОВ ЯЗЫКА UML

В этой главе рассмотрим основные понятия диаграмм классов унифицированного языка моделирования UML (Unified Modeling Language) и возможности применения этой диаграммной модели для проектирования реляционных баз данных. Кроме того, в данной главе будет кратко рассмотрен язык объектных ограничений OCL (Object Constraint Language) и приведены примеры формулировок ограничений целостности на этом языке в терминах концептуальной схемы базы данных.

3.1 ВВЕДЕНИЕ Унифицированный язык моделирования UML был создан в 1994 г.

специалистами по программной инженерии Гради Бучем (Grady Booch) и Джеймсом Рамбо (James Rumbaugh) из компании Rational Software [8].

Языку UML посвящено великое множество книг, многие из кото-рых переведены на русский язык (а некоторые и написаны россий-скими авторами). Язык UML разработан и развивается консорциумом OMG (Object Management Group) и имеет много общего с объектными моделями, на которых основана технология распределенных объект-ных систем CORBA, и объектной моделью ODMG (Object Data Management Group).

UML позволяет моделировать разные виды систем: чисто програм-мные, чисто аппаратные, программно-аппаратные, смешанные, явно включающие деятельность людей и т. д.

UML используется в объектно-ориентированных системах разра-ботки, таких как Delphi, и позволяет уменьшить разрыв между этапом проектирования системы, построения ее архитектуры и внутренних взаимосвязей и этапом реализации.

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

46

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

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

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

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

3.2 ОСНОВНЫЕ ПОНЯТИЯ ДИАГРАММ КЛАССОВ UML Язык UML базируется на трех фундаментальных понятиях: сущ-

ность, отношение и диаграмма. Сущность – это объект проектируемой системы, который цело-

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

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

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

– двумерные графические объекты представлены простыми гео-метрическими фигурами. Такие фигуры изображают сущности;

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

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

47

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

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

3.2.1 КЛАССЫ Класс в языке UML представляет собой структуру, шаблон абст-

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

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

3.2.2 АТРИБУТЫ Атрибутом класса называется именованное свойство класса,

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

48

Имена атрибутов представляются в разделе класса, расположенном под именем класса. Хотя UML не накладывает ограничений на спо-собы создания имен атрибутов (имя атрибута может быть произ-вольной текстовой строкой), на практике рекомендуется исполь-зовать короткие прилагательные

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

3.2.3 ОПЕРАЦИИ Операцией класса называется именованная услуга, которую

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

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

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

Рис. 3.1. Класс «Человек» с атрибутами

Рис. 3.2. Класс «Человек» с операциями

49

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

3.3 ЗАВИСИМОСТИ, ОБОБЩЕНИЯ И АССОЦИАЦИИ Объекты (сущности) диаграммы связываются друг с другом раз-

ными отношениями или связями. В диаграмме классов могут участ-вовать связи трех разных категорий: ассоциация (association), обобще-ние (generalization) и зависимость (dependency). При проектировании ре-ляционных БД наиболее важны вторая и третья категории связей, по-этому о связях-зависимостях будет сказано только самое основное.

3.3.1 ЗАВИСИМОСТИ Зависимостью называют связь по применению, когда изменение в

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

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

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

50

3.3.2 ОБОБЩЕНИЯ И МЕХАНИЗМ НАСЛЕДОВАНИЯ КЛАССОВ

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

Обобщения иногда называют связями «is a», имея в виду, что класс-потомок является частным случаем класса-предка. Класс-потомок наследует все атрибуты и операции класса-предка, но в нем могут быть определены дополнительные атрибуты и операции.

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

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

51

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

3.3.3 АССОЦИАЦИИ: РОЛИ, КРАТНОСТЬ, АГРЕГАЦИЯ, КОМПОЗИЦИЯ Ассоциацией называется структурная связь, показывающая, что

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

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

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

Приведенная именованная ассоциация должна читаться как

«Студент учится в Университете». Другим способом именования ассоциации является указание роли

каждого класса, участвующего в этой ассоциации. Роль класса, как и имя конца связи в ER-модели, задается именем, помещаемым под ли-нией ассоциации ближе к данному классу. На рис. 3.6 показаны две ассоциации между классами Человек и Университет, в которых эти классы играют разные роли.

52

Как мы видим, объекты класса Человек могут выступать в роли Работников при участии в ассоциации, в которой объекты класса Уни-верситет играют роль Нанимателя. В другой ассоциации объекты класса Человек играют роль Студента, а объекты класса Университет – роль Обу-чающего.

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

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

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

Указание диапазона «0..1» говорит о том, что не все объекты класса с данной ролью обязаны участвовать в каком-либо экземпляре данной ассоциации, но в каждом экземпляре ассоциации может уча-ствовать только один объект.

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

53

Толкование диапазона «0..*» является очевидным расширением случая «0..1». В более сложных (но крайне редко встречающихся на практике) случаях определения кратности можно использовать списки диапазонов. Например, список «2, 4..6, 8..*» говорит о том, что все объек-ты класса с указанной ролью должны участвовать в некотором экземп-ляре данной ассоциации, и в каждом экземпляре ассоциации должны участвовать два, от четырех до шести или более восьми объектов класса с данной ролью.

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

Обычная ассоциация между двумя классами характеризует связь

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

Графически агрегатные ассоциации изображаются в виде про-стой ассоциации с незакрашенным ромбом на стороне класса «целое». Простой пример агрегатной ассоциации показан на рис. 3.8.

54

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

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

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

Заметим, что в контексте проектирования реляционных БД агре-

гатные и в особенности композитные ассоциации влияют только на способ поддержки ссылочной целостности. В частности, композитная связь является явным указанием на то, что ссылочная целостность между «целым» и «частями» должна поддерживаться путем каскадного удаления частей при удалении целого. Подробнее способы поддержки ссылочной целостности в SQL-ориентированных БД рассматриваются в Главе 5.

55

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

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

В библиотеке должно содержаться некоторое количество книг, и

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

3.4 ОГРАНИЧЕНИЯ ЦЕЛОСТНОСТИ И ЯЗЫК OCL Один из самых серьезных и справедливо критикуемых недостат-

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

Рис. 3.10.

56

До появления формального языка объектных ограничений для описания ограничений применялись комментарии на естественном языке. На рис. 3.11 показана простая диаграмма классов Студент и Уни-верситет с ограничением, выраженным на естественном языке.

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

Студентстипендия

УниверситетмаксСтипендияминСтипендия

1..* 1

Студент.Стипендия должно находиться в диапазоне между Университет.минСтипендия и Университет.максСтипендия

Рис. 3.11. Ограничение, выраженное на естественном языке В начале 90-х годов в корпорации IBM разрабатывалась методика

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

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

3.4.1 ОБЩАЯ ХАРАКТЕРИСТИКА ЯЗЫКА OCL Нередко ограничения, выраженные на естественном языке, при

реализации системы трактовались неоднозначно. Язык OCL снял мно-жество проблем при проектировании моделей UML. Он предоставил разработчику набор формальных средств взаимодействия с объектами создаваемого приложения.

57

Приведем общую характеристику этого языка. Из языка UML в OCL заимствованы, в первую очередь, следующие понятия:

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

UML, в OCL предопределены структурные типы, которые являются разновидностями типов коллекций (collection):

– математическое множество (set), неупорядоченная коллекция, не содержащая одинаковых элементов;

– мультимножество (bag), неупорядоченная коллекция, которая может содержать повторяющиеся элементы-дубликаты;

– последовательность (sequence), упорядоченная коллекция, кото-рая может содержать элементы-дубликаты.

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

3.4.2 ИНВАРИАНТ КЛАССА Под инвариантом класса в OCL понимается условие, которому

должны удовлетворять все объекты данного класса. Если говорить более точно, инвариант класса – это логическое выражение, вычисле-ние которого должно давать true при создании любого объекта данно-го класса и сохранять истинное значение в течение всего времени его существования. При определении инварианта требуется указать имя класса и выражение, определяющее инвариант указанного класса. Синтаксически это выглядит следующим образом:

context <class_name> inv: <OCL-выражение>. В этом выражении: – <class-name> является именем класса, для которого определяется

инвариант;

58

– inv – ключевое слово, говорящее о том, что определяется именно инвариант, а не ограничение другого вида;

– context – ключевое слово, которое говорит о том, что контекстом следующего после двоеточия OCL-выражения являются объекты клас-са <class-name>.

OCL-выражение должно принимать значение true для всех объек-тов этого класса.

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

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

– операции над значениями предопределенных в UML типов дан-ных;

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

ций над ними очевидна, и поэтому ограничимся лишь их перечисле-нием. В OCL поддерживаются следующие заимствованные из опреде-ления UML скалярные типы данных: Boolean, Integer, Real и String.

Операции над объектами В OCL определены три операции над объектами: – получение значения атрибута; – переход по соединению, – вызов операции класса (последняя операция для целей проекти-

рования реляционных БД несущественна). Для записи этих операций используется «точечная нотация». На-

пример, результатом выражения вида <объект>.<имя атрибута>

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

59

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

<объект>.<имя соединения>

3.4.3 ОПЕРАЦИИ НАД МНОЖЕСТВАМИ, МУЛЬТИМНОЖЕСТВАМИ И ПОСЛЕДОВАТЕЛЬНОСТЯМИ В OCL поддерживается обширный набор операций над значения-

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

<коллекция> <имя операции> (<список фактических параметров>) Операция select В OCL определены три одноименных операции select, которые об-

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

Операция collect Аналогично набору операций select, в OCL определены три опера-

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

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

60

Операции exists, forAll, size В OCL определены три одноименных операции exists над множест-

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

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

Операция size применяется к коллекции и выдает число содержа-щихся в ней элементов.

Операции union, intersect, symmetricDifference Параметрами двуместных операций union, intersect,

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

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

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

3.4.4 ПРИМЕРЫ ИНВАРИАНТОВ В заключение обзора языка OCL приведем примеры пяти инвари-

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

Инвариант на значение атрибута «возраст» context Сотрудник inv: self.возраст >18 and self.возраст < 100 Условие инварианта накладывает требуемое ограничение на зна-

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

61

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

Сотрудникномер

должностьвозраст

Отделномер

годОснования1..* 1

Компанияимя

годОснования

сотрудник отдел

отдел

компания

1..*

1

Рис. 3.12. Диаграмма классов для примеров на языке OCL

Инвариант для объектов класса «Отдел» context Отдел inv: self.номер 5 or self.служащий select (возраст 30) size () = 0 В этом случае условное выражение инварианта будет вычислять-

ся для каждого объекта класса Отдел. Подвыражение справа от опера-ции or вычисляется слева направо.

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

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

Значением операции size () является число объектов в этом множе-стве. Все выражение принимает значение true, если последняя опера-ция сравнения «=0» вырабатывает значение true, т. е. если в текущем отделе нет сотрудников младше 31 года.

Ограничение в целом удовлетворяется только в том случае, если значением условия инварианта является true для каждого отдела.

62

Инвариант для объектов класса «Сотрудник» Инвариант можно сформулировать в контексте класса Сотрудник: context Сотрудник inv: self.возраст > 30 or self.отдел.номер < 5 Здесь следует обратить внимание на подвыражение self.отдел.номер

< 5. Поскольку отдел – это имя роли соединения, значением подвыра-жения self.отдел является коллекция (множество). Но кратность роли отдел равна единице, т. е. каждому объекту служащего соответствует в точности один объект отдела. Поэтому в OCL допускается сокра-щенная запись операции self.отдел.номер, значением которой является номер отдела текущего служащего.

Инвариант на наличие у отдела менеджера context Отдел inv: self.служащий exists (должность = "manager") and self.компания.годОснования self.годОснования Здесь должность – атрибут класса Сотрудники, а атрибуты с име-

нем годОснования имеются и у класса Отдел, и у класса Компания. В ус-ловном выражении этого инварианта подвыражение self.служащий exists (должность = "manager") эквивалентно выражению self.служащий select (должность = "manager") size () > 1. Если бы в ограничении мы потребова-ли, чтобы у каждого отдела был только один менеджер, то следовало бы написать size () = 1, и это было бы не эквивалентно варианту с exists.

Инвариант на основе операции «collect» context Компания inv: self.отдел collect (служащие) size ( ) < 1000 Здесь полезно обратить внимание на использование операции col-

lect. Проследим за вычислением условного выражения. В нашем случае в классе Компания всего один объект, и он сразу

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

При выполнении операции collect (служащие) для каждого объекта-отдела по соединению с объектами класса СЛУЖАЩИЕ будет образова-но множество объектов-служащих данного отдела, а в результате бу-дет образовано множество объектов, соответствующих всем служа-щим всех отделов компании, т. е. всем служащим компании.

63

3.4.5 ПЛЮСЫ И МИНУСЫ ИСПОЛЬЗОВАНИЯ ЯЗЫКА OCL ПРИ ПРОЕКТИРОВАНИИ РЕЛЯЦИОННЫХ БАЗ ДАННЫХ Плюсы и минусы использования языка OCL при проектировании

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

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

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

Кроме того, строгость синтаксиса и линейная форма языка в не-котором роде противоречат наглядности и интуитивной ясности диа-граммной части UML. Да, в инвариантах OCL используются те же по-нятия и имена, что и в соответствующей диаграмме классов, но ис-пользуются совсем в другой манере.

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

3.5 ПОЛУЧЕНИЕ СХЕМЫ РЕЛЯЦИОННОЙ БАЗЫ ДАННЫХ ИЗ ДИАГРАММЫ КЛАССОВ UML Если не обращать внимания на различия в терминологии, то здесь

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

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

64

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

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

Рекомендация 4. Не злоупотребляйте возможностями OCL. Диаграммы классов UML – это мощный инструмент для создания

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

КОНТРОЛЬНЫЕ ВОПРОСЫ 1. Приведите общее описание унифицированного языка модели-

рования UML. 2. Приведите общее описание языка объектных ограничений OCL. 3. Определите классы в языке UML. 4. Определите атрибуты в языке UML. 5. Определите операции в языке UML. 6. Опишите связи-зависимости в языке UML. 7. Опишите обобщения и механизм наследования классов в языке

UML. 8. Опишите ассоциации (роли, кратность, агрегацию, компози-

цию) в языке UML. 9. Недостатки выражения ограничений на естественном языке и

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

10. Опишите понятие инварианта класса языка объектных огра-ничений OCL.

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

12. Достоинства и недостатки использования языка OCL при про-ектировании реляционных баз данных.

65

ГЛАВА 4. МОДЕЛИРОВАНИЕ ДАННЫХ В ФОРМАЛИЗМЕ СПЕЦИФИКАЦИИ XSD

В последние годы, в связи с бурным развитием Web-технологий и основанных на них распределенных ИнфС, увеличивается спрос на определение информационных ресурсов, заданных в XML-формате, обеспечивающих независимость данных от платформы [9].

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

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

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

4.1 XML КАК СПОСОБ ЛОГИЧЕСКОГО ПРЕДСТАВЛЕНИЯ ИНФОРМАЦИИ

4.1.1 СТАНОВЛЕНИЕ ЯЗЫКА XML Название языка XML переводится с английского как «расширен-

ный язык разметки» и полностью соответствует его назначению. У этого языка много общего с его широко распространенным «родственником» − языком HTML, завоевавшим широчайшую популярность в качестве базового языка, лежащего в основе Web-технологий и Web-браузеров. Концепции обоих языков базируются на понятии разметки документа, которое возникло в ходе развития печатного дела.

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

66

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

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

С появлением компьютерных издательских систем команды разметки, встроенные в содержимое документа, стали командами издательских про-грамм. Но при этом каждый тип издательского программного обеспечения или оборудования поддерживал свой набор команд разметки, что очень затрудняло переход от одной системы к другой. Для стандартизации разметки был разработан язык SGML (Standard Generalized Markup Lan-guage − стандартный обобщенный язык разметки), который со време-нем был принят как стандарт всеми разработчиками издательских про-грамм.

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

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

Таким образом, XML и HTML являются языками, происходящими от общего предка − языка SGML.

67

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

4.1.2 ПРОСТОЙ ПРИМЕР XML-ДОКУМЕНТА Исходный документ в виде ASCII-текста. Рассмотрим простой

пример формирования данных документа в XML-формате. Пусть у нас имеется документ некоей компании Scateboots, представленный в виде ASCII-текста:

Customer Number 12345 Customer Name Joe's Boots Customer Address 300 High Street Customer Phone (095) 123 45 78 Postal Code 123456 Credit Limit 1 000 Credit Rating 5 Анализ данных документа. Итак, программист создал элемент

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

Customer Number Номер клиента целое число Customer Name Имя клиента текст Customer Address Адрес клиента текст Customer Phone Телефон клиента целое число Postal Code Почтовый индекс клиента текст Credit Limit Лимит кредита клиента десятичное число Credit Rating Кредитоспособность клиента целое число

Формирование XML-документа. Программист форматирует по-лученные данные в виде XML-документа следующим образом:

<?xml version="1.0" encoding="UTF-8"?> <Customer>

68

<CustomerNumber>12345</CustomerNumber> <CustomerName>Joe's Boots</CustomerName> <CustomerAddressr>300 High Street</CustomerAddressr> <CustomerPhone>(095) 123 45 67</CustomerPhone> <PostalCode>123456</PostalCode> <CreditLimit>1 000 000</CreditLimit> <CreditRating>5</CreditRating> </Customer> XML-схема документа. После представления данных о клиенте в

виде XML-описания и имея в наличии требования к данным этого опи-сания, аналитик компании Scateboots для проверки достоверности све-дений на предмет соответствия структуре и типам данных создает XML-схему:

<?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified"> <xs:element name="Customer" type="CustomerType"/> <xs:complexType name="CustomerType"> <xs:sequence> <xs:element name="CustomerNumber" type="xs:integer"/> <xs:element name="CustomerName" type="xs:string"/> <xs:element name="CustomerAddress" type="xs:string"/> <xs:element name="CustomerPhone" type="xs:string"/> <xs:element name="PostalCode" type="PostalCodeType"/> <xs:element name="CreditLimit" type="xs:decimal"/> <xs:element name="CreditRating" type="xs:integer"/> </xs:sequence> </xs:complexType> <xs:simpleType name="PostalCodeType"> <xs:restriction base="xs:string"> <xs:pattern value="\d{5}|\d{5}-d{4}"/> </xs:restriction> </xs:simpleType> </xs:schema> Пример иллюстрирует схему, отвечающую за проверку достовер-

ности, типов данных и структуры документа, включающего запись о клиенте. В начале схемы содержится ссылка schema, указывающая на используемую редакцию схемы. В данном случае это редакция от 21 мая 2001 года (пространство имен www.w3.org/2001/XMLSchema). Ссылка

69

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

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

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

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

4.1.3 XML-ПРОЦЕССОРЫ XML-процессоры осуществляют проверку достоверности экземп-

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

Тип и структура также соотносятся с экземпляром документа. Эта связь осуществляется за счет установления соответствия имен эле-ментов в экземпляре документа и именами элементов в связанной с ним схеме, и в случае совпадения используется информация о типе и структуре, объявленная в схеме при использовании XML-данных в языках высокого уровня. Простой тип данных может отобразиться в тип int языков C++ и Java, или в тип Integer языка Pascal, что зависит от конкретной среды.

70

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

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

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

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

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

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

71

4.2 ОПРЕДЕЛЕНИЕ XML-СХЕМЫ В начале главы мы отметили, что XSD-спецификации данных мо-

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

XML-схема, с которой мы уже ознакомились в пункте 4.1.2, пред-ставляет собой определение структуры XML-документа (ее организа-ции и применяемых в ней типов данных). Язык XML Schema описывает способ определения в схеме каждого элемента и позволяет указать типы данных, связанных с каждым элементом.

Схема сама является документом XML, в котором используются элементы и атрибуты, выражающие семантику схемы. А поскольку схема − документ XML, то ее можно редактировать и обрабатывать с помощью таких же инструментальных средств, какие применяются для обработки описанного ею документа XML. Рассмотрим основные компоненты XML-схемы на основе примера, приведенного в листинге в конце подраздела 4.2.

4.2.1 ПРОСТЫЕ И СЛОЖНЫЕ ТИПЫ Один из самых простых способов создания схемы XML состоит в

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

Элементы, не имеющие в своем составе других элементов или ат-рибутов, относятся к простому типу simpleType. Например, элементы Фамилия, Имя, Отчество и датаРождения можно представить следующим образом:

<xs:element name="Фамилия" type="xs:string"/> <xs:element name="Имя" type="xs:string"/> <xs:element name="Отчество" type="xs:string"/> <xs:element name="ДатаРождения" type="xs:date"/> Эти элементы объявлены с помощью предопределенных типов

string и date, а для обозначения их принадлежности к словарю XML Schema введен префикс xs, который связан с пространством имен W3C

72

XML Schema с помощью объявления xmlns:xsd=«http://www.w3.org/2001/ XML Schema, помещенного в элемент schema.

Элементы, содержащие другие элементы, относятся к типу слож-ных элементов complexType. Например, обнаружив корневой элемент Адрес, можно определить, что он относится к типу complexType. Список дочерних элементов элемента Адрес описывается с помощью элемента sequence. Он относится к типу элемента-составителя (compositor), кото-рый определяет упорядоченную последовательность субэлементов:

<xs:element name="Адрес"> <xs:complexType> <xs:sequence> <xs:element name="Индекс" type="xs:string"/> <xs:element name="Регион" type="xs:string"/> <xs:element name="насПункт" type="xs:string"/> <xs:element name="Улица" type="xs:string"/> <xs:element name="Дом" type="xs:integer "/> <xs:element name="Квартира" type="xs:integer "/> </xs:sequence> </xs:complexType> </xs:element> Кроме того, в XML-схеме можно объявлять атрибуты. Задание ат-

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

Например, атрибут формаОбучения может быть объявлен следую-щим образом:

<xs:attribute name="формаОбучения" type="xs:string"/>.

4.2.2 КАРДИНАЛЬНОСТЬ Язык XML Schema позволяет представить кардинальность некото-

рого элемента с помощью атрибутов minOccurs (минимальное количе-ство вхождений) и maxOccurs (максимальное количество вхождений). Для обозначения необязательного элемента атрибуту minOccurs при-сваивается значение 0, а для указания на то, что максимальное коли-чество вхождений не ограничено, атрибуту maxOccurs может быть присвоено значение unbounded. В качестве значения любого незадан-

73

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

<xs:element name="Отчество" type="xs:string" minOccurs="0"/> А для регистрации двух фамилий можно применить конструкцию <xs:element name="Фамилия" type="xs:string" maxOccurs="2"/>

4.2.3 ОПРЕДЕЛЕНИЕ НОВЫХ ТИПОВ В языке XML Schema предусмотрен третий механизм создания эле-

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

<xs:simpleType name="Группа"> <xs:restriction base="xs:string"> <xs:maxLength value="7"/> </xs:restriction> </xs:simpleType> Этот новый тип определен как ограничение (restriction) данных ти-

па string из пространства имен XML Schema (атрибут base), а также ука-зано, что он имеет максимальную длину 7 символов (элемент maxLen-gtn называется фасетом).

В спецификации XML Schema предусмотрено 15 фасетов, в том числе length, minLength, minlnclusive и maxlnclusive. Двумя другими чрезвы-чайно удобными фасетами являются pattern и enumeration. Элемент pat-tern определяет регулярное выражение, с которым должно сопостав-ляться проверяемое значение.

Например, на элемент Группа может быть наложено ограничение, чтобы его значение содержало от одного до четырех прописных сим-волов, за которыми следуют:

– один строчной символ; – знак '-'; – две цифры. Это требование можно представить на языке XML Schema с помо-

щью следующего шаблона pattern: <xs:pattern value="[А-Я]{4}[а-я]{1}-[1-6]{2}"/>.

74

Примеры значений элемента Группа: ЭВМд-32, АД-12, БЭВМд-32. Элемент enumeration позволяет ограничить простой тип набором

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

<xs:enumeration value="Бакалавр"/> <xs:enumeration value="Специалист"/> <xs:enumeration value="Магистр"/>

4.2.4 ЭЛЕМЕНТЫ-СОСТАВИТЕЛИ CHOICE И ALL При описании сложного элемента XML Schema мы уже имели дело

с элементом-составителем sequence. Предусмотрены еще два типа элементов-составителей: choice и all. Элемент-составитель choice опре-деляет возможность выбора между несколькими допустимыми эле-ментами или группами элементов, а элемент-составитель all определя-ет неупорядоченный набор элементов.

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

<xs:element name="Кафедра"> <xs:complexType> <xs:choice> <xs:element name="Код" type="xs:integer"/> <xs:element name="Наименование" type="xs:string"/> </xs:choice> </xs:complexType> </xs:element>

4.2.5 ОГРАНИЧЕНИЯ В предыдущих разделах уже рассматривались некоторые примеры

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

В этом разделе рассматриваются ограничения двух типов: огра-

75

ничения уникальности и ограничения по ключу. Ограничения уникальности. Для определения ограничения уни-

кальности должен быть задан элемент unique, определяющий элемен-ты или атрибуты, которые должны быть уникальными. Например, можно определить ограничение уникальности по данным, состоящим из фамилии и даты рождения (Фамилия − датаРождения) сотрудника компании, с помощью следующей конструкции:

<xs:unique> <xs:selector xpath="."/> <xs:field xpath="Фамилия"/> <xs:field xpath="датаРождения"/> </xs:unique> Местонахождение уникального элемента в схеме позволяет опре-

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

Выражения xpath, заданные в трех элементах данного определе-ния, являются относительными к контекстному узлу. Первое выраже-ние xpath с элементом selector задает элемент, на который распростра-няется ограничение уникальности (в данном случае "."), а следующие два элемента field указывают узлы, которые должны проверяться на уникальность.

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

В следующем примере показано ограничение pkСтудент по ключу, заданное на тех же узлах, а именно, Фамилия − датаРождения:

<xs:key name="pkСтудент"> <xs:selector xpath="."/> <xs:field xpath="Фамилия"/> <xs:field xpath="датаРождения"/> </xs:key> Еще один тип ограничения позволяет ограничивать ссылки значе-

76

ниями указанных ключей. Например, если какой-либо объект требу-ется связать с объектом СТУДЕНТ, то для этого необходимо опреде-лить элемент, скажем, fkСтудент, значения которого должны быть ог-раничены значениями ключа pkСтудент. Этот тип ограничения задает-ся следующим образом:

<xs:keyref refer="fkСтудент" name="pkСтудент"> <xs:selector xpath="."/> <xs:field xpath="Фамилия"/> <xs:field xpath="датаРождения"/> </xs:keyref>

4.2.6 ПРИМЕР XML-СХЕМЫ После описания компонентов XML-схемы по отдельности приведем

пример XML-схемы для XML-документа, содержащего данные о сту-дентах.

<?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified">  <xs:complexType name="ДисциплиныType"> <xs:sequence> <xs:element name="КодДисциплины" type="xs:integer"/> <xs:element name="Наименование" type="xs:string"/> <xs:element name="Преподаватель" type="xs:string"/> <xs:element name="колЛекций" type="xs:integer"/> <xs:element name="колПрактЗан" type="xs:integer"/> <xs:element name="колЛаборРаб" type="xs:integer"/> <xs:element name="fkDiscipliny" type="xs:integer"/> </xs:sequence> </xs:complexType>  <xs:complexType name="КафедраType"> <xs:sequence> <xs:element name="Код" type="xs:integer"/> <xs:element name="Наименование" type="xs:string"/> <xs:element name="fkKafedra" type="xs:integer"/> </xs:sequence> </xs:complexType> 

77

<xs:complexType name="АдресType"> <xs:sequence> <xs:element name="Индекс" type="xs:string"/> <xs:element name="Регион" type="xs:string"/> <xs:element name="насПункт" type="xs:string"/> <xs:element name="Улица" type="xs:string"/> <xs:element name="Дом" type="xs:string"/> <xs:element name="Квартира" type="xs:string"/> <xs:element name="fkAddress" type="xs:integer"/> </xs:sequence> </xs:complexType>  <xs:element name="СТУДЕНТ"> <xs:complexType> <xs:sequence> <xs:element name="КодСтудента" type="xs:integer"/> <xs:element name="Фамилия" type="xs:string"/> <xs:element name="Имя" type="xs:string"/> <xs:element name="Отчество" type="xs:string"/> <xs:element name="датаРождения" type="xs:date"/> <xs:element name="Статус"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:enumeration value="Бакалавр"/> <xs:enumeration value="Специалист"/> <xs:enumeration value="Магистр"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="Адрес" type="АдресType"/> <xs:element name="Кафедра" type="КафедраType"/> <xs:element name="Дисциплины" type="ДисциплиныType" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="формаОбучения" type="xs:string"/> </xs:complexType> <xs:key name="pkСтудент"> <xs:selector xpath="."/> <xs:field xpath="КодСтудента"/>

78

</xs:key> <xs:keyref name="fkAddress" refer="pkСтудент"> <xs:selector xpath="Адрес"/> <xs:field xpath="fkAddress"/> </xs:keyref> <xs:keyref name="fkKafedra" refer="pkСтудент"> <xs:selector xpath="Кафедра"/> <xs:field xpath="fkKafedra"/> </xs:keyref> <xs:keyref name="fkDiscipliny" refer="pkСтудент"> <xs:selector xpath="Дисциплины"/> <xs:field xpath="fkDiscipliny"/> </xs:keyref> </xs:element> </xs:schema>

XML файл, сформированный на основе XML-схемы элемента СТУ-ДЕНТ, приведен в следующем листинге.

<?xml version="1.0" encoding="UTF-8"?> <?xml-stylesheet type="text/xsl" href="Student.xslt"?> <СТУДЕНТ формаОбучения="String" xsi:noNamespaceSchemaLocation="Student.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <КодСтудента>1</КодСтудента> <Фамилия>Фетисов</Фамилия> <Имя>Денис</Имя> <Отчество>Петрович</Отчество> <датаРождения>2001-08-13</датаРождения> <Статус>Бакалавр</Статус> <Адрес> <Индекс>432031</Индекс> <Регион>Ульяновский</Регион> <насПункт>Ульяновск</насПункт> <Улица>Мира</Улица> <Дом>11</Дом> <Квартира>22</Квартира> <fkAddress>1</fkAddress> </Адрес> <Кафедра>

79

<Код>1</Код> <Наименование>ВТ</Наименование> <fkKafedra>1</fkKafedra> </Кафедра> <Дисциплины> <КодДисциплины>1</КодДисциплины> <Наименование>ПО АС</Наименование> <Преподаватель>Федоров Г.П.</Преподаватель> <колЛекций>17</колЛекций> <колПрактЗан>0</колПрактЗан> <колЛаборРаб>17</колЛаборРаб> <fkDiscipliny>1</fkDiscipliny> </Дисциплины> <Дисциплины> <КодДисциплины>2</КодДисциплины> <Наименование>БД</Наименование> <Преподаватель>Николаев Ф.Л.</Преподаватель> <колЛекций>17</колЛекций> <колПрактЗан>0</колПрактЗан> <колЛаборРаб>17</колЛаборРаб> <fkDiscipliny>1</fkDiscipliny> </Дисциплины> </СТУДЕНТ>

4.3 СТИЛИ И ФОРМАТИРОВАНИЕ ДАННЫХ XML Создатели языка XML отделили содержимое документа не только

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

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

80

Таблица стилей переводит информацию XML-документа в форму, которая может быть представлена визуально. Если, к примеру, доку-мент XML просматривается с помощью Web-браузера, то таблица сти-лей должна создать подходящий HTML-документ.

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

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

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

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

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

<?xml version="1.0" encoding="UTF-8"?> <?xml-stylesheet type="text/xsl" href="catalog.xslt"?> <catalog> <cd> <title>Empire Burlesque</title> <artist>Bob Dylan</artist> </cd> <cd> <title>Live a Paris</title> <artist>Celin Dion</artist> </cd> </catalog>

81

Программа обработки XSL (XSL-процессор),встроенная в Web-браузер и преобразующая

XML-файл в HTML-файл для отображения

Входной XML-документ

Таблица стилей XSL

Выходной документ

Рис. 4.1. Преобразование документа XML-файла в оформленный документ при помощи таблицы стилей XSL

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

Важность корневого элемента заключается в том, что он опреде-ляет стартовую точку для XSL-процессора.

82

XSL-процессор – это приложение, обрабатывающее таблицу сти-лей XSL и использующее ее для трансформации данных XML, например, в HTML-документ. Как правило, вам придется иметь дело с XSL-процессорами, встроенными в Web-браузеры.

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

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

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

Шаблон для корневого элемента документа имеет вид: <xsl:template match="/">Инструкции по преобразованию</xsl:template> Этот шаблон будет осуществлять трансформацию всего докумен-

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

ниже корневого. Так, к примеру, элемент title, вложенный в элемент cd документа catalog, идентифицируется как /cd/title.

Шаблоны имеют синтаксис: <xsl:template match="/cd/title"> Инструкции по преобразованию </xsl:template> и содержат в своем составе: – последовательность или адрес узлов (в нашем случае это выра-

жение "/cd/title", сформированное на языке xPath), для которых предна-значен данный шаблон, записывается в атрибут match элемента xsl:template;

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

димо использовать элемент xsl:apply-templates, который выбирает все дочерние элементы текущего узла.

Чтобы отобрать не все дочерние узлы данного узла, а лишь неко-торый их набор, нужно снабдить xsl:apply-templates атрибутом select, выделяющим нужные дочерние узлы. Например, xsl:apply-templates se-lect="title".

83

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

<?xml version="1.0" encoding="UTF-8"?> <xsl:stylesheet version="2.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> <xsl:template match="/ "> <html><body> <xsl:apply-templates /> </body></html> </xsl:template> <xsl:template match="cd"> <h4>CD</h4> Title: <xsl:apply-templates select="title"/>

<br/> Artist: <xsl:apply-templates select="artist"/>

</body> </xsl:template> </xsl:stylesheet> Эта таблица стилей по XML-документу catalog.xml формирует html-

файл, приведенный ниже.

<html> <body> <h4>CD</h4> Title: Empire Burlesque <br/> Artist: Bob Dylan <h4>CD</h4> Title: Live a Paris <br/> Artist: Celin Dion </body> </html>. Обход XML-документа при его преобразовании в HTML-документ

осуществляется в следующем порядке. 1. Корневой узел сравнивается со всеми правилами-шаблонами

таблицы стилей, т. е. xslt-документа. Находится шаблон xsl:template match="/", в соответствии с которым на выход передается текст <html> <body>.

84

2. Элемент xsl:apply-templates этого же шаблона указывает преобра-зователю на необходимость обработки дочерних узлов корневого уз-ла. Первый дочерний узел корня документа – инструкция xml-stylesheet.

3. Второй дочерний узел корневого узла – корневой элемент cata-log. Но для этого узла правила не определены.

4. Продолжая обход дерева, определяем первый дочерний элемент элемента catalog – элемент cd, описывающий альбом Empire Burlesque.

5. В xslt-документе находим правило-шаблон xsl:template match="cd" для этого элемента. В соответствии с этим шаблоном на выход пере-дается текст <h4>CD</h4>, а затем – текст Title:.

6. Правило xsl:apply-templates select="title" извлекает значение «Empire Burlesque» элемента <title> для первого элемента cd и передает его на выход.

7. После этого на выход передается текст <br/>, а затем – Artist:. 8. Правило xsl:apply-templates select="artist" извлекает значение Bob Dyl-

an элемента <artist> первого элемента cd и передает его на выход. 9. Продолжая обход дерева, определяем второй дочерний элемент

элемента catalog – элемент cd, определяющий альбом Live a Paris, и по-вторяем для него с 5-го по 8-й шаги описываемого процесса.

10. После завершения обхода дерева возвращаемся к правилу-шаблону корневого узла и передаем на выход текст </body></html>.

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

Рис. 4.2. Отображение HTML-документа в браузере

85

КОНТРОЛЬНЫЕ ВОПРОСЫ 1. Опишите языки SGML, HTML и XML. 2. Опишите возможности языка XML как средства логического пред-

ставления информации. 3. Приведите пример представления данных средствами XML-тех-

нологий. 4. Опишите XML-процессоры и их возможности по унифицирован-

ному представлению данных. 5. Каково назначение XML-схем. 6. Представление простых и сложных типов данных средствами

XML-схем. 7. Опишите механизм создания элементов атрибутов на основе

объявления новых типов данных средствами XML-схем. 8. Каково назначение элементов-составителей sequence, choice и all. 9. Опишите ограничения стандарта XSD, обеспечивающие адекват-

ность схем реляционных баз данных и XML-схем. 10. Опишите таблицу стилей как средства визуализации данных,

представленных в XML-формате.

86

ГЛАВА 5. АВТОМАТИЗАЦИЯ ПРОЕКТИРОВАНИЯ И РАЗРАБОТКИ ИНФОРМАЦИОННЫХ СИСТЕМ НА ОСНОВЕ XML-ТЕХНОЛОГИЙ

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

5.1 МОДЕЛИРОВАНИЕ ДАННЫХ НА БАЗЕ XSD После ознакомления в предыдущей главе с основами XSD-специ-

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

5.1.1 XSD-МОДЕЛЬ КОМПОНЕНТА RESOURCE Начнем процесс моделирования с разделения компонента верх-

него уровня, который назовем Resource, на составные части. В соот-ветствии с этим разделением компонент Resource включает в свой со-став элементы Title (Заголовок), URL (для Web-страниц), Author (Автор), Organization (Организация) и Description (Описание).

На рис. 5.1 приведена диаграмма XML-схемы компонента Resource, созданная с использованием визуального редактора. Эта диаграмма показывает компонент Resource, смоделированный в виде композици-онной схемы, содержащей элементы, перечисленные выше. Диаграм-

87

ма также показывает, что Resource мог бы быть связан с разными ав-торами (много авторов могли бы внести вклад в разработку компо-нента Resource), и что каждый Автор имеет подчиненные элементы FirstName, LastName, Middle и Degree. (Конечно, элемент Organization и другие элементы могли бы также быть далее расчленены в более сложном примере).

Рис. 5.1. Диаграмма XML Schema Resource

По описанной диаграмме генерируется XSD-код, приведенный на листинге 5.1. Поверхностный взгляд на код показывает, что он спро-ектирован по типу «матрешки», в котором полное определение моде-ли вложено в элемент Resource.

Листинг 5.1. XML-схема для документа XML <?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified"> <xs:element name="Resource">

88

<xs:annotation> <xs:documentation> Web-ресурс используется в литературных работах </xs:documentation> </xs:annotation> <xs:complexType> <xs:sequence> <xs:element name="Title" type="xs:string"/> <xs:element name="URL" type="xs:string"/> <xs:element name="Description"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:maxLength value="250"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="Author"> <xs:complexType> <xs:sequence> <xs:element name="FirstName" type="xs:string"/> <xs:element name="LastName" type="xs:string"/> <xs:element name="Middle" type="xs:string"/> <xs:element name="Degree" type="xs:string"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="Organization" type="xs:string"/> </xs:sequence> </xs:complexType> </xs:element> </xs:schema> Огромным преимуществом спецификации XSD является то, что

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

Поэтому на следующем этапе преобразуем некоторые из компо-нентов в глобальные, которые можно использовать в качестве пользо-

89

вательских типов данных. Главные кандидаты на этот вид абстракции – компоненты Resource и Author. На рис. 5.2 приведена диаграмма пе-ресмотренной схемы после определения глобальных типов AuthorType и ResourceType.

Рис. 5.2. Диаграмма схемы элемента XML Schema Resource с глобальными типами Resource и Author

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

Например, мы могли бы ограничить максимальную длину полей FirstName 50 символами, используя фасет max-length

90

<xs:element name="FirstName"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:maxLength value="50"/> </xs:restriction> </xs:simpleType> </xs:element> Так же можно поступить с элементом LastName <xs:element name="LastName"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:maxLength value="50"/> </xs:restriction> </xs:simpleType> </xs:element> Мы могли бы далее ограничить поле Middle инициалом отчества. <xs:element name="Middle"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:maxLength value="2"/> </xs:restriction> </xs:simpleType> </xs:element> И мы могли бы ограничить значения для Degree небольшим набо-

ром, используя список «д.т.н.», «к.т.н.». Фрагмент XSD-кода модели компонента Resource приведен ниже.

<xs:element name="Degree"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:enumeration value="д.т.н."/> <xs:enumeration value="к.т.н."/> </xs:restriction> </xs:simpleType> </xs:element> Эти ограничения избавили бы нас от ошибок при вводе данных

экземпляра XML-документа. Например, при попытке ввести строку «Сергеевич», состоящую из девяти символов, в элемент Middle, как по-казано в нижеследующем тексте

91

<Author> <FirstName>Петров</FirstName> <LastName>Сергей</LastName> <Middle>Сергеевич</Middle> <Degree>к.т.н.</Degree> </Author>

XML-редактор выдает сообщение об ошибке «Value ‘Сергеевич’ is not allowed for element <Middle>».

При вводе строки «д.б.н.», не входящей в список enumeration для элемента Degree,

<Author> <FirstName>Петров</FirstName> <LastName>Сергей</LastName> <Middle>С.</Middle> <Degree>д.б.н.</Degree> </Author>

выдается сообщение об ошибке «Value ‘д.б.н.’ is not allowed for element <Degree>».

Кроме этого, ниже сообщения выводится подсказка, из какого списка следует выбирать значения для элемента <Degree>. Как видно из приведенных примеров, ошибки в тексте XSD-кода с помощью ви-зуального редактора XMLSpy легко локализуются и устраняются.

5.1.2 КОМПОЗИЦИЯ ПРОТИВ АГРЕГАЦИИ Композиционные и агрегированные модели были рассмотрены

нами в рамках изучения модели UML. В ER-модели этот вопрос не под-нимался, так как данная парадигма моделирования рассматривает только агрегированные модели.

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

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

92

Рис. 5.3. Определение первичных ключей в модели компонента Resource_collection с глобальными типами Resource и Author

На рис. 5.3 приведен фрагмент альтернативной модели для ком-понента Resource, в котором установлены отношения агрегации типа 1:M между компонентами Resource и Author. В данном варианте модели объект верхнего уровня представлен как коллекция компонентов Re-source_collection, в которой экземпляры компонента Resource связаны с экземплярами компонента Author отношением типа «один ко многим».

Для реализации описанных изменений в компоненты Author и Re-source необходимо добавить:

– атрибуты idAuthor и idResource, идентифицирующие экземпляры данных для типов Author и Resource;

– атрибут refResource для типа Author. Это позволяет нам устанавливать связи между элементами ком-

понентов Author и Resource в экземплярах XML-документа для модели-

93

рования ситуаций, когда для каждого ресурса могут быть установле-ны один и более авторов. С этой целью элементы idAuthor и idResource глобальных типов Author и Resource определяются как первичные клю-чи keyAuthor и keyResource (см. рис. 5.4).

Рис. 5.4. Определение вторичного ключа в модели компонента Resource_collection

Это определение налагает на эти элементы ограничения, в соот-ветствии с которыми их значения должны быть уникальными и обяза-тельными. Элемент refResource глобального типа Author определяется как вторичный ключ refAuthorResource, значения которого ограничива-ются перечнем значений первичного ключа keyResource.

94

Введенные ограничения предотвращают ввод ошибочных данных в экземплярах XML-документа, реализованных на основе данной XML-схемы. Например, при попытке ввода значения `8` для атрибута refResource в нижеприведенном тексте

<Resource> <idResource>1</idResource> <Title>Базы данных</Title> <URL>www.mir.ru</URL> <Description>Описание</Description> <Organization>Mir</Organization> </Resource> <Author> <idAuthor>1</idAuthor> <FirstName>Федор</FirstName> <LastName>Нилов</LastName> <Middle>Н.</Middle> <Degree>к.т.н.</Degree> <refResource>8</refResource> </Author>,

XML-редактор выдает сообщение об ошибке: «Resourse_collection.xml is not valid. The value '8' matched by the <keyref> identity constraint 'refAuthorResource' was not matched by the referenced key 'keyResource' within the scope of element <Resource_collection>» так как значения первичного клю-ча idResource в данном экземпляре XML-документа ограничены переч-нем `1`, `2`, `3`.

XSD-спецификация позволяет устанавливать между компонентами модели не только отношения типа «один ко многим» 1:M, но и отно-шения типа «многие ко многим» N:M. Для этого добавим в схему еще один компонент ResourceAuthor для установления ассоциаций между экземплярами компонентов и определим его элементы idAuthor и idResource в качестве вторичных ключей refAuthor и refResource, как по-казано на рис. 5.5.

Таким образом, в XSD-моделях мы можем представить отношения «многие ко многим» и определить ограничения по этим отношениям, которые были бы трудно или невозможно представить, используя ие-рархический XML.

95

Рис. 5.5. Определение агрегации типа N:M в модели компонента Resource_collection

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

5.2 ПРОЕКТИРОВАНИЕ КОМПОНЕНТОВ СИСТЕМЫ НА ОСНОВЕ XML-СХЕМЫ Достоинства моделирования данных с помощью XSD состоит в

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

96

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

На основе нашего примера продемонстрируем, как можно исполь-зовать XML-схему для реализации:

– шаблона экземпляра XML-документа; – схемы БД в качестве постоянного хранилища данных XML-доку-

ментов; – электронной формы для ввода данных в XML-документы; – программы отображения данных XML-документов в базу данных; – программы отображения данных из базы данных в XML-документ.

5.2.1 ГЕНЕРИРОВАНИЕ ШАБЛОНА ЭКЗЕМПЛЯРА XML-ДОКУМЕНТА С помощью визуального редактора XML на основе XML-схемы

можно сгенерировать шаблон экземпляра XML-документа. Для этого в строке меню XML-редактора выбирается команда DTD/Schema/Generate Sample XML file и в окне Generate Sample XML file задаются опции для гене-рации экземпляра XML-документа. В качестве одного из параметров определим количество множественных элементов, равное трем. В со-ответствии с этим параметром в сгенерированном XML-документе бу-дет определено три элемента компонента Author, как показано в лис-тинге 5.2.

Листинг 5.2. Шаблон экземпляра XML-документа <?xml version="1.0" encoding="UTF-8"?> <Resource_collection xsi:noNamespaceSchemaLocation="Resourse_collection.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <Resource> <idResource>0</idResource> <Title>String</Title> <URL>String</URL> <Description>Описание</Description> <Organization>String</Organization> </Resource> <Author> <idAuthor>0</idAuthor> <FirstName>String</FirstName> <LastName>String</LastName> <Middle>aa</Middle>

97

<Degree>к.т.н.</Degree> <refResource>0</refResource> </Author> <Author> <idAuthor>0</idAuthor> <FirstName>String</FirstName> <LastName>String</LastName> <Middle>aa</Middle> <Degree>к.т.н.</Degree> <refResource>0</refResource> </Author> <Author> <idAuthor>0</idAuthor> <FirstName>String</FirstName> <LastName>String</LastName> <Middle>aa</Middle> <Degree>к.т.н.</Degree> <refResource>0</refResource> </Author> </Resource_collection> Оставим пока сгенерированный шаблон без изменения, чтобы

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

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

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

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

98

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

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

5.2.2 ГЕНЕРИРОВАНИЕ ПОСТОЯННОГО ХРАНИЛИЩА ДАННЫХ Ограничения, которые мы встроили в XSD-модель, обеспечивают

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

На рис. 5.6 приведена диаграмма схемы базы данных со сгенери-рованными таблицами, иллюстрирующая отношения «один ко мно-гим» между компонентами Resource и Author, установленными от XSD-модели данных как показано на рис. 5.4.

Рис. 5.6. Схема базы данных, сгенерированной по XML-схеме

Ниже приведен листинг 5.3, содержащий SQL-скрипт для компо-нента Resource_collection, который был сгенерирован по XML-схеме Re-source_collection.xsd.

99

Листинг 5.3. SQL-скрипт для создания таблиц базы данных Resource

CREATE TABLE "Resource" ( "idResource" integer NOT NULL, "Title" character(255) NOT NULL, "URL" character(255) NOT NULL, "Description" character(250) NOT NULL, "Organization" character(255) NOT NULL, CONSTRAINT "keyResource" PRIMARY KEY ("idResource") )

CREATE TABLE "Author" ( "idAuthor" integer NOT NULL, "FirstName" character(255) NOT NULL, "LastName" character(255) NOT NULL, "Middle" character(2) NOT NULL, "Degree" character(255) NOT NULL, "refResource" integer NOT NULL, CONSTRAINT "keyAuthor" PRIMARY KEY ("idAuthor"), CONSTRAINT "Author_ref Resource_fkey" FOREIGN KEY ("refResource") REFERENCES "Resource" ("idResource") MATCH SIMPLE ON UPDATE NO ACTION ON DELETE NO ACTION, CONSTRAINT "CK_Author_Degree" CHECK ("Degree" = ANY (ARRAY['к.т.н.'::bpchar, 'д.т.н.'::bpchar])) )

Этот листинг показывает SQL-скрипт, сгенерированный для соз-дания базы данных для примера Resource_collection.

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

5.2.3 СОЗДАНИЕ ПОЛЬЗОВАТЕЛЬСКОГО ИНТЕРФЕЙСА Выше мы рассмотрели два формата определения данных. При

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

100

Проектирование пользовательского интерфейса будет также бази-роваться на XSD-модели. Но для этого несколько видоизменим нашу агрегированную XML-схему с отношениями типа «один ко многим»: компонент Author включим в состав компонента Resource и переопре-делим вторичный ключ refAuthorResource, как показано на рис. 5.7.

Рис. 5.7. Диаграмма XML-схемы, модифицированная для формирования пользовательского интерфейса

101

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

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

Структура модели представлена в виде дерева в окне Schema Tree слева от графического интерфейса пользователя (GUI). А вкладка Design основной области предназначена для отображения дизайна электрон-ной формы, реализованной с помощью механизма «перетаскивания» (drag-and-drop) элементов схемы из окна Schema Tree на вкладку Design.

Рис. 5.8. Дизайн интерфейса пользователя

102

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

На рис. 5.8 приведен спроектированный дизайн интерфейса поль-зователя. Обратите внимание на введенные при элементах содержа-ния надписи, а также заголовок таблицы. Их форматирование опреде-ляется в ходе разработки дизайна и является содержанием таблицы стилей.

Рис. 5.9. Интерфейс пользователя для ввода данных

На рис. 5.9 приведена экранная форма для ввода данных, создан-ная на основе описанного дизайна интерфейса пользователя.

После того как данные компонента Resource были введены в элек-тронную форму, представленную на вкладке Authentic, после нажатия кнопки Save Authentic XML data автоматически формируется экземпляр XML-документа, связанного с XSD-моделью компонента Resource.

На листинге 5.4 приведен текст экземпляра XML-документа, сгене-рированного от данных, введенных в электронную форму в Authentic.

103

Листинг 5.4. Экземпляр сгенерированных XML данных <?xml version="1.0" encoding="UTF-8"?> < Resource_collection xsi: SchemaLocation="Resourse_collection.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <Resource> <idResource>1</idResource> <Title>Алгебра</Title> <URL>www.algebra.ru</URL> <Description>Учебник алгебры для 10 класса</Description> <Organization>УлГТУ</Organization> </Resource> <Author> <idAuthor>1</idAuthor> <FirstName>Федоров</FirstName> <LastName>Клим</LastName> <Middle>П.</Middle> <Degree>д.т.н.</Degree> <refResource>1</refResource> </Author> <Author> <idAuthor>2</idAuthor> <FirstName>Петров</FirstName> <LastName>Иван</LastName> <Middle>А.</Middle> <Degree>к.т.н.</Degree> <refResource>1</refResource> </Author> <Author> <idAuthor>3</idAuthor> <FirstName>Нилов</FirstName> <LastName>Сергей</LastName> <Middle>И.</Middle> <Degree>к.т.н.</Degree> <refResource>1</refResource> </Author> </Resource_collection> Обратите внимание на то, что шаблон данного XML-документа

был уже сформирован на этапе генерирования XML-файла по XML-схеме (см. листинг 5.2).

Итак, к данному моменту на основе XML-схемы мы сгенерировали

104

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

5.2.4 ОТОБРАЖЕНИЕ XML-ДОКУМЕНТА В БАЗУ ДАННЫХ Таким образом, все, что остается в нашем процессе сквозного

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

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

Рис. 5.10. Диаграмма отображения XML-документа на схему БД

На рис. 5.10 приведена диаграмма отображения между XML-доку-ментом и схемой базы данных, сгенерированной по XML-схеме. В этом примере мы отобразили поля ввода данных XML на реляционные таб-

105

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

XML, мы отображаем id-поля от экземпляров компонента Resource и со-ответствующих элементов компонента Authors на ссылки, определен-ные на связывающей таблице Resource_Author.

Рис. 5.11. Скрипт отображения XML-документа на схему базы данных

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

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

Рис. 5.12. Результат отображения XML-документа на схему базы данных

106

По созданному отображению генерируется код (на языке Java, C#), который формирует скрипт для вставки данных XML-документа в поля таблиц базы данных.

На рис. 5.11 приведен сформированный скрипт, который после выполнения приводит к вставке данных XML-документа в поля таблиц базы данных. Результат выполнения скрипта можно просмотреть, от-крыв соответствующую базу данных. В нашем случае – это база дан-ных, созданная с помощью СУБД Access (см. рис. 5.12).

5.2.5 ОТОБРАЖЕНИЕ БАЗЫ ДАННЫХ В XML-ДОКУМЕНТ Отображение данных можно выполнить и в обратном направле-

нии, т. е. из базы данных в XML-документ. Диаграмма такого отобра-жения приведена на рис. 5.13.

Рис. 5.13. Диаграмма отображения Схемы базы данных на XML-схему Как видно из приведенного рисунка, логика отображения «база

данных → XML-документ» сложнее логики отображения, рассмотренного выше.

Объясняется это тем, что в данном случае требуется: – во-первых, ввести критерий отбора записей базы данных; – во-вторых, сравнить введенный критерий с данными из базы; – в-третьих, сопоставлять значения первичных ключей родитель-

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

107

С этой целью в диаграмму отображения «база данных – XML-доку-мент» вводятся:

– элемент ввода NomerResource для ввода номера ресурса; – первый логический элемент equal, обеспечивающий сравнение

введенного значения NomerResource со значениями ключевого поля idResource;

– первый элемент Filter, обеспечивающий считывание записей из базы данных по результатам сравнения в элементе equal;

– второй логический элемент equal, обеспечивающий сравнение значений первичного ключа idResource со значениями вторичных клю-чей refResource, для выявления тех записей из таблицы Author, которые связаны с выбранной записью из таблицы Resource;

– второй элемент Filter, обеспечивающий считывание записей из таблицы Author по результатам сравнения во втором элементе equal.

Как и в предыдущем случае, по созданному отображению генери-руется код (на языке Java или C#), который формирует скрипт для вставки данных XML-документа в поля таблиц базы данных. Результа-том выполнения сгенерированного кода является XML-документ, идентичный приведенному в листинге 5.4.

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

5.3 ПРЕОБРАЗОВАНИЕ XML-СХЕМЫ В ДИАГРАММУ КЛАССОВ UML Предыдущие примеры показали мощь спецификации XSD как

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

В дополнение к приведенным достоинствам модели XSD следует также добавить ее полную совместимость с языком UML. На рис. 5.14 приведена UML-диаграмма, сформированная от XSD-структуры Re-source_collection.

108

Эта диаграмма UML показывает сложный характер схемы. Здесь мы видим, что элемент Resource_collection содержит анонимное опреде-ление типа (это определено как XSD complexType), который, в свою очередь, включает последовательность элементов «один ко многим» Re-source типа ResourceType и Author типа AuthorType.

Кроме того, на боковой панели Model Tree диаграммы UML показа-ны определения типов ResourceType и AuthorType. Здесь же приведены описания всех связей, имеющих место в схеме, с указанием их типов.

Рис. 5.14. UML-диаграмма, сформированная от XML-документа

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

109

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

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

В будущем роль XSD-специфицированной модели данных только станет возрастать, поскольку обработки данных типа XPath 2.0 и XQuery, основанные на XML-технологиях, достигли широкого распро-странения.

КОНТРОЛЬНЫЕ ВОПРОСЫ 1. В чем сходство моделированием данных методами специфика-

ции XSD с методами моделирования ER и UML? 2. Опишите композиционные и агрегированные модели в специ-

фикации XSD. 3. Назовите преимущества проектирования компонентов инфор-

мационной системы на основе XML-схемы. 4. Расскажите о способе формирования экземпляра XML-докумен-

та по XML-схемы. 5. Опишите процесс создания постоянного хранилища данных

XML-документа. 6. Опишите процесс отображения XML-документа в базу данных. 7. Опишите процесс отображения базы данных в XML-документ. 8. Опишите процесс отображения базы данных в UML-диаграмму.

110

ЗАКЛЮЧЕНИЕ

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

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

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

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

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

Язык UML принадлежит объектному миру. Этот мир гораздо слож-нее реляционного мира. Поскольку UML может использоваться для

111

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

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

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

112

СПИСОК ЛИТЕРАТУРЫ

1. Петров В.Н. Информационные системы. – СПб. : Питер, 2003. –688 с.

2. ГОСТ 34.003-90. Автоматизированные системы. Термины и оп-ределения. – М., 1990.

3. ГОСТ 19.101-77. Единая система программной документации. Виды программ и программных документов. – М., 1977.

4. Емельянова Н.З., Партыка Т.Л., Попов И.И. Основы построения автоматизированных информационных систем : учебное пособие. – М. : ФОРУМ-ИНФРА-М, 2005. – 415 с.

5. Основы методологий проектирования автоматизированных сис-тем обработки информации и управления : учебное пособие / сост. : А.В. Иващенко. – Самара : СНЦ РАН, 2009. – 40 с.

6. Кулябов Д.С., Королькова А.В. Введение в формальное мето-ды описания бизнес-процессов : учебное пособие. – М. : РУДН, 2008. – 173 с.

7. Маклаков. С.В. CASE-средства разработки информационных сис-тем. – М. : Диалог – МИФИ, 2004. – 256 с.

8. Буч Г., Рамбо Д., Джекобсон А. Язык UML. Руководство пользо-вателя: пер. с англ. – М. : ДМК, 2000. – 432 с.

9. Моррисон М. HTML и XML. Быстро и эффективно. – СПб. : Пи-тер, 2005. – 303 с.

10. Холзнер С. XML. Энциклопедия. – 2-е изд. – СПб. : Питер, 2004. – 1001 с.

11. Гарольд Э., Минс С. XML. Справочник : пер. с англ. – СПб. : Символ-Плюс, 2002. – 576 с.

12. Рей Э. Изучаем XML : пер. с англ. – СПб. : Символ-Плюс, 2001. – 408 с.

113

ГЛОССАРИЙ

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

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

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

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

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

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

https://ru.wikipedia.org/wiki/%D0%9A%D0%BB%D0%B0%D1%81%D1%81_(%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5)

https://ru.wikipedia.org/wiki/%D0%9F%D0%BE%D0%BB%D0%B5_%D0%BA%D0%BB%D0%B0%D1%81%D1%81%D0%B0

https://ru.wikipedia.org/wiki/%D0%9C%D0%B5%D1%82%D0%BE%D0%B4_(%D1%8F%D0%B7%D1%8B%D0%BA%D0%B8_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F)

https://ru.wikipedia.org/wiki/%D0%9C%D0%B5%D1%82%D0%BE%D0%B4_(%D1%8F%D0%B7%D1%8B%D0%BA%D0%B8_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F)

https://ru.wikipedia.org/wiki/%D0%9E%D0%B1%D1%8A%D0%B5%D0%BA%D1%82%D0%BD%D0%BE-%D0%BE%D1%80%D0%B8%D0%B5%D0%BD%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D0%BE%D0%B5_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5

114

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

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

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

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

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

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

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

115

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

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

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

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

Модель «сущность-связь» (ER-модель – англ. Entity-relationship model или entity-relationship diagram) – модель данных, которая позво-ляет описывать концептуальные схемы с помощью обобщенных конструкций блоков. ER-модель – это метамодель данных, то есть средство описания моделей данных. ER-модель удобна при проек-тировании информационных систем, баз данных, архитектур ком-пьютерных приложений и других систем (моделей). С помощью такой модели выделяют существенные элементы (узлы, блоки) мо-дели и устанавливают связи между ними.

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

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

http://dic.academic.ru/dic.nsf/ruwiki/1527943

http://dic.academic.ru/dic.nsf/ruwiki/1527943

116

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

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

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

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

Простой тип данных (simpleType) в языке XML Schema – элементы, не имеющие в своем составе других элементов или атрибутов.

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

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

Сложный тип данных (complexType) в языке XML Schema – эле-менты, содержащие другие элементы.

117

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

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

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

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

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

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

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

118

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

CASE-технология – технология автоматизированного созда-ния и сопровождения ПО различных систем.

XML-схема представляет собой определение структуры XML-документа (ее организации и применяемых в ней типов данных). Язык XML Schema описывает способ определения в схеме каждого элемента и позволяет указать типы данных, связанных с каждым элементом.

119

ПРЕДМЕТНЫЙ УКАЗАТЕЛЬ

А Агрегированная модель, XSD .... 92 Анализ, системный ...................... 13 Ассоциация, UML ....................... 51 Ассоциация, агрегатная, UML ... 53 Ассоциация, композиционная, UML .............................................. 54 Атрибут ........................................ 22 Атрибут, ключевой ...................... 24 Атрибут, неключевой .................. 26

Б База данных .................................. 12

Д Диаграмма, UML ......................... 46 Документ, XSLT .......................... 83 Документа, разметка ................... 65 Документа, содержание .............. 66 Документа, структура ................. 66 Документа, форматирование ...... 66 Документа, шаблон ..................... 82

З Зависимость, UML ...................... 49

И Интерфейс пользователя .......... 101

К Кардинальность, схема, XML .... 72 Класс, UML .................................. 47 Класс, атрибут, UML ............. 47, 48 Класс, инвариант, OCL ............... 57 Ключ, XML схема ........................ 75

Ключ, альтернативный ............... 25 Ключ, внешний ............................ 25 Ключ, внешний, XML схема ...... 76 Ключ, внешний, идентифицирующий ................... 26 Ключ, внешний, неидентифицирующий ............... 26 Ключ, первичный ........................ 24 Ключ, первичный, искусственный ............................. 25 Ключ, составной .......................... 24 Композиционная модель, XSD .. 91

М Методология: IDEF0 ................... 20 Модель, концептуальная ............ 16 Модель, логическая ..................... 17 Модель, объектная, UML ........... 45 Модель, реляционная .................. 98 Модель, физическая .................... 18

Н Нормализация данных ................ 29

О Обеспечение ИнфС, информационное ......................... 12 Обеспечение ИнфС, информационное, внемашинное ............................... 12 Обеспечение ИнфС, информационное, внутримашинное ......................... 12 Обеспечение ИнфС, математическое ........................... 11

120

Обеспечение ИнфС, программное ................................ 11 Обобщение, UML ........................ 50 Операция, OCL ............................ 59 Определение ограничений, XML схема ................................... 74 Отношение .................................... 34 Отношение, UML ........................ 46 Отношение, идентифицирующее .................... 37 Отношение, количество элементов ..................................... 36 Отношение, направленность ...... 36 Отношение, неидентифицирующее ................ 37 Отношение, степень .................... 35 Отношения, роли ......................... 39 Отображение базы данных ......... 84 Отображение, XML схема на UML-диаграмму ........................ 107 Отображение, XML схемы на БД ........................................... 104 Отображение, БД на XML схему ............................ 106

П Процессор, XML .......................... 69 Процессор, XSL ........................... 82

Р Роль, кратность, UML ................. 52

С Связь ............................................. 22 Система, автоматизированная .... 12 Система, информационная ..... 6, 11 Система, информационная, проект ........................................... 12 Сущность ...................................... 22 Сущность, ER-модели ................. 27 Сущность, UML ........................... 46 Сущность, ассоциативная ........... 28

Сущность, зависимая .................. 27 Сущность, кодовая ...................... 28 Сущность, независимая .............. 27 Сущность, подтип ....................... 39 Сущность, связанная ................... 26 Сущность, сержневая .................. 27 Сущность, супертип .................... 40 Схема, XML ................................. 71

Т Таблица стилей, XSL .................. 79 Тип данных, простой, XML ....... 71 Тип данных, сложный, XML ...... 72 Типы данных, определение ........ 73

Ф Фасет, XML схема ....................... 73

Ч Часть ИнфС, обеспечивающая... 11 Часть ИнфС, функциональная ... 11

Ш Шаблона, инструкция по преобразованию .......................... 82 Шаблона, последовательность ... 82

Э Элемент enumeration, XML схема ................................... 74 Элемент ограничения, unique .... 75 Элемент ограничения, xpath ...... 75 Элемент-составитель, all ............ 74 Элемент-составитель, choice ...... 74 Элемент-составитель, sequence . 72 Этап, предпроектный .................. 13 Этап, проектирования ................. 14 Этап, развертывания ................... 14 Этап, разработки ПО ................... 14

121

A ASCII-текст .................................. 67

C CASE-технология .......................... 8

E ER-модель .................................... 23

H HTML ............................................ 66 HTML-документ .......................... 84

I IDEF, семейство ........................... 20 IDEF1, методология .................... 21 IDEF1X, методология ................. 21 IDEF2, методология .................... 21 IDEF3, методология .................... 21 IDEF4, методология .................... 21 IDEF5, методология .................... 21

O OCL ............................................... 45

S SGML ............................................ 66 SQL, язык ..................................... 19 SQL-скрипт .................................. 98

U UML .............................................. 45

W Web-технология .......................... 65

X XML .............................................. 65 XML-документ ............................ 67 XML-схема ................................... 68 XML-элемент ............................... 67 XSD .................................................. 65

Учебное издание

ТОКМАКОВ Геннадий Петрович

АВТОМАТИЗИРОВАННОЕ ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННЫХ СИСТЕМ

Учебное пособие

Редактор Н. А. Евдокимова

ЛР №020640 от 22.10.97 Подписано в печать 07.08.2015. Формат 60×84/16.

Усл. печ. л. 7,21. Тираж 100 экз. Заказ 642.

Ульяновский государственный технический университет 432027, г. Ульяновск, ул. Сев. Венец, 32.

ИПК «Венец» УлГТУ, 432027, г. Ульяновск, ул. Сев. Венец, 32.

user

Машинописный текст

ЭИ № 527.

Documents

Г. П. Токмаков АВТОМАТИЗИРОВАННОЕ ...venec.ulstu.ru/lib/disk/2015/167.pdf · 2015. 10. 2. · Пособие предназначено для студентов