К12

К13

12

13

Петров

Сидоров

К22

П2

Информатика

К11

К12

К12

К13

К13

К22

К21

К22

К21

К22

12

13

11

12

13

Петров

Сидоров

Иванов

Петров

Сидоров

П1

П1

П2

П2

П2

Математика

Математика

Информатика

Информатика

Информатика

CUSTOMER

Функции АБД

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

Функциональные зависимости и детерминанты

Функциональные  зависимости  (ФЗ)  позволяют  накладывать  дополнительные  ограничения  на  реляционную  схему.  Основная  идея  состоит  в  том,  что  значение  одного  атрибута  в  кортеже  однозначно  определяет  значение  другого  атрибута.  Например,  в  каждом  кортеже  таблицы 3.1  №  работника  однозначно  определяет  фамилию; №  работника  однозначно  определяет специальность.  Записываются  эти  две  функциональные  зависимости  следующим  образом:

ФЗ : №  работника ¾> фамилия,

ФЗ : №  работника ¾>

специальность.

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

Более  формально  мы  можем  определить функциональную  зависимость  следующим  образом:  если  А  и  В – атрибуты  в  таблице  R,  то  запись

ФЗ :  A¾>

В

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

Обозначение ¾>  читается  «функционально  определяет». 

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

Идентификация пользователя

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



чего-то,  что  пользователь  знает,  например,  номер  подключения  и  пароля;

      чего-то,  чем  пользователь  обладает,  например,  пластиковая  идентификационная  карточка;

      Физической  идентификации  (отпечатка  пальца  или  голоса).

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

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

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

      Когда  у  вашей  подруги  день  рождения?

      Чем  примечательно  для  вас  2  сентября?

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

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

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

Иерархические и сетевые модели систем

Индексно-последовательные файлы решили проблему прямого обраще­ния к определенной записи в файле. Для примера посмотрим снова на рис. 1.2. Если мы прочли первую запись о продажах в файле SALE и хотим узнать имя и адрес клиента, с которым была заключена эта сделка, мы можем просто воспользоваться идентификатором клиента (100), чтобы посмотреть соответствующую запись в файле CUSTOMER. Таким образом, мы выясним, что заказ был сделан компанией братьев Уотэйб.

Теперь предположим, что нам требуется обратный процесс. Вместо того чтобы выяснять, с каким клиентом заключена сделка, мы хотим найти все продажи данному клиенту. Мы начнем с записи «Братья Уотэйб» в файле CUSTOMER, а затем найдем все продажи этой компании. В файловой сис­теме мы не сможем напрямую получить ответ на наш вопрос. Именно для подобных прикладных задач и были придуманы системы управления базами данных.

Первая информационная система, использующая базы данных, появив­шаяся в середине шестидесятых годов, была основана на иерархической мо­дели, что означает, что отношения между данными имеют иерархическую структуру. Для того чтобы пояснить это, слегка изменим базу данных, при­веденную на   рис. 1.2. Вместо продаж, записанных в виде одной строки, у нас будут счета-фактуры, которые, в свою очередь, состоят из нескольких строк. К каждому клиенту может относиться несколько таких счетов, и ка­ждый счет может состоять из нескольких строк. Каждая строка обозначает продажу одного товара. На рис. 1.7 представлен пример. Теперь вместо файла SALE у нас есть файлы INVOICE (СЧЕТ) и INVOICE LINE (СТРОКА-СЧЕТА).

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

