Учебное пособие Допущено Министерством образования Российской Федерации в качестве учебного пособия для студентов высших учебных заведений, обучающихся по специальности

Вид материала

Содержание

Ссылочная целостность
Дополнительные ограничения
Е– слабое множество сущностей, то каждое из множеств F
Переход от E/R-диаграмм к реляционным проектам
Семья, полагая, что тройкой в множестве отношений для Семья
5. Базы данных в сетях
5.1. Архитектура "клиент-сервер"

Подобный материал:

1 2 3 4 5 6 7 8 9 10

Ссылочная целостность

В E/R-диаграммах можно расширить функции стрелок таким образом, чтобы они показывали, ожидается ли ссылочная целостность данной связи в одном или нескольких направлениях. Пусть R – это связь множества сущностей Е с множеством сущностей F. Стрелка с закругленным "острием", указывающая на F, означает не только то, что Е и F находятся в связи типа "многие-к-одному" или "один-к-одному", но и то, что должно существовать множество Е. То же самое относится к случаю, когда R – связь между более чем двумя атрибутами.

Пример 4.23. На рис. 59 показано ограничение ссылочной целостности для множеств Изделия, Цеха и Начальники. Эти множества и связи впервые были введены на рис. 47 и рис. 48. Закругленная стрелка, указывающая от связи обеспечивает на множество Цеха выражает ограничение ссылочной целостности, состоящее в том, что цех, обеспечивающий работу над изделием, должен всегда присутствовать в множестве Изделия.

Аналогично, вторая закругленная стрелка от Возглавляет к Цеха, означает: если начальник возглавляет цех, то этот цех обязательно существует в множестве Цеха.

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

Дополнительные ограничения

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

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

В E/R диаграммах соответствующим образом помечают линии между символами связи и множества сущностей, как в следующем примере (рис. 60).

Слабые множества сущностей

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

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

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

Пример 4.24.

Д

анный пример иллюстрирует описание иерархии, которая отображается с использованием слабых множеств сущностей. В цехе может работать несколько бригад, которые обозначаются "бригада 1", "бригада 2" и т.д. Но так же могут обозначить свои бригады и другие цеха, поэтому атрибут номер не является ключом для бригад. Для определения уникального имени бригады необходимы название цеха, которому она принадлежит, и номер. Такая ситуация изображена на рис. 61. Ключ для слабого множества сущностей Бригады состоит из его собственного атрибута номер и атрибута название единственного цеха, с которым данная бригада находится в связи Часть_ от типа "многие-к-одному".

Ключевые атрибуты для слабого множества сущностей нельзя получить произвольным образом. Если Е– слабое множество сущностей, то каждое из множеств F, поставляющих один ключевой атрибут для Е или более, должно быть соединено с Е связью R. Кроме того, необходимо выполнить следующие условия:

R должно быть бинарной связью типа "многие-к-одному" между E и F.
Атрибуты F, используемые в ключе для Е, должны быть ключевыми атрибутами множества F.
Если F само является слабым, атрибуты F, используемые в ключе для Е, могут быть атрибутами множества сущностей, с которым F соединено связью типа "многие-к-одному.
Если есть несколько связей типа "многие-к-одному" между Е и F, эти связи можно использовать для получения копий ключевых атрибутов F, позволяющих сформировать ключ для Е. Заметим, что сущность е из Е может быть связана с многими сущностями в F посредством различных связей из Е. Поэтому ключи многих различных сущностей из F могут появляться в ключевых значениях, идентифицирующих отдельную сущность е из Е.

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

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

Эти соглашения суммируются в виде правила:

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

В объектно-ориентированных системах вопрос о поиске ключа никогда не возникает, всегда можно построить ключ путем описания атрибута или атрибутов, хотя это и необязательно. Объект обладает свойством "целостности объекта" и в результате имеет адрес, по которому его можно найти, a ID объекта уникальным образом отличает один объект от другого даже тогда, когда их невозможно различить по значениям их атрибутов или связям. А E/R-модель "ориентирована на значение", и сущности различимы только по связанным значениям их атрибутов. Поэтому нужно всегда учитывать, что в E/R-моделях сущности любого множества можно различать только по значениям, не обращаясь ни к какой "идентичности объектов".

Переход от E/R-диаграмм к реляционным проектам

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

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

все слабые сущности в одной таблице (а);
для каждой слабые сущности – отдельная таблица (б).

При применении способа (а) таблица создается для наиболее внешнего супертипа, а для подтипов могут создаваться представления.

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

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

общий домен (а);
явные внешние ключи (б).

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

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

Преимущества перехода к схеме БД от E/R-моделей по сравнению с ODL-проектом заключаются в следующем:

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

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

Контрольные вопросы и задания

Пояснить основные положения объектно-ориентированного проектирования.
Каким образом представляются объекты в ODL?
Как описываются атрибуты в ODL?
Охарактеризовать типы связей в ODL.
Привести пример обратной связи в ODL.
Привести пример связи "многие-ко-многим" в ODL.
Привести пример связи "многие-к-одному" в ODL.
Привести пример связи "один-к-одному" в ODL.
Перечислить базовые типы данных в ODL.
Чем отличается тип множество от типа мультимножество?
Перечислить принципы проектирования с использованием ODL.
Что такое подкласс?
Привести пример множественного наследования в ODL.
Каким образом осуществляется моделирование ограничений в ODL?
Какова последовательность действий для преобразования ODL-модели в реляционную?
Перечислить компоненты E/R диаграммы.
Каким образом выражается множественность связей в E/R диаграммах?
Привести примеры многосторонних связей.
В чем заключается суть ролей в связях?
Привести пример перемещения атрибута в множество сущностей.
Описать слабые множества сущностей.
Какова технология конвертирования многосторонних связей в бинарные?
Указать рекомендации по проектированию E/R-моделей.
Каким образом выбираются типы элементов проекта?
Для чего предназначена связь isa?
Как осуществляется моделирование ограничений в E/R-модели?
Описать технологию перехода от E/R-модели к реляционной модели.
Спроектировать БД предприятия, содержащую информацию о сотрудниках и отделах, в которых работают сотрудники. Информация о сотруднике – это его имя, адрес, телефон, должность, номер паспорта. Отдел имеет название, число сотрудников, начальника. Описать в ODL данную БД.
Описать в ODL БД, содержащую следующую информацию о командах, игроках и их спонсорах:

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