CUSTOMER
Индексы По определениям ключей (первичных или вторичных, см.         п. 2.2) СУБД автоматиче­ски строит индексы, которые представляют собой механизмы быстрого доступа к хранящимся в таблицах данным.                    Сущность индексов состоит в том, что они хранят отсортированные значения ин­дексных полей (т.е. полей, по которым построен индекс) и указатель на запись в таб­лице. Например, пусть имеется таблица, показанная на рис. 2.11. Порядковый № записи Дата прихода товара Наименование товара Количество, кг 1 10.12.1999 Сахар 10 2 12.12.1999 Картофель 50 3 12.12.1999 Свекла 20 4 14.12.1999 Сахар 50 5 14.12.1999 Свекла 10 6 16.12.1999 Сливы 4 Рис. 2.11 Физическая структура таблицы С логической точки зрения ее индексы выглядит так, как показано на рис. 2.12. Индекс по дате прихода товара Индекс по наименованию товара Индекс по количе­ству Дата прихода № за­писи Наименование товара № записи Количе­ство № записи 10.12.99 1 Картофель 2 4 6 12.12.99 2 Сахар 1 10 1 12.12.99 3 Сахар 4 10 5 14.12.99 4 Свекла 3 20 3 14.12.99 5 Свекла 5 50 2 16.12.99 6 Сливы 6 50 4 Рис. 2.12. Логическая структура индексов Обратите внимание: значения полей в индексе («Дата прихода», «Наименование товара», «Количество») сортируются по возрастанию, что существенно ускоряет поиск нужных значений. Если, например, нужно выбрать все записи с наименованием товара «Свекла», нет нужды просматривать всю таблицу. Достаточно найти в индексе, построенном по столбцу «Наименование товара», первый указатель на запись, содер­жащую товар «Свекла», и считать из таблицы эту запись, а затем повторить то же для всех иных указателей в индексе на записи с товаром «Свекла». Поскольку значения полей отсортированы, поиск первого указателя осуществляется специальными мето­дами быстрого поиска и реализуется значительно быстрее, чем если бы поиск шел по неотсортированным полям таблицы. Такой метод доступа к записям таблицы называ­ется индексно-последовательным, потому что: · поиск ведется по индексу, а не по таблице; · доступ начинается с первой строки, удовлетворяющей условию запроса или его части; · строки в индексе, начиная с первой найденной записи, просматриваются после­довательно. В том случае, если в условия запроса входят поля, по которым не построено индексов, ищется иной пригодный индекс, а если такого индекса нет, производится последователь­ный перебор записей таблицы БД (в некоторых СУБД, например, использующих техно­логию ADO, в этом случае может быть построен вспомогательный индекс). Информационные системы, использующие До сих пор мы обсуждали информационные системы, использующие базы данных, и их возможности лишь в общих терминах. Теперь пришло время более внимательно взглянуть на то, из чего состоит такая система. Информационная система - это нечто большее, чем просто данные или дан­ные в сочетании с программным обеспечением базы данных. Полная инфор­мационная система, использующая базы данных, состоит из четырех компонентов: оборудования, программного обеспечения, данных и людей. Оборудование Оборудование (или «железо») - это набор физических устройств, на ко­торых существует база данных. Оно состоит из одного или нескольких ком­пьютеров, дисководов, мониторов, принтеров, магнитофонов, соединитель­ных кабелей и других вспомогательных и соединительных устройств. Рис. 1.15. Три возможные конфигурации оборудования для информационных систем Для обработки данных в базах данных могут использоваться универ­сальные вычислительные машины, мини-компьютеры или персональные компьютеры. В нашем предыдущем примере фирма IPD начинала с мини-компьютера, затем они перешли на универсальную вычислительную ма­шину. Универсальные ЭВМ и мини-компьютеры традиционно используются в качестве основы для поддержания доступа многих пользователей к общей базе данных. Персональные компьютеры часто используются для баз дан­ных, с которыми работает один пользователь. Они, однако, могут быть со­единены в сеть по принципу клиент/сервер, обеспечивая доступ нескольких пользователей к общей базе данных, хранимой на дисках и управляемой сервером. Сервером может служить более мощный настольный компьютер, мини-компьютер или универсальная ЭВМ. На рис. 1.15 представлены раз­личные конфигурации устройств. Основным способом хранения баз данных является хранение на дисках, что существенно, поскольку к ним возможен произвольный доступ, без которого работать с базой данных невозможно. Настольные компьютеры, мониторы и принтеры используются для ввода и извлечения информации из базы данных. Ленты являются недорогим средством быстрого создания резервных копий данных, хранящихся на дисках. Успешная работа информационных систем, использующих базы данных, сильно зависит от совершенства технологии устройств. Для поддержания и управления огромным количеством данных, хранящихся в базе данных, требуется очень большой объем оперативной памяти и дисков. Кроме того, в системе с большим числом пользователей для того, чтобы за приемлемое время извлекать нужную им информацию, необходимо быстро выполнять огромное количество обращений к данным, для чего требуется высокое бы­стродействие компьютеров, сетей и периферийных устройств. К счастью, за годы развития баз данных мощность компьютерного оборудования сильно выросла, а стоимость значительно снизилась. Благодаря этому стало воз­можным широкое распространение информационных систем, использующих базы данных. Программное обеспечение Информационная система, использующая базу данных, включает в себя два вида программного обеспечения: q     Программное обеспечение общего назначения для поддержания базы данных, обычно называемое системой управления базой данных (СУБД). q     Прикладное программное обеспечение, которое использует средства СУБД для выполнения конкретных деловых задач, таких как вы­ставление счетов или анализ продаж. Прикладное программное обеспечение обычно создается сотрудниками компании для решения конкретных задач компании. Оно может быть напи­сано на стандартном языке программирования типа Кобола или Си или же на языке (обычно называемом языком четвертого поколения), входящем в комплект системы управления базой данных. Прикладные программы ис­пользуют средства СУБД для обращения к данным и их обработки, создавая отчеты или документы, необходимые для работы компании. Система управления базой данных (СУБД) - это системное программ­ное обеспечение, аналогичное операционной системе или компилятору, об­служивающее конечных пользователей, программистов и т.д. Как следует из названия, СУБД предназначена для того, чтобы обеспечивать управление базой данных. Обычно СУБД выполняет следующие функции: q     Централизованное определение и контроль данных, известное под названием словарь/каталог данных. q     Защита данных и обеспечение их целостности. q     Одновременный доступ к данным для нескольких пользователей. q     Ориентированные на пользователя возможности запросов, обработки и извлечения данных. q     Ориентированные на программиста возможности создания прикладных систем. Словарь/каталог данных. Подсистема словаря/каталога данных следит за определениями всех элементов данных базы, включая элементарные группы данных (поля), структуры данных на уровне групп и записей, файлы или реляционные таблицы. Эту информацию поддерживает не только словарь данных, но именно он отслеживает отношения, существующие ме­жду различными группами данных. Кроме того, он поддерживает индексы, служащие для быстрого обращения к данным. Он также отслеживает уста­новки формата вывода данных, которые могут использоваться различными прикладными программами. Словарь данных можно рассматривать как часть самой базы данных. То­гда база данных будет самоописываемой, поскольку она содержит информа­цию, описывающую ее собственную структуру. Информация в словаре дан­ных называется метаданными, то есть «данными о данных». Метаданные доступны для запросов и манипуляций, как и любые другие данные базы. Метаданные - данные в словаре данных, описывающие базу данных. Механизмы защиты и поддержания целостности данных. База данных - это ценный ресурс, нуждающийся в защите. СУБД защищает базу дан­ных, не предоставляя несанкционированного доступа к ней. Полномочия пользователей могут быть различны с точки зрения того, к каким данным им разрешено обращаться, и имеют ли они право обновлять данные. Такой доступ контролируется системой паролей и представлениями данных, то есть описаниями ограниченных частей базы данных, как показано на рис. 1.16. Целостность и непротиворечивость базы данных обеспечивается ограничениями на значения элементов данных, а также путем создания СУБД резервных копий, делающих возможным восстановление данных. Описания ограничений на значения элементов данных хранятся в словаре данных. Резервные копии и восстановление поддерживаются программами, которые автоматически фиксируют внесенные в базу данных изменения и обеспечивают возможность восстановления текущего состояния базы данных в случае сбоя в системе.   Рис. 1.16. Пользовательские представления данных в базе данных Представление данных - описание ограниченной части базы данных. Одновременный доступ к данным для нескольких пользователей. Одна из главных функций СУБД состоит в поддержании доступа, извлечения и обновления данных базы. СУБД обеспечивает физические механизмы, по­зволяющие многим пользователям быстро и эффективно обращаться к боль­шому количеству связанных данных. Это распространяется и на удаленных пользователей, которые обращаются к базе данных через систему телеком­муникаций. Средства СУБД обеспечивают взаимодействие с телекоммуникационными системами, адекватно обрабатывая запросы и выдавая результаты. Централизованное хранение данных в базе является причиной высокой вероятности того, что двум или более пользователям потребуется одновре­менный доступ к одним и тем же данным. Если СУБД это позволяет, то два пользователя наверняка повлияют на работу друг друга и могут испортить ее. Таким образом, важно, чтобы СУБД не допускала такой ситуации, когда один пользователь обращается к данным, а другой в то же время вносит в них изменения. Для этого в СУБД используются сложные блокирующие ме­ханизмы, защищающие данные, которые в текущий момент обновляются пользователем, и в то же время обеспечивающие одновременный доступ к данным и приемлемое время реакции системы для других пользователей. Ориентированные на пользователя запросы и отчеты. Одна из наиболее ценных черт СУБД - это ориентированные на пользователя средства работы с данными. Простые языки запросов предоставляют пользователям возмож­ность формулировать запросы и получать одноразовые отчеты прямо из базы данных. Это избавляет программистов компании от необходимости форму­лировать эти запросы или писать специальные прикладные программы. С языками запросов связаны генераторы отчетов. Часто язык запросов содержит средства оформления результатов запроса в виде отчета. Сам сформулированный запрос зачастую можно сохранить и использовать в дальнейшем для составления регулярных отчетов. В этом случае язык за­просов можно рассматривать как генератор отчетов. Кроме того, к системе могут прилагаться генераторы отчетов, обладающие более широкими воз­можностями, чем встроенные в язык запросов. Средства создания прикладных программ. Кроме того, что СУБД упро­щает пользователю обращение к базе данных за информацией, она часто серьезно помогает и разработчикам прикладных программ. Стандартными являются такие средства, как окна, меню и генераторы отчетов, генераторы приложений, компиляторы, а также средства описания данных и выборок. Что более важно, современные информационные системы, использующие базы данных, укомплектованы языками, значительно более мощными, чем традиционные, что сильно повышает эффективность самого процесса про­граммирования. Данные Очевидно, что ни одна база данных не может существовать без данных, основных фактов, на которых базируется вся информация, необходимая в работе компании. Однако следует заметить, что данные, из которых состоит база данных, должны быть тщательно и логично организованы. Необходимо проанализировать бизнес-функции, установить и точно определить элементы данных и отношения между ними, а определения аккуратно внести в сло­варь данных. После этого в соответствии с определенной структурой в базу можно вносить данные. Гармонично организованная база данных может стать мощным источником обеспечения организации своевременной информацией. Люди В случае IPD мы видели два типа людей, работающих с базой данных. Сьюзан Броудбент и Дик Гринберг - пользователи, то есть люди, которым информация базы данных требуется для выполнения их прямых служебных обязанностей, которые лежат в несколько иной области. Сэнфорд Мэллон и Корделия Молини - обслуживающий персонал, то есть люди, чьими пря­мыми обязанностями является создание и поддержание информационной системы и соответствующего прикладного программного обеспечения, необ­ходимого пользователям. Приведем примеры людей, входящих в эти две категории: 1. Пользователи: руководители, менеджеры, конторские служащие. 2. Обслуживающий персонал: администраторы базы данных, аналитики, программисты, системные разработчики, менеджеры информационных систем. Пользователи - люди, которым требуется информация базы данных для вы­полнения прямых служебных обязанностей. Обслуживающий персонал - люди, ответственные за работу информационной системы, использующей базы данных, и соответствующего прикладного программного обеспечения.        Процедура - письменные инструкции, описывающие шаги, необходимые для выполнения в системе определенной задачи. Процедуры, которые люди используют для выполнения своих задач в системе, являются важным аспектом. В действительности ни одна система не автоматизирует полностью работу пользователя. Приходится разрабаты­вать инструкции, обеспечивающие бесперебойное взаимодействие между пользователями системы и самой системой. Примером такой процедуры мо­жет служить аудиторский контроль, посредством которого пользователи проверяют, соответствует ли общая сумма, помещенная в банк в определен­ный день, общей сумме полученных в этот день наличных денег, отраженной в системе. Обычно в системе есть множество подобных процедур, и зачастую успешная работа системы зависит от того, насколько хорошо процедуры увязаны с функциями самой системы. Отношения между четырьмя компонентами системы На рис. 1.17 в сжатом виде представлены отношения между четырьмя компонентами системы. Обслуживающий персонал (аналитики и разработ­чики базы данных), советуясь с пользователями,  определяет  необходимые данные и создает структуру базы данных, отвечающую потребностям поль­зователей. Затем структура базы данных сообщается СУБД через словарь данных. Пользователи вводят в систему данные, следуя определенным про­цедурам. Хранение введенных данных обеспечивается оборудованием, таким как диски или ленты. Прикладные программы, обслуживающие доступ к базе данных, разрабатываются программистами, а пользователи запускают их на компьютерах. Эти программы пишутся на командном языке СУБД, и в них используется информация, содержащаяся в словаре данных. Эти про­граммы выдают информацию, которая может использоваться менеджерами и руководством компании при принятии решений. Прикладные программы также могут печатать счета и другие документы для клиентов фирмы. Та­ким образом, мы видим, что в удачно разработанной и функционирующей системе все четыре компонента - оборудование, программное обеспечение, данные и люди - взаимодействуют, образуя единую систему, выполняющую нужные организации задачи.   Рис. 1.17. Четыре компонента информационной системы, использующей базы данных: оборудование, программное обеспечение, данные и люди Информационные системы, использующие базы данных Информационные системы, использующие базы данных, позволили пре­одолеть ограничения файловых систем. Поддерживая целостную, централи­зованную структуру данных, информационные системы, использующие базы данных, позволили избавиться от проблем избыточности и слабого контроля данных. Доступ к централизованной базе данных имеет вся компания, и если, например, необходимо внести изменение в имя клиента, это изменение будет известно всем пользователям. Данные контролируются посредством словаря/каталога данных (data dictionary/directory, DD/D), которым, в свою очередь, управляет группа сотрудников компании, называемых администра­торами базы данных (АБД). Новые методы обращения к данным сильно уп­ростили процесс связывания элементов данных, что привело к расширению возможностей работы с данными. Все эти характеристики систем управления базами данных упрощают процесс программирования и уменьшают необходимость программной поддержки. В настоящее время процесс создания максимально мощных систем управления базами данных идет полным ходом. За несколько десятилетий последовательно появлялись системы, основанные на трех базовых моделях данных, или концептуальных методах структурирования данных: иерархическая, сетевая и реляционная. Исторический контекст Сети -  это способ  представления  отношений   между  объектами.  Они  широко  применяются  в  математике,  исследованиях  операции,  физике  и  других  областях  знаний. Сети  обычно  представлены  математической  структурой,  которая  называется  направленным  графом.   Граф  состоит  из  точек  или  узлов,  которые  соединены  стрелками  или  ребрами.  В  сетевой  модели  узлы  можно  представлять  как  типы  записей  данных,  а  ребра – как отношения  один-к-одному  или  один-ко-многим.   Таким  образом,  сетевая  модель  данных  представляет  данные  сетевыми  структурами  типов  записей,  которые  связаны  отношениями  один-к-одному  или  один-ко-многим.  В  1971 году  был  опубликован  официальный  стандарт  сетевых  баз  данных,  который  получил  название  CODASYL.  Появление  стандарта  увеличило  популярность  сетевой  модели,  и  многие  компании  создали  свои  версии  сетевой  СУБД.   Хотя  сетевая  модель  данных  в  будущем  может  все  больше  уступать  место  на  рынке  СУБД  реляционной  модели  данных,  сегодня  она  эффективно  служит  во  многих  информационных  системах. Контроль изменений Если  на  фирме  «Хелми»  операции  ведутся  таким  образом, что  количество  не  распределенного  со  склада  товара,  указанного в  таблице  СОДЕРЖИМОЕ_НАРЯДОВ_НА_ПРО-ДАЖУ,  не  может  увеличиваться,  всякий  прирост  этого  показателя  должен  фиксироваться,  расцениваясь  как  возможная  ошибка.  СУБД  оснащаются  средствами,  которые позволяют  объявлять  ограничения,  накладываемые  на  характер  изменения  переменных. Еще  один  пример  ограничений  такого  типа.  В  «Хелми»  считается  недопустимым,  чтобы  содержимое  атрибута  КОЛИЧЕСТВО_НА_СКЛАДЕ  в  таблице  ТОВАРНЫЕ_ЗАПАСЫ  возрастало  после  единичной  корректировки на величину, превышающую  ЗАКАЗЫВАЕМОЕ КОЛИЧЕСТВО.  Если  это  правило  нарушается,  СУБД  должно  известить  пользователя  об  ошибке. Контроль типов Информация,  хранящаяся  в  БД,  должна  быть  в  меру  возможности  правильной,  точной  и  согласованной.  Необходимо  предусматривать  средства,  которые  бы  защищали  базу  от  потенциально  неверных  действий,  связанных  с  корректировкой  данных  и  записью  новой информации. Одним  из  распространенных  способов  защиты  является  контроль  типов.   Простейший  вариант  -  проверка  принадлежности  переменной выделяемому  для  нее  диапазону  величин.  Если, например,  установлено,  чтобы  содержимое  атрибута  НОМЕР_КЛИЕНТА  находилось  в  пределах  от  100000  до  999999,  то  система  должна  предотвратить  попытку  пользователя  присвоить  этому  полю  значение  403.  Другой  пример:  торговые  зоны,  где  располагаются  фирмы-клиенты,  сокращенно  обозначаются  Ю,  ЮЗ,  З,  СЗ, С, СВ,  В,  ЮВ.  Недопустимо,  чтобы  система  позволила  записать  в  атрибут ТОРГОВАЯ_ЗОНА  значение  «МОСКВА». Контрольные вопросы 1. Объясните  своими  словами  смысл  терминов: ·       Нормализация. ·       Избыточность  данных. ·       Аномалия  обновления. ·       Аномалия  ввода. ·       Атомарное  значение. ·       Нормальная  форма  Бойса-Кодда.  2.  Объясните,  почему  нежелательны  таблицы,  не  подчиняющиеся  второй  или  третьей  нормальной  форме. 1. Объясните своими словами смысл терминов: ·       Система обработки данных. ·       Произвольный доступ. ·       Информационно-управляющая система. ·       База данных. ·       Информационная система, использующая базы данных. ·       Модель данных. ·       Иерархическая модель. ·       Указатель. ·       Сеть. ·       Принцип клиент/сервер. ·       Открытые системы. ·       Возможность взаимодействия (совместимость). ·       Система управления базой данных. ·       Представление данных. ·       Процедура. ·       Метаданные.                                           2.       Каковы важнейшие характеристики файловых систем с последовательным и произвольным доступом? От каких недостатков файлов последовательного доступа избавлены файлы произвольного доступа? 3.       Объясните важность информации как ресурса организации. Каким образом информационные системы, использующие базы данных, способствовали повышению ценности информации для организаций? 4.       Дайте сравнительную характеристику иерархических, сетевых и реляционных информационных систем, использующих базы данных. Какие потребности бизнеса привели к появлению каждой из них? 5.       Перечислите и кратко охарактеризуйте каждый компонент современной информационной системы, использующей базы данных. 6.       Опишите каждый из следующих компонентов системы управления базой данных (СУБД): ·       Словарь/каталог данных. ·       Защита и поддержание целостности данных. ·       Обеспечение одновременного доступа нескольких пользователей. ·       Запрос данных, обработка данных, вывод данных. ·       Средства создания прикладных систем. 7. Приведите примеры: ·       Пользователей. ·       Обслуживающего персонала. LINE-#		PROD-ID		QTY		TOTAL-PRICE
1012 1012 1012 1015 1015 1020 1020		01 02 03 01 02 01 02		1035 2241 2518 1035 2518 2241 2518		100 200 300 150 200 10 150		2200.00 6650.00 6360.00 3300.00 4240.00 3325.00 3180.00

Рис. 1.7. Файлы IPD, имеющие иерархическую структуру

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

Указатель -

физический адрес, обозначающий место хранения записи на диске.

Предположим, что мы хотим добавить в нашу иерархическую базу дан­ных информацию о клиентах. Например, если наши клиенты - торговые компании, нам может понадобиться список магазинов каждой компании. В этом случае мы расширим диаграмму, приведенную на рис. 1.8, придав ей вид, представленный на рис. 1.9. Файл CUSTOMER по-прежнему находится над файлом INVOICE, который находится над файлом INVOICE LINE. Но в то же время с файлом CUSTOMER связан файл STORE (МАГАЗИН), а с ним — файл CONTACT (ПРЕДСТАВИТЕЛЬ). Под представителем мы подразумеваем закупщика, которому продаем товары для конкретного магазина. Из этой диаграммы мы видим, что клиент является вершиной иерархии, из ко­торой мы можем извлечь немало информации.

Рис. 1.8. Иерархическая модель отношений между файлами CUSTOMER, INVOICE и INVOICE LINE

 Метод поалфавитной подстановки

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

1. Ключ пишется под текстом и повторяется столько раз, чтобы полностью «закрыть»  текст:

идет снег

защитазащ.

2. Будем считать, что пробел занимает тридцать третье и последнее место в алфавите. Для каждого символа сложим номер в алфавите символа текста  и соответствующего символа ключа, разделим на 33 и  сохраним остаток. Заменим символ текста на символ, имеющий вычисленный номер. В нашем примере под пробелом (33) стоит  т (19), таким образом (33+19)= 52, остаток от деления на 33 равен 19.

На 19 месте в алфавите стоит буква т, поэтому вместо пробела в зашифрованном тексте будет т.

Многотабличные запросы

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

Запрос:  Вывести  специальности  рабочих,  назначенных  на  здание  435.

Данные,  необходимые  для  ответа,  находятся  в  двух  таблицах:  «Работник»  и  «Работа».  Для  решения  в  SQL  требуется  перечислить  обе  таблицы  в  команде  FROM  и  задать  специальный  тип  условия  WHERE:

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

  FROM  Работник,  Работа

  WHERE   Работник. № работника = Работа. № работника

              AND  № здания  = 435

Рассмотрим  два  этапа  обработки  системой  данного  запроса.

1.   Сначала  обрабатывается  фраза  FROM.  Однако  в  этом  случае,  поскольку  в  команде  указаны  две  таблицы,  система  создает  декартово  произведение  строк  этих  таблиц.  Если  в  команде  FROM  перечислено  более  двух  таблиц,  то  создается  декартово  произведение  всех  таблиц,  указанных  в  команде.

2.   После создания  гигантской  реляционной  таблицы  система  применяет  команду  WHERE.  Каждая  строка  таблицы,  созданной  командой  FROM,  проверяется  на  выполнение  условия  WHERE.  Строки,  не  удовлетворяющие  условию,  исключаются  из  рассмотрения.  Затем  к  оставшимся  строкам  применяется  фраза  SELECT.

Фраза  WHERE  в  данном  запросе  содержит  два  условия: 

1. WHERE   Работник. № работника = Работа. № работника

2.  № здания  = 435

 Первое  из  этих  условий – условие  соединения.  Так  как  обе  таблицы  содержат  столбец  с  именем  «№ работника», их  декартово  произведение  будет  содержать  два  столбца  с  таким  именем.  Для  того  чтобы  различить  их,  помещаем  перед  именем  столбца  имя  исходной  таблицы,  отделяя  его  точкой.

Полное  соединение  этих  двух  таблиц  представлено  на  рис. 7.2.

Необходимость произвольного доступа к данным

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

Для того чтобы программа расчета причитающихся сумм обрабатывала продажи вместе с файлом CUSTOMER, файл SALE должен быть упорядочен по индексу клиента. По­скольку продажи, скорее всего, вводились как попало, нам придется упоря­дочивать файл SALE, прежде чем использовать его в качестве исходных данных для программы. Это показано на рис. 1.3. Однако, если файл SALE упорядочен по индексу клиента, он наверняка находится в полном беспо­рядке относительно индекса товара. Таким образом, общую сумму продажи невозможно посчитать, обратившись к файлу PRODUCT. Из-за этого служа­щие вынуждены вводить лишние данные, что требует дополнительной за­траты ручного труда и увеличивает количество ошибок.

Необходимость последовательного доступа к файлам иным образом вы­нуждает пользователей выполнять лишнюю работу. Например, другая про­грамма IPD подсчитывает комиссионные со сделок и составляет счета на оп­лату работы агентов. Для того чтобы подсчитать комиссионные, причитаю­щиеся агенту, мы снова должны упорядочить файл SALE, на сей раз по SALREP-ID. И только после этого мы можем обрабатывать файлы SALE и SALES-REPRESENTATIVE вместе, чтобы составить счета на оплату работы агентов (рис. 1.4).

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

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

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

1.3. Информация как ресурс

 

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

Нормализация отношений

Нормализация отношения

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

Рассмотрим  реляционную  таблицу  на  рис.  3.1.  После  небольшого  анализа  видно,  что  реляционная  таблица  на  рис. 3.1  спроектирована  неудачно.  Например,  в  четырех  кортежах,  соответствующих  рабочему  1412,  повторяется  одно  и  то  же  имя  и  информация  о  типе  специальности.  Эта  избыточность  данных  или  повторение  приводит  не  только  к  потере  лишнего  места;  она  может  вызвать  нарушение  целостности  данных  (противоречивость)  в  базе  данных.

Избыточность  данных -  повторение  данных  в  базе  данных.

Целостность  данных  -  согласованность  данных  в базе  данных.

                            Таблица   3.1.   «Работник»

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

Аномалия  обновления -  противоречивость  данных,  вызванная  их  избыточностью и  частичным  обновлением.  

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

Аномалия  удаления -   непреднамеренная  потеря  данных,  вызванная  удалением  других  данных.

Аномалия  ввода -  невозможность  ввести  данные  в  таблицу,  вызванная  отсутствием  других  данных.

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

Нормализация - за и против

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

Рис.3.20. Нормализованная база данных

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

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

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

Нормальная форма Бойса-Кодда (НФБК)

Реляционная  таблица  находится  в  нормальной  форме  Бойса-Кодда  (НФБК),  если  для  любой  ФЗ:  X¾>  Y,  X ( то есть детерминанта) является возможным  ключом отношения.  Из  определения  следует,  что  любая  таблица,  удовлетворяющая  НФБК,  также  удовлетворяет  и  2НФ,  однако  обратное  неверно.

Рассмотрим  таблицу 3.9 «Оплата за работу». №  Работника  является  ключом,  следовательно,  в  таблице  имеются  функциональные  зависимости:

ФЗ: №  Работника ¾>  Разряд;

ФЗ: №  Работника ¾>  Оплата.

Однако  также  имеется  функциональная  зависимость

ФЗ: Разряд ¾>

Оплата.

Атрибут «разряд» является детерминантой, так как он однозначно определяет атрибут «оплата», но «разряд» не может быть ключом отношения, поэтому в таком виде отношение «Оплата за работу»  не удовлетворяет НБКФ. Но  таблица 3.9     удовлетворяет  2НФ  (так  как  неключевые атрибуты «разряд» и «оплата»).  Таким  образом,  таблица  может  быть  в  2НФ,  но  не  в  НФБК.

Таблица   3.9.   «Работник»

Чем  плохи  таблицы,  не  удовлетворяющие  НФБК?  Вызванные  ими  проблемы  схожи  с  перечисленными  для  таблиц,  нарушающих  2НФ:

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

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

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

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

Объединение

Объединение – операция  выполняется  над  двумя совместимыми таблицами  R1,  R2.   В  результате  этой    операции    строится  новая  таблица  R = R1 U R2.   Таблица  R  имеет тот  же  состав  атрибутов  и кортежей  исходных  таблиц.   Причем  одинаковые  кортежи  не  дублируются.

Пример.  Ниже  приведены  исходные  таблицы:  R1  «Клиенты  банка  А»  (табл.4.1)  и   R2  «Клиенты  банка  В»  (табл. 4.2)  и  результат  объединения  - R  (табл.4.3).

             Таблица 4.1. R1 «Клиенты  банка  А»

          Таблица 4.2. R2 «Клиенты  банка  В»

                  Таблица  4.3.   R  «Клиенты»

В  новую  таблицу  R  не  вошел  кортеж  К21,  так  как  он  дублирует  кортеж  К11.

4.2.  Пересечение

Пересечение – операция  выполняется  над  двумя    совместимыми  таблицами  R1,  R2.  В  результате  этой  операции  получается  новая  таблица  RP = R1  З  R2. Эта  таблица содержит  одинаковые  кортежи, которые  есть  в  каждой  из  двух  исходных  таблиц.