Изменить предыдущее задание, указав, за какие команды выступал каждый из игроков, включая начальную и конечную даты его выступления за каждую из команд.
Составить генеалогическое дерево династии. Имеется единственный класс. Информация, которую необходимо записать о человеке, состоит из его имени (атрибут) и следующих связей: мать, отец и дети. Опишите в ODL класс Особа. Обязательно указать обращения связей, которые, подобно, мать, отец и дети, служат и связями класса Особа с самим собой. Является ли дети инверсией связи мать? Почему? Описать каждую связь и ее обращение как множества пар.
Допустимо ли, чтобы тип был одновременно типом атрибута ODL и типом связи ODL? Объяснить, почему.
В условия задания 1 добавлены новые элементы – проекты. Проект имеет название, общий бюджет, объединяет несколько сотрудников для его выполнения. Описать такую БД в ODL.
Представить БД предприятия из задания 1 в виде Е/R-модели. Обязательно ввести стрелки (там, где они необходимы) для выражения множественности связи.
Представить БД команды/игроки /болельщики из задания 2 в виде E/R-модели. Учтите, что множество цветов – неподходящий тип атрибута для команд. Как можно обойти это ограничение?
Альтернативный способ представления информации задания 4, ввести тернарную связь Семья, полагая, что тройкой в множестве отношений для Семья является (особа, отец, мать) и все ее члены, разумеется, входят во множество Люди.

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

Пусть в условиях задания 1 каждый отдел имеет сектор, с названиями сектор1, сектор2, и т.д. Сотрудники относятся непосредственно к секторам. Привести полную Е/R – диаграмму такой информационной системы.
Один из способов представления студентов и оценок, полученных ими на учебных курсах, использование множеств сущностей, соответствующих студентам, курсам и "зачислениям". Зачисления образуют множество "связующих" сущностей между студентами и курсами. Их можно использовать не только для представления того факта, что студент проходит определенный курс, но для выражения отметок, полученных студентом по данному курсу. Представить эту ситуацию в E/R-диаграмме, указав слабые множества сущностей и их ключи. Является ли отметка частью ключа для "зачислений"?
Выбрать и определить ключи для ODL-разработок из задания 1.
Выбрать и определить ключи для Е/R – диаграмм из задания 2.

5. БАЗЫ ДАННЫХ В СЕТЯХ

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

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

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

В этой главе мы рассмотрим некоторые варианты распределенной обработки данных .

5.1. Архитектура "клиент-сервер"

Определим основные понятия сервер и клиент. Под сервером в информационных системах понимается программа (компьютер), предоставляющая услуги по запросам других программ (компьютеров), называемых клиентами. В контексте баз данных вводится понятие сервер баз данных [15]:

СУБД в архитектуре "клиент-сервер".
Компьютер в сети, на котором поддерживается база данных и осуществляется обработка пользовательских запросов.

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

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

Клиентские узлы поддерживают пользовательские интерфейсы и функциональность приложений.

Основой архитектуры "клиент-сервер" является принцип централизации хранения и обработки данных. Централизованная база данных физически сосредоточена в одном месте и управляется одним компьютером-сервером. Классическая двухзвенная схема "клиент-сервер" представлена на рис. 62.

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

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

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

В модели удаленного доступа к данным (Remote Data Access, RDA) на сервере хранится база данных и ядро СУБД. На клиенте располагается презентационная логика и бизнес-логика. Клиент обращается к серверу с запросом на языке SQL, либо посредством средств пользовательского интерфейса (API). Данную модель поддерживает большое число серверных СУБД, имеющих SQL-интерфейсы, и инструментальных средств, обеспечивающих создание клиентской части.

Модель сервера БД ( Database Server – DBS) характеризуется тем, что функции компьютера-клиента ограничиваются презентационной логикой. Большая часть бизнес-логики переложена на сервер. Иногда такую модель называют моделью с "тонким клиентом". Эта модель является более технологичной, чем RDA и применяется в таких СУБД как Informix, Ingres, Sybase, Oracle, SQL MS Server.

С

уществуют и более сложные варианты реализации архитектуры "клиент-сервер", например, трехзвенные информационные системы с использованием серверов приложений, реализующих бизнес-логику информационной системы (модель сервера приложений – Application Server (AS)) (рис. 63).

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

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

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

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

Под монитором обработки транзакций (Transaction Processing Monitor – TPM) понимаются средства программного обеспечения промежуточного слоя, предназначенные для обеспечения эффективного управления информационными и вычислительными ресурсами в распределенных системах при обработке транзакций. Понятие транзакции в TPM шире, чем транзакция в СУБД. Основными функциями TPM являются: аутентификация пользователей и проверка полномочий доступа, управление коммуникациями, необходимыми для выполнения транзакций, собственно управление транзакциями, включая управление блокировкой ресурсов, журнализацию, фиксацию, откаты и восстановление транзакций [15].

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

Blog

Содержание

Ссылочная целостность