Пример.  Пересечение  двух  таблиц  R1 «Клиенты  банка  А»  и   R2  «Клиенты  банка  В»  дает  одну  таблицу  R  «Клиент» (табл. 4.4).                     

   Таблица 4.4. Пересечение  отношений

Обработка транзакций

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

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

1. Изменение записи клиента: уменьшение суммы счета на 500 $.

2. Изменение  кассовой  записи:  увеличение  суммы  на  500 $.    

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

Для  обработки  транзакций  требуется,  чтобы  СУБД  поддерживала  запись  транзакции  для  каждого  изменения,  вносимого  в  БД.  Один  из  способов – применение  протокола.  Когда  клиент  платит  500 $  по  счету,  транзакция  включает  1) уменьшение  счета  клиента  и  2) увеличение  кассового  счета.  Во  время  выполнения  транзакции  все  записанные  операции  задерживаются  до  тех  пор,  пока  не  будет  выполнено  последнее  действие  транзакции.  Результаты  обновления  записываются  в  протокол  транзакций.  Когда  все  действия  выполнены,  информация  об  обновлении  из  протокола  используется  для  переноса  обновленной  информации  в  соответствующие  записи  данных.

                                                   ДЕЙСТВИЯ                                                         РЕЗУЛЬТАТ

СЧЕТ  КЛИЕНТА                        1.
Оплата                СЧЕТ  КЛИЕНТА

                                                         кредита

 № Клиента   Баланс                      500 $.                 № Клиента       Баланс

Операции с данными в реляционной модели

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

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

Определения и понятия

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

Часть реального мира, сведения о   которой  хранятся  в  БД,  называется  предметной  областью  (ПО)  базы  данных.

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

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

Например,  СТУДЕНТ,  ПРЕПОДАВАТЕЛЬ,  УЧЕБНАЯ  ДИС-ЦИПЛИНА,  АУДИТОРИЯ  -  объекты  ПО  «Учебный  процесс».   ПАЦИЕНТ,  ПАЛАТА,  ВРАЧ  -  объекты  ПО  «Больница».

Объекты  обладают  определенным  набором  свойств,  которые  называются    атрибутами.   Например: фамилия  студента, номер  студбилета,   номер  группы,  адрес  -  атрибуты,  соответствующие  характеристикам  объекта  ПО  СТУДЕНТ.  Объект     ПРЕПОДАВАТЕЛЬ  имеет   такие  атрибуты,  как:  фамилия,  номер  диплома,  специальность,  ученая  степень  и  т.д.

 В таблице 2.1 приведены экземпляры объекта ПРЕПОДАВАТЕЛЬ с атрибутами НОМЕР, ФИО, Кафедра.

Основные понятия и определения

В  сетевой  модели  существуют  два  основных  понятия:  типы  записей  и  наборы.  Типы  записей -  это  совокупность  логически  связанных  записей.  Например,  тип  записи  клиент  может  включать  такие  элементы  данных,  как  ИД-Клиент,  Имя,  Адрес,  Сумма-Счета,  Дата-Последнего-Платежа.  Все  типы  записей  -  это  заданные  имена,  такие  как  КЛИЕНТ,  СЧЕТ,  ТОРГОВЫЙ  АГЕНТ  и  т.д.

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

Отношение многие-ко-многим

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

Таблица «Учебные группы            Таблица

и дисциплины»                             «Преподаватели»

Рис. 2.5. Связь многие-ко-многим

Некоторые СУБД не поддерживают связи многие-ко-многим

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

была заменена на одну или более связей один-ко-многим.

Отношение один-к-одному

Отношение один-к-одному имеет место, когда одной записи в родительской табли­це соответствует одна запись в дочерней таблице (рис. 2.4.).

       Таблица «Сотрудники»                      Таблица «Информация

                о сотрудниках»

Рис. 2.4 Связь один-к-одному.

Данное отношение встречается много реже, чем отношение один-ко-многим.

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

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

Подобно связи один-ко-многим, связь один-к-одному может быть жесткой и неже­сткой.

Отношение один-ко-многим

Таблица «Товары»                Таблица «Отпуск товаров»

Рис. 2.3. Связь один-ко-многим

Как видно из рис. 2.3, одной записи из родительской таблицы «Товары» может со­ответствовать несколько записей в дочерней таблице «Отпуск товаров». Обратите внимание на глагол может: он означает, что такая возможность - потенциальная и что в родительской таблице могут быть записи, для которых в данный момент нет записей в дочерней таблице (например, товар «Куры»).

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

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

Параллельная работа с БД

Предположим,   что  Лига  Женщин-Избирателей (ЛЖИ)  из  Москвы  решила  устроить  обед  с  окороком  и  индейкой.  Коммерческая  Палата  (КП)  из  Томска    решила,  что  пришло  время  порадовать  своих  членов  обедом  с  окороками  и  овощами.  Каждая  организация  обратилась  в  своем  городе  в  представительство  фирмы  «Хелми».  ЛЖИ  требует  25  окороков,  КП  нужно  35  окороков.  Оба  заказа  передаются  в  систему  БД  регионального  склада  одновременно  (рис. 5.2).  Заказ  ЛЖИ  приходит  на  долю  секунды  раньше,  чем  заказ  КП. 

КЛ

">

ЛЖИ

">                                                                                  ЛЖИ

                                                                                                     Москва  

                                                                                    КП                                              

ЛЖИ                                                                        КП

	(1)Чтение записи  об  окороках (2)Вычитание 25 окороков (3)Переписывание  записи об      окороках		(4)Чтение записи  об  окороках (5)Вычитание 35 окороков (6)Переписывание  записи об      окороках

                  Порядок  обработки  ЦП 

Первая нормальная форма

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

Атомарное  значение

- значение,  не  являющееся  множеством  значений  или  повторяющейся  группой.

 Любая  реляционная  таблица  находится  в  1НФ.  Для  того  чтобы  пояснить  понятие,    рассмотрим  пример  таблицы  3.2,  не  удовлетворяющей  этому  условию.

                                    Таблица   3.2.   «Работник»

Значение  атрибута  № здания – это  множество  зданий,  на  которых  работает  данный  человек.  Предположим,  что  мы хотим получить список рабочих, отделывающих здание 435.  Извлечь  эту  информацию  может  оказаться  непросто,  так  как  идентификатор  нужного  нам  значения  запрятан  внутри  множества  в  кортеже. Реляционная  таблица 3.2  не  соответствует  1НФ,  так  как  значения атрибута  № здания не  являются  атомарными. Однако  таблица 3.1 имеет  1НФ,  так  как  нужное  нам  значение,  то  есть номер  конкретного  здания,  может  быть  выбрано  путем  простой  ссылки  на  имя  атрибута               № здания.

Первичные ключи и индексы

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

Первичные ключи облегчают установление связи между таблицами. В таблице «Покупатель» таким ключом является одноименное поле. Установив связь по пер­вичному ключу, мы можем выяснить, что, например, 10.02.1999 года со склада было отпу­щено 100 единиц товара «Сахар» покупателю «Геракл, ТОО», офис которого распо­ложен по адресу: 107005, Москва, 2-я Бауманская ул., 12 (телефон для связи 273-00-14).

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

И таблица:

№№

Покупатель

Подзапросы Подзапрос  может  помещаться  в  команду  WHERE  запроса,  в  результате  чего  возможности  команды  WHERE  расширяются.  Рассмотрим  пример. Запрос:  Вывести  специальности  рабочих,  назначенных  на  здание  435? SELECT  Специальность     FROM  Работник     WHERE  № работника  IN                         (SELECT   № работника                             FROM   Работа                             WHERE  № здания = 435 ) Подзапрос  в  этом  примере                                                      (SELECT   № работника                             FROM   Работа                             WHERE  № здания = 435 ) Запрос,  в  котором  содержится  подзапрос,  называется  внешним  запросом  или  главным  запросом.  Подзапрос  приводит  к  созданию  следующего  множества № работников:   № Работника    1412    1235 Затем  это  множество  «№ Работников»  занимает  место  подзапроса  во  внешнем  запросе.  С  этого  момента  выполняется  внешний  запрос,  использующий  множество,  созданное  подзапросом.  Внешний  запрос  обрабатывает  каждую  строку  таблицы  «Работник»  в  соответствии  с  условием  WHERE.  Если  «№ работника»  строки  лежит  во  множестве,  созданном  подзапросом, то  «Специальность»  строки  выбирается  и  выводится  в  результирующей  таблице:   Специальность  Штукатур  Электрик Очень  важно,  что  фраза  SELECT  подзапроса  содержит  «№ работника»  и  только   «№ работника.  В  противном  случае  фраза    WHERE  внешнего  запроса,  означающая,  что  «№ работника»  лежит  в  множестве  «№  работников»,  не  имела  бы  смысла. Подзапрос  может  логично  выполняться  прежде,  чем  хотя  бы  одна  строка  рассматривается  главным  запросом.  В  некотором  смысле  подзапрос  независим  от  главного  запроса.  Он  может  выполняться  как  полноценный  запрос.  Такой  подзапрос  называется  некоррелированным  подзапросом.  Приведем  пример  подзапроса  внутри  подзапроса. Запрос:  Вывести  фамилии  работников,  назначенных  на  здания  офисов.                  SELECT  Фамилия   FROM  Работник   WHERE  № работника  IN                        (SELECT   № работника                          FROM   Работа                          WHERE  № здания   IN                                              (SELECT   № здания                                                FROM   Здание                                                 WHERE  Тип = 'Офис' ))               Результат:       Фамилия      И. Петров Нигде  не  нужно  указывать  перед  именами  столбцов  имена  таблиц,  поскольку  каждый  подзапрос  обрабатывает  одну  и  только  одну  таблицу,  так  что  никаких  неопределенностей  возникнуть  не  может.  Выполнение  запроса  происходит  в  порядке  изнутри  наружу. Коррелированный  подзапрос  -  подзапрос,  результат  которого  зависит  от  строки,  рассматриваемой  главным  запросом. Ниже  приведен  пример  такого  подзапроса.        Запрос:  Вывести  фамилии  работников,  чьи  почасовые  ставки выше,  чем  ставки  их  менеджеров.                    SELECT  Фамилия   FROM  Работник  А   WHERE  А. Недельная зарплата  >                        (SELECT  B.Недельная зарплата                          FROM   Работник  В                          WHERE  В.№ работника = А.№ менеджера)               Результат:       Фамилия       К.  Иванов        Обратите  внимание,  что  поскольку  «А. Недельная  зарплата»  может  сравниваться  только  с  одной  величиной,  подзапрос  должен  выдавать  только  одну  величину.  Эта  величина  меняется  в  зависимости  от  того,  какая  строка  А  рассматривается.  Таким  образом,  подзапрос  коррелирует  с  главным  запросом. Преимущества и недостатки иерархических моделей В  иерархической  модели  связи  между  данными,  имеющими  какой-либо  общий  признак,  отражены  в  виде  дерева-графа,  где  возможны  только  односторонние  связи  от  старших  вершин  к  младшим.  Это  облегчает  доступ  к  необходимой  информации,  но  только  если  все  возможные  запросы  отражены  в  структуре  дерева.  Никакие  иные  запросы  удовлетворены  быть  не  могут.  Использование  иерархических  моделей  ускоряет  доступ  к  информации  в  базе  данных.  Но  поскольку  каждый  элемент  данных  должен  содержать  ссылки на  некоторые  другие  элементы,  требуются  значительные  ресурсы  как  дисковой,  так  и  основной  памяти  ЭВМ.  Недостаток  основной  памяти,  конечно,  снижает  скорость  обработки  данных,  для  таких  моделей  характерна  сложность  реализации  СУБД.  Преимущества и недостатки сетевых моделей Достоинством  сетевых  моделей  является  отсутствие  дублирования  данных  в  различных  элементах  модели.  Кроме  того,  технология  работы  с  сетевыми  моделями  является  удобной  для  пользователя,  так  как  доступ  к  данным  практически  не  имеет  ограничений  и  возможен  непосредственно  к  объекту  любого  уровня.  Недостатки  сетевой  модели,  в  основном,  связаны  со  слабыми  возможностями  адаптации  к  изменяющимся  требованиям  и  выполнения  разовых  запросов. Кроме  того,  для  таких  моделей  характерна  сложность  реализации  СУБД.  Проекция Проекция  -   операция  выполняется  над  одной  таблицей  R. Операцию  проекция  можно  представить  как  исключение  ненужных   столбцов.  Новая  таблица  может  содержать  меньше  кортежей,  так  как  после  исключения  из  исходной  таблицы  R  ненужных  атрибутов  могут  образоваться  кортежи,  которые  дублируют  друг  друга. Пример.  Ниже  приведен  пример  исходной  таблицы  R  «Служащий»  (табл.4.11)  и  результат  проекции  (RPR)  (табл.4.12).                                                  Таблица 4.11.  R «Служащий» Служащий Номер отдела Должность Иванов Петров Нестеров Никитин 01 02 01 02 Инженер Инженер Инженер Лаборант       Таблица 4.12   Отношение  RPR Номер  отдела Должность 01 02 01 02 Инженер Инженер Инженер (*) Лаборант Примечание:  (*) – удаляемый  кортеж - дубликат. Простые запросы   Простой  запрос -  запрос,  который  обращается  только  к  одной  таблице  базы  данных. Ниже  приведены  примеры  простых  запросов. Работник   № рабо-  Фамилия     Недельная     Спец-ть       № Менеджер  тника                           зарплата                       1235         И. Петров            12.50          электрик            1311      1412         К. Иванов            13.75          штукатур           1520 2920         Р. Смирнов          10.00          кровельщик       2920 1520         Г. Сидоров           11.75          штукатур           1412 1311         Х. Васильев          15.50          электрик             1311 Работа   № рабо-       № здания       Дата_начала        Число_дней тника 1235                        312                      10.10                      5      2920                        460                      05.10                      18        1235                        435                      17.10                      22    3231                        111                      10.10                      8         1412                        435                      15.10                      15             1311                        460                      23.10                      24 Здание    № здания       Адрес                          Тип  312                   ул. Вязов, 123             офис  435                   ул. Кленов, 456           склад  515                   ул. Березовая, 12        магазин     210                   ул. Нахимова, 4           склад   Рис.  5.1.  База  данных  строительной  компании  «Премьер» Запрос:  Вывести  фамилии штукатуров?              SELECT  Фамилия              FROM     Работник              WHERE   Специальность =  'Штукатур'   Результат:           Фамилия           К. Иванов           Г. Сидоров Этот  запрос  иллюстрирует  три  наиболее  часто  встречающиеся  фразы  SQL:  SELECT,  FROM  и  WHERE.  В  данном  примере  мы  поместили  их  на  разные  строки,  они  все  могут  стоять  в  одной  строке.  Они  также  могут  помещаться  с  разными  отступами,  а  слова  внутри  фраз  могут  разделяться  произвольным  числом  пробелов.  Рассмотрим  характеристики  каждой  фразы: Select.  Фраза  SELECT  перечисляет  столбцы,  которые  должны  войти  в  результирующую  таблицу.  В  данном  примере  результирующая  таблица  состоит  из  одного  столбца   (Фамилия),  но  в  общем  случае  она  может  содержать  несколько  столбцов;  она  также  может  содержать  вычисленные  значения  или  константы.   Если  результирующая  таблица  должна  содержать  более  одного  столбца,  то  все  нужные  столбцы  перечисляются после  команды  SELECT  через  запятую.  Например,  фраза  SELECT  №  работника,  Фамилия  выдает  в  результате  таблицу,  состоящую  из  столбцов    «№  работника»  и  «Фамилия». From.  Фраза  FROM  задает одну  или  более  таблиц,  к  которым  обращается  запрос.  Все  столбцы,  перечисленные  во  фразах  SELECT  и  WHERE,  должны  существовать  в  одной  из  таблиц,  перечисленных  в  команде  FROM.  Where.  Фраза  WHERE  содержит  условие,  на  основании  которого  выбираются  строки  таблицы  (таблиц).  В  данном  примере  условие  состоит  в  том,  что  столбец  Специальность   должен  содержать  константу  ‘Штукатур’,  заключенную  в  апострофы.  Фраза  WHERE  -  наиболее  изменчивая  команда  SQL;  она  может  содержать  множество  разнообразных  условий. Приведенный  выше  запрос  SQL  обрабатывается  системой  в  следующем  порядке:  FROM,  WHERE,  SELECT. В данном  примере  из  каждой  такой  строки  выбирается  Фамилия,  и  все  выбранные  значения  выводятся  в  качестве  результатов  запроса.   Запрос:  Вывести  все  данные  о  зданиях  офисов.              SELECT  *              FROM     Здание              WHERE   тип =  'Склад' Результат:    Здание № здания            Адрес                            Тип               435                  ул. Кленов 456               склад  210                    ул. Нахимова 4              склад Звездочка (*)  в  команде  SELECT  означает  «строка  целиком». Запрос:  Вывести  недельную  зарплату  каждого  электрика.        SELECT Фамилия,'Недельная  зарплата  = ', 40* Недельная  зарплата        FROM     Работник      WHERE   Специальность = 'Электрик'      ORDER  BY  Фамилия   Результат:   Фамилия М. Петров           Недельная  зарплата = 500.00 Х. Васильев        Недельная  зарплата = 620.00 Этот  запрос  иллюстрирует  употребление  символьных  констант и  вычислений  в  команде  SELECT.  Внутри  команды  SELECT  можно  производить  вычисления,  в  которых  используются  числовые  столбцы  и  числовые  константы,  а  также  стандартные  арифметические  операторы (+,-,*, /),  сгруппированные  по  мере  необходимости  с  помощью  скобок.  Команда  ORDER BY  сортирует  результат  запроса в  возрастающем  алфавитно-числовом  порядке  по  указанному столбцу.  Если  вы  хотите  упорядочить  результаты  по  убыванию,  то  к  команде  нужно  добавить  DESC.  Фраза  ORDER  BY  может  сортировать  результаты  по  нескольким  столбцам,  по  одним – в  порядке  возрастания,  по  другим – в  порядке  убывания.  Первым  указывается  столбец  первичного  ключа  сортировки. Запрос:  Вывести  фамилии  работников, у  которых  почасовая  ставка  от  10  до  12  рублей.      SELECT  *         FROM     Работник      WHERE   Недельная  зарплата > =  10  AND   Недельная  зарплата < = 12       Результат: № рабо-       Фамилия      Недельная          Специальность                                                                                                  тника                              зарплата                    2920         Р. Смирнов         10.00                   кровельщик           520          Г. Сидоров           11.75                   штукатур   Этот  запрос  иллюстрирует  некоторые  дополнительные  возможности  команды  WHERE:  операторы  сравнения  и  булеву  операцию  AND (И).  Для  сравнения  столбцов  с  другими  столбцами  или  с  константами  могут  использоваться  шесть  операторов сравнения  (=,<> (не равно),<, >, <=, >=).  Для  отрицания  условий  могут  использоваться  булевы  операции  AND(И),  OR(ИЛИ),  NOT(НЕТ).  Для  группировки  условий  могут  использоваться  скобки. Для  формулировки  этого  запроса  также  можно  было  использовать  оператор  BETWEEN (между):     SELECT  *         FROM      Работник      WHERE   Недельная  зарплата  BETWEEN  10  AND  12 BETWEEN  может  использоваться  для  сравнения  некоторой  величины  с  двумя  другими  величинами,  первая  из  которых  меньше  второй.  Сравнимая  величина  может  быть  равна  каждой  из  данных  величин  или  любому  значению  между  ними. Запрос:  Вывести  фамилии  штукатуров,  кровельщиков.      SELECT  *         FROM      Работник      WHERE   Специальность  IN  ('штукатур',  'кровельщик')       Результат:    № рабо-     Фамилия           Недельная          Специальность       тника                                      зарплата                            1412             К. Иванов            13.75                  штукатур          2920             Р. Смирнов          10.00                 кровельщик           1520             Г. Сидоров          11.75                  штукатур Этот  запрос  поясняет  использование  оператора  сравнения  IN  (В).  Условие  WHERE  считается  истинным,  если  тип  специальности  строки  расположен  внутри  множества,  указанного  в  скобках, то  есть  если  тип  специальности – штукатур,  кровельщик Предположим,  что  мы  не  можем  точно  вспомнить  написание  специальности:  «электрик»  или  «электронщик»  или  еще  как-то.  Символы  шаблона,  которые  замещают  неопределенные  строки  символов,  облегчают  поиск  неточного  написания  в  запросе. Запрос:  Вывести  фамилии  работников,  чей  тип  специальности  начинается  с  «элек».      SELECT  *         FROM     Работник      WHERE   Специальность  LIKE  ('элек%')       Результат:  № рабо-       Фамилия       Недельная          Специальность тника                                       зарплата                           1235           И. Петров            12.50                   электрик         1311           Х. Васильев         15.50                   электрик  В  SQL  есть  два  символа  шаблона:  % (процент)  и  _  (подчеркивание).  Подчеркивание  замещает  ровно  один  неопределенный  символ.  Процент  замещает  произвольное  число  символов,  начиная с  нуля.  Когда  используются  символы  шаблона,  для  сравнения  символьных  переменных  с  константами  требуется  оператор  LIKE  (как).   Проверка полномочий и представления данных Представление  данных – это  средство  предоставления  пользователю  его  личной  модели  базы  данных.  Это  также  удобный  способ  ограничения  доступа  пользователя  к  различным  частям  базы  данных:  данные,  которые  пользователю  не  нужно  видеть,  просто  спрятаны  от  него.  Это  упрощает  работу  с  системой,  повышая  попутно  защищенность  базы  данных.  Представления  данных  могут  создаться  при  помощи  операции  выбора,  создания  проекций  или  соединения  существующих  таблиц.  Таким  образом,  возможности  пользователя  могут  быть  ограничены  рассмотрением  только  части  некоторой  существующей  таблицы  или  же  соединения  некоторых  таблиц. Типы  доступа  к  представлениям  данных.  Для  каждого  представления  данных  возможны  различные  типы  доступа: 1.    Право  чтения:  позволено  только  чтение  данных,  но  не  их  изменение. 2.    Право  ввода:  позволен  ввод  новых  данных,  но  не  изменение  существующих. 3.    Право обновления:  позволено  изменение  данных,  но  не  их  удаление. 4.    Право  удаления:  позволено  удаление  данных. Эти  типы  доступа  обычно  обеспечиваются  назначением  для  предоставления  данных  нескольких  паролей.  Например,  предположим,  что  у  нас  есть  таблица 4.1 «Работник»  и  мы  хотим,  чтобы  пользователь  Васильев  имел  доступ  только  к  атрибутам  № РАБОТНИКА   и ФАМИЛИЯ,  причем  только  для  чтения.   Этого  можно  добиться,  создав  представление  данных,  содержащее  только  атрибуты  № РАБОТНИКА  и  ФАМИЛИЯ.  Для  представления  данных  № РАБОТНИКА_ФАМИЛИЯ  можно  создать  пароль,  дающий  право  доступа  только  для  чтения (команда SQL): GRANT  READ ACCESS ON № РАБОТНИКА_ФАМИЛИЯ TO  Васильев Общая  форма  такого  предоставления  права  доступа  в  SQL  с  командой  GRANT  выглядит  следующим  образом: GRANT  <список  полномочий >  ON  <имя  представления  данных  или  таблицы> Рассмотрим  пример,  в  котором  используется  таблица  «Проект»,  имеющая  следующую  схему:  ПРОЕКТ (№,  ФАМИЛИЯ, АДРЕС, ПОЧТОВАЯ  ОПЛАТА, ОТДЕЛ).  Например,  пользователю  может  быть,  разрешено  смотреть  только  среднюю  почасовую  оплату  из  таблицы.  Такое  ограничение  поддерживается  следующим  представлением  данных:      CREATE   VIEW AVG  (№,  ФАМИЛИЯ,  СР._ОПЛ., OТДЕЛ) AS  SELECT №,ФАМИЛИЯ,AVG (ПОЧ._ ОПЛ),ОТДЕЛ   FROM   ПРОЕКТ  GROUP BY OТДЕЛ Обратите  внимание,  что в  представлении  данных  создается  атрибут  (СР._ОПЛ),  которого  не  существовало  в  базовой  таблице  «Проект».  Его  значения  вычисляются  командой  SELECT - берется  среднее  значение  атрибута  ПОЧТОВАЯ  ОПЛАТА  для  каждого  отдела. Хотя  применение  представлений  данных  может  быть  эффективным  средством  защиты,  система  должна  уметь  приспосабливаться  к   изменяющимся  со  временем  требованиям.  В  SQL  такую  возможность  дают  команды  GRANT  и  REVOKE.  Приведем примеры: GRANT  SELECT  ON  TABLE  C  TO  Иванов,  Петров Команда  означает,  что  Иванову  и  Петрову  предоставлено  право  применять  любые  операции  SELECT  к  таблице «C». GRANT  SELECT,  UPDATE (ОТДЕЛ)  ON  TABLE  C  TO  Петров Это  означает,  что  Петров  имеет  право  применять  любые  операции  SELECT  к  таблице «C»,  а  также  обновлять  значения  атрибутов  ОТДЕЛ. REVOKE   SELECT  ON  TABLE  C  FROM  Иванов Эта  команда  означает,  что  Иванов  больше  не  имеет  права  выполнять  операции  SELECT  над  таблицей «С». Список  привилегий,  которые  относятся  к  таблицам:  SELECT  (выбор) UPDATE  (обновление) DELETE  (удаление) INSERT  (ввод) Опция  GRANT  может  распространяться   на  других  пользователей.  Например,  если  Иванов  имеет  право  передать  привилегию  А  Петрову,  то  Петров  имеет  право  передать  привилегию  А  другому   пользователю, Васильеву  и т.д.  Иванов: GRANT  SELECT  ON  TABLE  C  TO  Петров  WITH  GRANT  OPTION   Петров: GRANT  SELECT ON  TABLE  C  TO Васильев WITH GRANT  OPTION До  тех  пор  пока  пользователь  получает  GRANT  OPTION,  он  может  передавать  ту  же привилегию  другим  пользователям. Если  Иванов  позже  хочет  отозвать GRANT  OPTION,  то  он  может  сделать  так:  REVOKE  SELECT  ON  TABLE  C  FROM   Петров Такой  отзыв  будет  применен  как  к  Петрову, так и  ко  всем,  кому  он  передал  привилегию,  и  т.д. Работа с пользователями Информационные системы часто состоят из трех компонентов: цен­тральной, наиболее широко используемой базы данных, содержащей боль­шую часть данных фирмы; нескольких функциональных баз данных (например, систем бухгалтерского учета), к которым обращается более узкий круг программ; а также, возможно, нескольких узкоспециализированных баз данных, к которым обращаются отдельные приложения (например, база данных учета материалов). Важный организационный принцип состоит в том, что общим результатом создания информационных систем является централизация значительной части данных компании. Централизация данных обычно исключает индивидуальное владение данными и, таким образом, снижает их избыточность. Владение и управле­ние данными передается центральному словарю данных, который поддержи­вает запись о владельце и возможности использования каждого элемента данных. Такой перенос управления может вызвать сопротивление некоторых пользователей. Преодолеть сопротивление можно при помощи активного просвещения пользователей: знакомства их с преимуществами технологии базы данных, разъяснения того, каким образом база данных может сделать более эффективной и эффектной их работу. АБД в сотрудничестве с руководством должен заниматься таким просвещением. Решение об установке базы данных обычно означает согласие на значи­тельные изменения работы организации на операционном уровне. АБД мо­жет сделать такие изменения более приемлемыми для работников, пропа­гандируя базу данных до начала ее создания. Важность подготовки ключевых работников к использованию базы данных трудно переоценить. Некото­рые аспекты их текущей работы могут быть упразднены с введением базы данных, и стандартная работа систем и программ может значительно изме­ниться. В подготовку желательно включить презентации для менеджеров, учебные семинары для персонала и, возможно, приглашение консультантов со стороны. Обучение обычно является наиболее важным элементом подготовки к изменениям. Обучение должно дать персоналу широкое представление о функционировании данных как составной части информационной системы компании, а также специальные знания о том, как пользователи могут применять систему в своей ежедневной работе. Для того чтобы обучение было полным, оно должно рассматриваться как непрерывный процесс, подталкиваемый приемом новых работников, приобретением нового программного обеспечения, разработкой новых приложений и усовершенствованием старых. Развитие технологии базы данных Сложность современной технологии баз данных явилась результатом развития в течение нескольких десятилетий способов обработки данных и управления информацией. Подталкиваемая, с одной стороны, нуждами и требованиями менеджмента и ограниченная, с другой стороны, возможно­стями технологии, обработка данных развивалась от примитивных методов пятидесятых годов к сложным интегрированным системам сегодняшнего дня. Потребности менеджмента росли параллельно с развитием технологии. Первые системы обработки данных выполняли лишь канцелярскую работу, сокращая количество бумаг. Современные системы перешли к накоп­лению и управлению информацией, рассматриваемой сегодня как жизненно важный ресурс компании. Сегодня наиболее важная функция систем управ­ления базами данных — служить основой информационных систем корпора­тивного управления. Технологические изменения всегда были вызваны потребностями биз­неса. Менеджеры примут новую компьютерную систему только в том случае, если ясно увидят, что выгода превышает затраты на нее. И, несмотря на риск и возможные ловушки, во многих случаях действительно получается существенная выгода. Более того, конца процессу пока не видно. Новые технологии, такие как объектно-ориентированные базы данных и платформа клиент/сервер, решают новые задачи, что должно привести к появлению в будущем более мощных систем. Реляционные системы управления базами данных Использование физических указателей было одновременно и сильной, и слабой стороной иерархических и сетевых систем управления базами дан­ных. Сильной, поскольку они позволяли извлекать данные, связанные опре­деленными отношениями. Слабой, поскольку эти отношения должны быть определены до запуска системы. Извлечь данные на основе других отноше­ний было сложно, если вообще возможно. В 1970 году Е.Ф. Кодд опубликовал революционную по содержанию статью (Codd, 1970), которая всерьез поколебала устоявшиеся представления о базах данных. Он выдвинул идею, что данные нужно связывать в соответствии с их внутренними логическими возможностями, а не физическими указателями. Таким образом, пользователи смогут копировать данные из разных источников, если логическая информация, необходимая для такого комбинирования, присутствует в исходных данных. Это открыло новые возможности для информационно-управляющих систем, поскольку запросы к базам данных теперь не были ограничены физическими указателями.   Рис. 1.11. Логическая связь, не поддерживаемая физическим указателем   Для того чтобы понять, какие недостатки присущи системам, основан­ным на физических указателях, рассмотрим рис. 1.11. На нем показано, что файлы CUSTOMER, INVOICE и INVOICE LINE связаны физическими указа­телями. Файлы MANUFACTURER (ИЗГОТОВИТЕЛЬ) и PRODUCT тоже свя­заны. Пунктирная линия между INVOICE LINE и PRODUCT обозначает, что между ними существует логическая связь, поскольку каждая строка счета относится к конкретному товару. Однако предположим, что файл PRODUCT не привязан к файлу INVOICE LINE физическим указателем. Как тогда, со­ставить следующий отчет? Для каждого клиента перечислить изготовителей приобретенных им товаров. Для составления такого отчета требуется двигаться от файла CUSTOMER через INVOICE и INVOICE LINE к PRODUCT и затем к MANUFACTURER. Но поскольку между файлами INVOICE LINE и PRODUCT нет физической связи, то обычными средствами базы данных такой путь проделать невоз­можно. Для того чтобы все-таки получить такую информацию, придется пользоваться древними и неуклюжими способами работы с файлами. Это потребует искусного длительного программирования. Те же информацион­ные системы, использующие базы данных, которые поддерживают извлече­ние данных на основе логических связей, легко ответят на такой вопрос. В своей статье Кодд предложил простую модель данных, согласно кото­рой все данные сведены в таблицы, состоящие из строк и столбцов. Эти таб­лицы получили название реляций, а модель стала называться соответственно реляционной. Кодд также предложил пользоваться для работы с данными в таблице двумя языкам: реляционной алгеброй и реляционным исчислением (о них мы поговорим и в главе 6). Оба эти языка обеспечивают работу с дан­ными на основе логических характеристик, а не физических указателей, ко­торыми пользовались в иерархических и сетевых моделях. Рассматривая данные с концептуальной, а не физической точки зрения, Кодд предложил еще одну революционную идею. В реляционных системах баз данных целые файлы данных могут обрабатываться одной командой, то­гда как в традиционных системах за один раз обрабатывается только одна запись. Подход Кодда чрезвычайно повысил эффективность программирования в базах данных. Логический подход к данным сделал также возможным создание языков запросов, более доступных для пользователей, не являющихся специалистами по компьютерам. Хотя создать язык, которым могли бы пользоваться все, независимо от опыта работы с компьютером, довольно сложно, однако реляционные языки запросов сделали базы данных доступными для более широкого круга пользователей, чем раньше. Публикация работ Кодда в начале семидесятых вызвала взрыв активно­сти как среди ученых, так и среди разработчиков коммерческих систем по созданию реляционной системы управления базами данных. Результатом этой деятельности явилось создание во второй половине семидесятых реля­ционных систем, которые поддерживали такие языки, как Structured Query Language (SQL, язык структурированных запросов), Query Language (Quel, язык запросов) и Query-by-Example (QBE, запросы по образцу). С широким распространением персональных компьютеров в восьмидесятые годы также появились реляционные базы данных для микрокомпьютеров. В 1986 году SQL был принят в качестве стандарта ANSI языков реляционных баз дан­ных. Этот стандарт обновлялся в 1989 и в 1992 годах. Все эти новшества сильно расширили возможности систем управления базами данных и повысили доступность информации в корпоративных базах данных. Реляционный подход оказался весьма плодотворным. Более того, продолжающиеся исследования обещают значительный прогресс с точки зрения понимания интересов пользователей систем управления базами данных. Сегодня реляционные базы данных рассматриваются как стандарт для современных коммерческих систем работы с данными. Разумеется, файловые системы, иерархические и сетевые базы данных все еще многочисленны и во многих случаях именно их применение является наиболее выгодным. Тем не менее, среди компаний прослеживается очевидная тенденция при первой  же возможности переходить на реляционные системы. Неверным, однако, было бы полагать, что современные реляционные  системы управления базами данных являются последним словом в развитии СУБД. Реляционные базы данных продолжают совершенствоваться, и их внутренняя природа значительно меняется, предоставляя пользователям возможность решать все более сложные задачи. По нашему мнению, наибо­лее существенные из таких перемен происходят в области объектно-ориенти­рованных баз данных. Еще одно чрезвычайно важное новшество - переход организаций к работе с базами данных на технологию клиент/сервер. Этот принцип мы рассмотрим в следующем разделе. На   рис. 1.12   представлена   временная   шкала,   описывающая историческое развитие способов доступа к данным, о котором мы говорили.В таблице 1.1 приведены сравнительные характеристики различных способов доступа к данным.         Таблица 1.1. Сравнительная характеристика способов обращения к данным Расчет оплаты работы агента Информационная система - автоматическая система, организующая данные и выдающая информацию. Информационно-управляющая система - система, обеспечивающая информационную поддержку менеджмента. Данные - разрозненные факты. Информация - организованные и обработанные данные. В этом контексте мы различаем данные и информацию. Под данными обычно подразумеваются разрозненные факты. Например, такой факт: Компания братьев Уотэйб находится в Японии. Этот факт содержится в одной записи файла CUSTOMER. Файлы сис­темы содержат тысячи таких фактов. Таким образом, файлы содержат дан­ные. Информация же - это обработанные данные. Мы подразумеваем здесь, что информация - это организованные данные или выводы из них. Например, кому-то может понадобиться узнать полный текущий баланс компании братьев Уотэйб, или же кого-то заинтересует средний текущий баланс наших клиентов в Европе. Ответы на эти и подобные вопросы мы на­зовем информацией. Конечно, каждый факт или группу данных мы могли бы назвать ин­формацией. Но мы в первую очередь заинтересованы в такой информации, которая может быть полезна менеджерам или руководству компании, осо­бенно в вопросе принятия решений. Обычно такая информация получается в результате обработки большого количества фактов. Таким образом, инфор­мация отличается от данных. В последние годы серьезность влияния, оказываемого информацией на планирование и принятие решений организациями, привела к росту пони­мания того, что информация - это ресурс, обладающий определенной цен­ностью, и, следовательно, нуждающийся в упорядочении и управлении. Од­нако бизнесмены привыкли иметь дело с более осязаемыми активами, та­кими как деньги, средства производства и рабочая сила, ценность которых можно достаточно точно измерить, и выяснение ценности информации для них представляло определенную трудность. Тем не менее, ясно, что если ме­неджеры хорошо информированы, то они с большей вероятностью будут принимать здравые, своевременные решения, которые положительно ска­жутся на состоянии дел предприятия. Наоборот, если менеджеры информи­ рованы недостаточно, они будут больше колебаться в принятии решений, и вероятность удачного выбора значительно снизится. Появившиеся информа­ционные системы, использующие базы данных, стали основополагающим средством снабжения менеджеров точной и своевременной информацией. База данных - это множество взаимосвязанных элементарных групп данных, которые могут обрабатываться одной или несколькими приклад­ными системами. Система базы данных состоит из базы данных; программ­ного обеспечения общего назначения, называемого системой управления базой данных (СУБД), служащего для управления базой данных; соответст­вующего оборудования и людей. СУБД обычно приобретается у фирмы, тор­гующей программным обеспечением, и служит средством, с помощью кото­рого прикладные программы или пользователи работают с данными базы. Составные части информационных систем, использующих базы данных, мы более подробно обсудим в конце главы. База данных - множество взаимосвязанных единиц данных, которые могут обрабатываться одной или несколькими прикладными системами. Система базы данных - база данных, система управления базой данных, соответствующее оборудование и люди. Система управления базой данных (СУБД) - программное обеспечение, осуществляющее, управление базой данных. Создание счета клиенту   Программа такого типа, выполняющая конкретную практическую за­дачу в бизнесе, — это прикладная программа или пример приложения. На­бор таких программ, совместно выполняющих связанные задачи, называется прикладной системой. Секретность данных БД,  позволяющая  получать  агрегированную  информацию  о  больших  подмножествах  некоторого  множества  объектов,  называется  статистической.  Примерами  могу  служить  БД  переписи  населения,  налоговых  деклараций  либо  пациентов  госпиталя.  Кроме  обычных  проблем  предотвращения  несанкционированного  доступа  к  БД  или  ее  модификации,  в  статистической  БД  существуют  проблемы,  связанные  с  тем,  что  допускаются  запросы  в виде: «Напечатать  средний  доход  всех  жителей  Томска»,  но  в  тоже  время  запрещается  доступ  к  данным  о  доходах,  конкретного  человека,  например  Иванова. Не  так  просто  запретить  запросы,  которые  требуют  информации,  относящейся  к    единственной  записи.  Например,  Петров  может  запросить  средний  доход  для  множества  {Петров,  Иванов},  из  которого,  зная  свой  собственный  доход,  он  может  вычислить  доход  Иванова.  Не  решает  проблему  также  и  требование,  чтобы  информация  запрашивалась  относительно  множества,  состоящего  из  m  человек.  Действительно,  в  этом  случае  Петров  мог  бы  взять  множество  S  из   m-1  или  более  человек,  доходы  которых  ему  не  нужно  узнавать,  и  запросить  средний  доход  этих  людей  вместе  с  Ивановым.  Затем  он  получил  бы  средний  доход  для  множества,  включающего  его  самого  и  людей  из  множества  S.  Зная  свой  собственный  доход,  он  смого бы  теперь  легко  определить  доход  Иванова  на  основе  двух  ответов  системы.  Поэтому  необходимо  ввести  огранечения на запросы,  сильно  пересекающиеся  друг  с  другом  и  таким  образом  можно  если  не  предотвратить  раскрытие  индивидуальных  данных,  но  сделать  это  достаточно  трудным делом. Будем  считать для  простоты,  что  статистическая  БД  содержит  единственный  файл  записей.  Каждая  запись  состоит  из  нескольких  полей.  Пусть  v = (v ,v ,…v ) – вектор  значений  некоторого  неключевого  поля  этих  записей.  Тогда  линейным  запросом  называется  линейная  сумма  ,  где  -   произвольные  действительные  числа.  Важным  случаем  линейных  запросов  является  сумма по  множеству  S,  где а  также  средние,  где где p -  число  записей  в  S. Способность  компрометировать  БД (т.е.  вычислять  значения  отдельного  )  будет  зависеть  от  допустимого  числа ненулевых  ,  а  не  от  их  точных  значений. Существует  теорема:  Пусть  допускаются  линейные  запросы,  продуцирующие  по  меньшей  мере  m  элементов  (т.е.  обрабатывают  m  записей), и  никакие  два  запроса  не  могут  иметь  более  k  общих  элементов  (т.е.  k  общих  записей).  Предположим,  что  p  элементов  уже  известны  (т.е.  для  p  записей  конкретные  значения  поля  известны), тогда  для  вычитания  некоторого  еще  неизвестного  элемента (значения  поля  в  интересующей  нас  записи)  необходимо  сделать  не  менее  1+ (m-1-p) /k  запросов.   Ограничения  на  структуру  запроса. Пусть  ключ  записи  состоит  из  x  полей  и  предполагается,  что  в  запросе  можно  задать  не  более  y  полей  ключа (т.е.  выполняется  поиск  по  частичному  соответствию  ключа).  Тогда,  если  y < k,  никакая  функция,  использующая  только  операции  сложения,  вычитания,  умножения  и  деления,  не  позволит  определить  значение  данного  конкретной  записи.  Шифровка Различные  меры  идентификации  пользователей  и  проверки  полномочий,  стандартные  способы  защиты  БД  могут  оказаться  недостаточными  для  сильно  уязвимых  данных.  В  таких  случаях  может  оказаться  желательным  зашифровать  данные.  Зашифрованные  данные  агрессор  не  может  прочесть, если  он  хотя  бы  частично  не  знает  способа  шифровки.  Разработке  методов  шифровки  посвящено  немало  исследований.  Некоторые  из  методов  настолько  просты,  что  легко  поддаются  дешифрации.  Другие чрезвычайно  сложно  расшифровать,  что  обеспечивает  высокую  степень  защиты  данных. Шифровка – преобразование читаемого текста в нечитаемый текст при помощи некоторого алгоритма; применяется для защиты уязвимых данных. Сначала рассмотрим простую схему шифровки, затем – более сложный и более надежный метод.      Метод простой подстановки Предположим, необходимо зашифровать сообщение (простой текст).             Идет снег.             Простой текст - текст, который можно прочесть.                         Текст-шифр - текст, который прочесть невозможно. Метод простой подстановки состоит в замене каждой буквы алфавита на следующую за ней в алфавите. Считается, что пробел идет после буквы «я» и перед буквой «а». Тогда «идет снег»  превращается в текст – шифр: йежуатожд Соединение Соединение  выполняется   для  связывания  данных  между  двумя  таблицами.  Исходные  таблицы  R1,  R2  имеют  разные  структуры,  в  которых  есть  одинаковые  атрибуты  - внешние  ключи.  Операция  соединения  формирует  новую  таблицу,  структура  которой  представляет  собой  совокупность  всех  атрибутов  исходных  таблиц.  У  операции  соединения  есть  несколько  версий:  естественное  соединение,  тета-соединение  и   эквисоединение. Естественное  соединение.   Операция  соединения - операция,  связывающая  таблицы,  когда  общие  столбцы  имеют  равные  значения. Общее  определение  естественного  соединения  таково:  предположим,  что  мы  хотим  взять  естественное  соединение  двух  таблиц  А  и  В,  которые  имеют  общие  строки  С1,…,С .  Тогда  операция  выполняется  за  следующих  три  шага: 1.    Берется  произведение  таблиц  А  и  В.  В  результате  получается  таблица,  содержащая  по  два  столбца  на  каждый  С1,…,С . 2.    Из  таблицы  произведения  исключаются  все  строки,  кроме  тех,  в  которых  значения  столбцов  С1,…,С   из  таблицы  А  равны  значениям  этих  столбцов  в  В. 3.    Проектированием  исключается  одна  копия  столбцов  С1,…,С . Если  таблица  А  имеет  k  столбцов,  а  таблица  В  имеет  m  столбцов,  то  естественное    соединение  таблиц  А  и  В  будет  состоять  из  (k+m-n)  столбцов,  где  n -  число  общих  столбцов  таблиц  А  и  В. Пример. Рассмотрим  таблицу  А  «Продажа»  (табл.4.13)  и  таблицу  В  «Клиент»  (табл.4.14).  Предположим,  мы  хотим  знать  список  клиентов,  закупивших  товар  2518.  Результатом  этого  запроса  будет  таблица  С  «Отношение АJB» (табл.4.15).                  Таблица  4.13.   А «Продажа» День № клента №  торгового агента № товара Количество 28.02 100 10 2241 200 19.02 101 23 2518 300 12.02 105 10 2241 160 22.02 100 39 2518 30 14.02 101 23 2234 60 15.02 110 37 2518 250 <                            Таблица 4.14.  В «Клиент» №  клиента Имя клиента Город 100 Смирнов Москва 101 Петров Самара 105 Кошкин Томск 110 Воробьев Кемерово  Таблица 4.15.С «Отношение  АJB»   Имя  клиента Смирнов Петров Воробьев Тета-соединение  -  это  соединение  с  определенным  условием,  в  котором  участвуют  столбцы  из  каждой  таблицы.  Это  условие  означает  что  два  столбца  будут  определенным  образом  сравниваться.  Оператор  сравнения  может  быть  любым из  шести  следующих:  =,  ¹,  <,  >,  <=,  >=. Пример.  Рассмотрим  таблицу  «Торговый  агент»  (табл.4.16).  Предположим,  что  мы  должны  идентифицировать  агентов,  чьи  менеджеры получают  комиссионные  более  11%.  Результатом  этого  запроса  будет  таблица  «Менеджер»  (табл.4.17).                          Таблица   4.16.   «Торговый  агент» №  агента Фамилия №  менеджера Офис Комис. % 10 Петров 27 Москва 10 14 Сидоров 44 Киев 11 23 Смирнов 35 Токио 9 37 Иванов 12 Томск 13 27 Васильева Москва 15 39 Пряников 44 Киев 10 35 Манжурин 27 Токио 11 12 Сорокин 27 Томск 10 44 Кошкин 27 Киев 12    Таблица 4.17 «Менеджер»      № менеджера Петров Сидоров Пряников Кошкин Манжурин Сорокин Данный  пример  иллюстрирует  тета-соединение  в  случае,  когда  оператор  сравнения  «=«.  Такое  соединение  также  называется  эквисоединением.  В  некоторых  задачах  требуются  другие  операторы.  Способ доступа к данным Характеристика Файлы последовательного доступа Записи должны обрабатываться в последовательном порядке Файлы произвольного доступа Поддерживают прямой доступ к конкретной записи. Сложно обращаться к нескольким записям, связанным с одной Иерархическая база данных Поддерживает доступ к нескольким записям, связанным с одной. Отношения между данными ограничиваются иерархическими. Зависит от предопределенных физических указателей Сетевая база данных Поддерживает иерархические и неиерархические отноше­ния между данными. Зависит от предопределенных физических указателей Реляционная база данных Поддерживает все логические отношения между данными. Логический доступ к данным, не зависящий от физической реализации Появление в 1981 году IBM PC сделало настольный компьютер обычным явлением в офисе. Программы обработки текстов, работы с таблицами и многие другие сами по себе оправдывали использование таких машин. Кроме того, было вполне естественно связывать компьютеры в сеть, чтобы пользователи могли общаться по электронной почте и работать с общими ресурсами, такими как принтеры и диски. Вначале серверы были созданы для управления печатью и доступом к файлам. Это были серверы печати и файловые серверы. Например, в ответ на запрос клиента на доступ к кон­кретному файлу, файловый сервер пересылал этот файл через сеть на кли­ентский компьютер (рис. 1.13). Сегодня же большинство серверов состав­ляют серверы баз данных — программы, которые запускаются на серверной машине и обслуживают доступ клиентов к базе данных (рис. 1.14). Напри­мер, клиент запускает прикладную программу, и ему требуется запросить базу данных. Для этого он обращается к серверу за нужными ему данными, сервер выполняет запрос и возвращает результат клиенту. Прикладная про­грамма может также посылать данные на сервер с требованием обновить базу данных. Сервер вносит необходимые изменения. Рис. 1.12. Развитие систем управления базами данных   Система клиент/сервер - локальная сеть, состоящая из клиентских компьюте­ров, которые обслуживает компьютер-сервер. Сервер базы данных, - программа, которая запускается на машине-сервере и обслуживает доступ клиентов к базе данных. В основе продуктивности системы клиент/сервер лежит принцип разделения труда. Клиент - это та машина, с которой работает пользователь. Она управляется графическим пользовательским интерфейсом и производит вычисления и другую работу, необходимую непосредственно конечному пользователю. Сервер находится «за сценой» и выполняет работу, общую для нескольких клиентов - доступ к базе данных, обновление базы данных и т.д. Графический пользовательский интерфейс. Графические средства доступа ко­нечного пользователя к компьютерной системе. В концептуальном плане принцип клиент/сервер - это часть понятия открытой системы, объединяющего все те способы, которыми можно связать и заставить согласованно работать на благо пользователя компьютеры, операционные системы, сетевые протоколы и другое оборудование, и про­граммное обеспечение. Однако на практике заставить вместе работать разно­образные операционные системы, сетевые протоколы, базы данных и т.д. не слишком просто. Цель открытых систем - добиться возможности взаимо­действия (совместимости), когда две или более различных системы обмени­ваются информацией и каждая из них вносит свой вклад в решение общей задачи. Открытые системы - понятие, означающее согласованную работу объединенного вместе различного оборудования и программного обеспечения. Взаимодействие - режим, в котором две или более различных системы обмениваются информацией, внося свой вклад в решение общей задачи. Рис. 1.13. Извлечение целого файла с файлового сервера В некотором смысле технология клиент/сервер - наиболее яркое во­площение сочетания распределенной обработки данных с централизованным управлением и доступом к данным. Провидцы предсказывали неизбежное появление распределенных вычислений уже более двух десятилетий назад, однако в реальности они появились лишь недавно.Хотя многие сложные проблемы взаимодействия пока не решены, перспективы увеличения эффек­тивности обработки данных и доступа к базам данных еще никогда не были столь радужными.   Рис. 1.14. Клиенты, взаимодействующие с сервером базы данных   Ссылочная целостность Рассмотрим наиболее часто встречающуюся в базах данных связь один-ко-многим. Соответствующие таблицы показаны на рис. 2.8. Как можно заметить, дочерняя и родительская таблицы связаны между собой по общему полю «Товар». Назовем это поле полем связи. Таблица «Товары»                            Таблица «Отпуск товаров»   Рис. 2.8. Связанные таблицы базы данных Возможны два вида изменений, которые приведут к утере связей между записями в родительской и дочерней таблицах: · изменение значения поля связи в записи родительской таблицы без изменения значений полей связи в соответствующих записях дочерней таблицы; · изменение значения поля связи в одной из записей дочерней таблицы без соответ­ствующего изменения значения полей связи в родительской и дочерней таблицах. Рассмотрим первый случай. На рис. 2.9 показано изменение значения поля «Товар» с «Сахар» на «Рафинад» в таблице «Товары». В таблице «Отпуск товаров» значение поля связи «Сахар» осталось прежним. В результате: · в дочерней таблице «Отпуск товаров» для товара «Рафинад» (таблица «Товары») нет сведений о его отпуске со склада; · некоторые записи таблицы «Отпуск товаров» содержат сведения об отпуске то­вара «Сахар», о котором нет информации в таблице «Товары». Таблица «Товары»                        Таблица «Отпуск товаров» Рис. 2.9. Нарушение целостности базы данных; записи с товаром «Сахар» (таблица «Отпуск товаров») не имеют родительской записи Рассмотрим второй случай. Пусть в одной из записей таблицы «Отпуск товаров» значение поля связи «Сахар» изменилось на «Рафинад» (рис. 2.10). В результате: · в дочерней таблице «Отпуск товаров» недостоверны сведения об отпуске со склада товара «Сахар» (таблица «Товары»); · одна из записей таблицы « Отпуск товаров» содержит данные об отпуске товара «Рафинад», сведения о котором отсутствуют в таблице «Товары». Таблица «Товары»                            Таблица «Отпуск товаров»   Рис. 2.10. Нарушение целостности базы данных: запись с товаром «Рафинад» (таблица «Отпуск това­ров») не имеет родительской записи И в первом, и во втором случае мы наблюдаем нарушение целостности базы данных, это означает, что хранящаяся в ней информация становится недостоверной. СУБД обычно блокирует действия, которые нарушают целостность связей между таблицами, т.е. нарушают ссылочную целостность. Когда говорят о ссылочной цело­стности, имеют в виду совокупность связей между отдельными таблицами во всей БД. Нарушение хотя бы одной такой связи делает информацию в БД недостоверной. Чтобы предотвратить потерю ссылочной целостности, используется механизм кас­кадных изменений. Он состоит в обеспечении следующих действий: · при изменении поля связи в записи родительской таблицы следует синхронно изменить значения полей связи в соответствующих записях дочерней таблицы; · при удалении записи в родительской таблице следует удалить соответствующие записи в дочерней таблице. Изменения или удаления в записях дочерней таблицы при одновременном измене­нии (удалении) записи родительской таблицы называются каскадными изменениями и каскадными удалениями. Существует другая разновидность каскадного удаления: при удалении родительской записи в записях дочерних  таблиц значения полей связи обнуляются. Эта разновидность применяется редко, т.к. дочерние таблицы в этом случае будут содержать избыточные данные, например, сведения о товаре, которого нет на складе. Обычно для реализации ссылочной целостности в дочерней таблице создают внешний ключ, в который входят поля связи с дочерней таблицы. Этот ключ для дочерней таблицы является первичным и поэтому по составу полей должен совпадать с первичным ключом родительской таблицы или реже – с частью первичного ключа. СТРОКА-ЭЛЕМЕНТ

менеджера

здания