Лекция 1. Основные термины и определения

Цель. Изучение основных терминов и определений в области баз данных (БД) и систем управления базами данных (СУБД)

Ключевые слова: данные (data), база данных (БД, database), система управления базами данных(СУБД, DBMS),программное обеспечение (software), аппаратное обеспечение (hardware), пользователь, администратор, клиент – сервер, процедура.

Литература.[1, 31–64; 4, 43–57; 5, 14–15]

Базы данных стали неотъемлемой частью нашей повседневной жизни. Поэто­му обсуждение баз данных в этом разделе мы начнем с изучения некоторых приложений систем баз данных. В дальнейших рассуждениях будем рассматри­вать базу данных как некий набор связанных данных, а систему управления ба­зами данных, или СУБД (Database Management System — DBMS), — как про­граммное обеспечение, которое управляет доступом к этой базе данных. Примеры использования баз данных: покупка в супермаркете, заказ книг в местной библиотеке, оформление страхового полиса, работа в Internet, обучение в университете.

История развития СУБД. Считается, что развитие СУБД началось еще в 1960-е годы, когда разрабатывался проект запуска корабля Apollo на Луну. В то время не существовало никаких систем, способных обрабатывать или как-либо управлять тем огромным количеством данных, которое было необхо­димо для реализации этого проекта.

В результате специалисты основного подрядчика — компании North American Aviation (NAA) (которая теперь называется Rockwell International) — разработа­ли программное обеспечение под названием GUAM (Generalized Update Access Method). Основная идея GUAM была построена на том, что малые компоненты объединяются вместе как части более крупных компонентов до тех пор, пока не будет собран воедино весь проект. Применяемую при этом структуру, напоми­нающую перевернутое дерево, часто называют иерархической структурой (hierarchical structure). В середине 1960-х годов корпорация IBM присоединилась к фирме NАА для совместной работы над GUAM, в результате чего была создана система IMS (Information Management System). Причина, по которой корпорация IBM ограничила функциональные возможности IMS только управлением иерар­хиями записей, заключалась в том, что необходимо было обеспечить работу с устройствами хранения с последовательным доступом, а именно с магнитными лентами, которые были в то время основным типом носителя. Спустя некоторое время это ограничение удалось преодолеть. Несмотря на то что IMS является са­мой первой из всех коммерческих СУБД, она до сих пор остается основной ие­рархической СУБД, используемой на большинстве крупных мэйнфреймов.

Другим заметным достижением середины 1960-х годов было появление сис­темы IDS (Integrated Data Store) фирмы General Electric. Работу над ней воз­главлял один из пионеров исследований в области систем управления базами данных — Чарльз Бачман (Charles Bachmann). Развитие этой системы привело к созданию нового типа систем упрйяленин базами данных — Сетевых (network) СУБД, — что оказало существенное влияние на информационные системы того поколения. Сетевая СУБД создавалась для представления более сложных взаи­мосвязей между данными, чем те, которые можно было моделировать с помо­щью иерархических структур, а также для формирования стандарта баз данных. Для создания таких стандартов в 1965 году на конференции организации CODASYL (Conference on Data Systems Languages), проходившей при участии представителей правительства США и бизнесменов, была сформирована рабочая группа List Processing Task Force, переименованная в 1967 году в группу Data Base Task Group (DBTG). В компетенцию группы DBTG входило определение спецификаций среды, которая допускала бы разработку баз данных и управле­ние данными. Предварительный вариант отчета этой группы был опубликован в 1969 году, а первый полный вариант — в 1971 году. Предложения группы DBTG содержали три компонента:

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

подсхема — это часть базы данных, как она видится пользователям или приложениям;

язык управления данными — инструмент для определения характеристик и структуры данных, а также для управления ими.

Группа DBTG также предложила стандартизировать три языка:

язык определения данных для схемы (Data Definition Language — DDL), который позволяет ее описать;

язык определения данных для подсхемы (также DDL), которвш позволяет определять в приложениях те части базы данных, доступ к которым будет необходим;

язык манипулирования данными (Data Manipulation Language — DML), предназначенный для управления данными.

Несмотря на то что этот отчет официально не был утвержден Национальным институтом стандартизации США (American National Standards Institute -ANSI), большое количество систем было разработано в полном соответствии с этими предложениями группы DBTG. Теперь они называются CODASYL-системами, или DBTG-системами. CODASYL-системы и системы на основе иерархических подходов представляют собой СУБД первого поколения. Однако этим двум моделям присущи перечисленные ниже недостатки.

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

• Независимость от данных существует лишь в минимальной степени.

• отсутствие общепризнанных теоретических основ,

В 1970 году Е.Ф. Кодд (Е. F. Codd), работавший в исследовательской лабора­тории корпорации IBM, опубликовал очень важную и весьма своевременную ста­тью о реляционной модели данных, позволявшей устранить недостатки прежних моделей. Вслед за этим появилось множество экспериментальных реляционных СУБД, а первые коммерческие продукты появились в 1970-1980-х годах. Осо­бенно следует отметить проект System R, разработанный в исследовательской лаборатории корпорации ШМ, расположенной в городе Сан-Хосе, штат Кали­форния, созданный в конце 1970-х годов. Этот проект был задуман с целью доказать практичность реляционной модели, что достигалось посредством реали­зации предусмотренных ею структур данных и требуемых функциональных воз­можностей. На основе этого проекта были получены важнейшие результаты.

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

• в 1980-х годах были созданы различные коммерческие реляционные СУБД — например, DB2 или SQL/DS корпорации IBM или Oracle корпора­ции Oracle Corporation.

В настоящее время существует несколько сотен различных реляционных СУБД для мэйнфреймов и персональных компьютеров, хотя во многих из них определение реляционной модели трактуется слишком широко. В качестве при­меров многопользовательских СУБД могут служить система INGRES II фирмы Computer Associates и система Informix фирмы Informix Software, Inc. Приме­рами реляционных СУБД для персональных компьютеров являются Access и FoxPro фирмы Microsoft, Paradox фирмы Corel Corporation, InterBase и BDE фирмы Borland, а также R:Base фирмы R:Base Technologies. Реляционные СУБД относятся к СУБД второго поколения. Однако реляционная модель обладает также некоторыми недостатками — в ча­стности, ограниченными возможностями моделирования. Для решения этой про­блемы был выполнен большой объем исследовательской работы. В 1976 году Чен (Chen) предложил модель "сущность-связь" (Entity-Relations hip model — ER-модель), которая в настоящее время стала самой распространенной технологией проектирования баз данных. В 1979 году Кодд сделал попытку устранить недостатки собственной основополагающей работы и опубликовал расширенную версию реляционной мо­дели — RM/T (1979), затем еще одну версию — RM/V2 (1990). Попытки создания модели данных, позволяющей более точно описывать реальный мир, неформально называют семантическим моделированием данных (seiiientic data modeling).

В ответ на все возрастающую сложность приложений баз данных появились две новые системы: объектно-ориентированные СУБД, или ООСУБД (Object-Oriented DBMS - OODBMS), и объектно-реляционные СУБД, или ОРСУБД (Object-Relational DBMS — ORDBMS). Однако, в отличие от предыдущих моде­лей, действительная структура этих моделей не совсем ясна. Попытки реализа­ции подобных моделей представляют собой СУБД третьего поколения.

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

• понимание проблем, присущих файловым системам, может предотвратить их повторение в СУБД. Иначе говоря, следует учесть опыт прошлых оши­бок. На самом деле, слово "ошибки" в данном случае звучит несколько уничижительно и не дает никакого представления о той полезной работе, которая выполнялась этими системами в течение многих лет. Тем не менее, оно дает понять, что существуют и другие, более эффективные способы управления данными.

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

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

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

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

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

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

Рисунок 1. - Типичная организация приложений с использованием файловых систем

Ограничения, присущие файловым системам

Такого краткого описания файловых систем вполне достаточно для того, что­бы понять суть присущих им ограничений, которые рассмотрены ниже: разделение и изоляция данных, дублирование данных, зависимость от данных, несовместимость файлов, фиксированные запросы/быстрое увеличение количества приложений

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

• дублирование данных сопровождается неэкономным расходованием ресур­сов, поскольку на ввод избыточных данных требуется затрачивать допол­нительное время и деньги;

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

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

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

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

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

• Определение данных содержится внутри приложений, а не хранится от­дельно и независимо от них.

• Помимо приложений не предусмотрено никаких других инструментов дос­тупа к данным и их обработки.

Для повышения эффективности работы необходимо использовать новый подход, а именно базу данных, (database) и систему управления базами данных, или СУБД (Database Management System — DBMS). В этом разделе представлено формальное определение этих терминов, а также рассмотрены компоненты среды СУБД.

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

Чтобы глубже вникнуть в суть этого понятия, рассмотрим его определение более внимательно. База данных — это единое, большое хранилище данных, ко­торое однократно определяется, а затем используется одновременно многими пользователями — представителями разных подразделений. Вместо разрознен­ных файлов с избыточными данными здесь все данные собраны вместе с мини­мальной долей избыточности. База данных уже не принадлежит какому-либо единственному отделу, а является общим корпоративным ресурсом. Причем база данных хранит не только рабочие данные этой организации, но и их описания. По этой причине базу данных еще называют набором интегрированных записей с самаоописанием. В совокупности описание данных называется системным ка­талогом (system catalog), или словарем данных (data dictionary), а сами элемен­ты описания принято называть метаданными (meta-data), т.е. "данными о данных". Именно наличие самоописания данных в базе данных обеспечивает в ней независимость программ от данных (program-data independence).

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

И, наконец, следует объяснить последний термин из определения базы дан­ных, а именно понятие "логически связанный". При анализе информационных потребностей организации следует выделить сущности, атрибуты и связи. Сущ­ностью (entity) называется отдельный тип объекта (человек, место или вещь, понятие или событие), который нужно представить в базе данных. Атрибутом (attribute) называется свойство, которое описывает некоторую характеристику рассматриваемого объекта; связь (relationship) — это то, что объединяет не­сколько сущностей.

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

СУБД — это программное обеспечение, которое взаимодействует с прикладными программами пользователя и базой данных и обладает перечисленными ниже возможностями:

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

• позволяет вставлять, обновлять, удалять и извлекать информацию из базы данных, что обычно осуществляется с помощью языка манипулирования данными (DML — Data Manipulation Language).

Наличие централизованного хранилища всех данных и их описаний позволяет использовать язык DML как общий инструмент организации запросов, который иногда называют языком запросов (query language). Наличие языка запросов позволяет устранить присущие файловым системам ограничения, при которых пользователям приходится иметь дело только с фиксированным набором запросов или постоянно возрастающим количеством программ, что порождает другие, более сложные проблемы управления программным обеспечением. Наиболее распространенным типом непроцедурного языка является язык структурированных запросов (Structured Query Language — SQL), который в настоящее время определяется специальным стандартом и фактически является обязательным языком для любых реляционных СУБД. (SQL произносится либо по буквам "S-Q-L", либо как мнемоническое имя "See-Quel".)

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

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

• системы поддержки целостности данных, обеспечивающей непротиворечивое состояние хранимых данных;

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

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

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

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

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

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

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

Рисунок 2.- Среда СУБД

Аппаратное обеспечение. Для работы СУБД и приложений необходимо некоторое аппаратное обеспечение. Оно может варьировать в очень широких пределах — от единственного персонального компьютера или одного мэйнфрейма до сети из многих компьютеров. Используемое аппаратное обеспечение зависит от требований данной организации и типа СУБД.

Программное обеспечение. Этот компонент охватывает программное обеспечение самой СУБД и прикладных программ, вместе с операционной системой, включая и сетевое программное обеспечение, если СУБД используется в сети. Обычно приложения создаются на языках третьего поколения, таких как С, C++, Java, Visual Basic, COBOL, Fortran, Ada или Pascal, или на языках четвертого поколения, таких как SQL, операторы которых внедряются в программы на языках третьего поколения. Впрочем, СУБД может иметь свои собственные инструменты четвертого поколения, предназначенные для быстрой разработки приложений с использованием встроенных непроцедурных языков запросов, генераторов отчетов, форм, графических изображений и даже полномасштабных приложений. Использование инструментов четвертого поколения позволяет существенно повысить производительность системы и способствует созданию более удобных для обслуживания программ.

Данные. Вероятно, самым важным компонентом среды СУБД (с точки зрения конеч­ных пользователей) являются данные. На рис. 2 показано, что данные играют роль моста между компьютером и человеком. База данных содержит как рабочие данные, так и метаданные, т.е. "данные о данных". Структура базы данных называется схемой (schema).

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

Пользователи. Распределение обязанностей в системах с базами данных:

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

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

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

• логическое проектирование базы данных, которое проводится с учетом особенностей выбранной модели данных: реляционной, сетевой, иерархиче­ской или объектно-ориентированной.

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

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

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

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

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

Преимущество:

• контроль за избыточностью данных

• непротиворечивость данных

• больше полезной информации при том же объеме хранимых данных

• совместное использование данных

• поддержка целостности данных

• повышенная безопасность

• применение стандартов

• повышение эффективности с ростом масштабов системы

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

• повышение доступности данных и их готовности к работе

• улучшение показателей производительности

• упрощение сопровождения системы за счет независимости от данных

• улучшенное управление параллельной работой

• развитые службы резервного копирования и восстановления

Недостатки:

• сложность;

• размер;

• дополнительные затраты на аппаратное обеспечение;

• затраты на преобразование;

• проблемы производительности.

Выводы.

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

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

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

Доступ к данных в базе данных осуществляется с помощью языков запросов. Наиболее распространен язык SQL (Structed Query Language). Основной функцией языка является предоставления пользователю возможностей по созданию, модификации и доступа к данных, которые сохраняются в базе данных. SQL – запросы могут выполняться как из командной оболочки, так и встраиваться у программы на других языках программирования через специальный интерфейс. Учитывая широкую распространенность и практическую значимость языка SQL, его изучению следует уделить много времени.

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

Литература

1.Дейт К. Введение в системы баз данных. 7-е изд., М.; СПб.: Вильяме. — 2001. — 1072 с. 2. Ульман Дж., Видом Дж. Введение в системы баз данных. М.: Лори. — 2000. — 374 с. 3. Райордан Р. Основы реляционных баз данных/Пер, с англ. — М.: Издательско-торговый дом “Русская Редакция”, 2001. — 384 с.: ил. 4. Коннолли Т., Бегг К. Базы данных. Проектирование, реализация и сопровождение. Теория и практика. 3-е издание.: Пер. с англ. — М.: Издательский дом “Вильяме”, 2003. — 1440 с. 5. Аткинсон Л. MySQL. Библиотека профессионала.: Пер. с англ. — М.: Издательский дом “Вильяме”, 2002. — 624 с.

Лекция 2. Модели данных

Цель: изучение структуры данных, модели «сущность-связь».

Ключевые слова: модель «сущность-связь», бинарные сущности, структура данных, связи, двусторонние связи.

Литература. [1,; 4, 88-93,169-207; 5, 58-69, 96-106]

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

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

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

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

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

На практике системы баз данных мо­гут быть легко распределены по категориям в соответствии со структурами данных и операторами, которые они предоставляют пользователю. Прежде всего, старые (дореляционные) системы можно разделить на три большие категории, а именно: системы инвертированных списков (inverted list), иерархические (hierarchic) и сетевые (network). Кроме того, необходимо отметить, что термин сетевая (система) в данном случае не имеет ничего общего с коммуникационной сетью, а относится лишь к структуре дан­ных и операторам, которые поддерживаются данной системой. Сетевые системы иногда называют системами CODASYL или система­ми DBTG по имени группы, которая их предложила — Data Base Task Group (DBTG) of the Conference on Data Systems Languages (CODASYL). Пожалуй, наиболее извест­ной из таких систем была IDMS корпорации Computer Associates International, Inc. По­добно иерархическим системам (но в отличие от реляционных), все такие системы, кроме всего прочего, предоставляли в распоряжение пользователя внутренние указа­тели на элементы данных.

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

Первые реляционные продукты начали появляться в конце 1970-х и начале 1980-х годов. В настоящее преобладающее большинство СУБД были реля­ционными и предназначались для работы на практически любой программной и аппа­ратной компьютерной платформе. Среди них ведущими (в алфавитном порядке) явля­лись следующие: DB2 (всевозможные версии) корпорации IBM; Ingres II корпорации Computer Associates International, Inc.; Informix Dynamic Server корпорации Informix Software, Inc.; Microsoft SQL Server корпорации Microsoft; Oracle 8i корпорации Oracle и Sybase Adaptive Server компании Sybase, Inc.

В последнее время стали появляться объектно-ориентированные и объектно-реляционные продукты⁴. Большинство объектно-реляционных СУБД основывается на совместимых снизу вверх расширениях оригинальных реляционных продуктов, как это случилось с DB2 или Informix. Существующие объектно-ориентированные системы представляют собой попытки сделать что-то совершенно отличное, как это имеет место в случае с системой GemStone корпорации GemStone Systems, Inc. и системой Versant ODBMS компании Object Technology.В дополнение к различным уже упоминавшимся выше подходам в течение несколь­ких лет проводились исследования множества альтернативных схем, включая много­мерный (multi-dimensional) подход и логический (logic-based) подход, называемый еще дедуктивным или экспертным.

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

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

- пользователи не должны непосредственно иметь дело с такими подробно­стями физического хранения данных в базе, как индексирование и хеши­рование (приложение А, "Учебный проект Wellmeadows Hospital"). Иначе говоря, взаимодействие пользователя с базой не должно зависеть от осо­бенностей хранения в ней данных.

- администратор базы данных (АБД) должен иметь возможность изменять структуру хранения данных в базе, не оказывая влияния на пользователь­ские представления.

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

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

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

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

Рисунок 1 – Ієрархічна структура даних

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

Сетевые модели также создавались для малоресурсных ЭВМ. Это достаточно сложные структуры, состоящие из “наборов” – поименованных двухуровневых деревьев. “Наборы” соединяются с помощью “записей-связок”, образуя цепочки и т. д. При разработке сетевых моделей было выдумано множество “маленьких хитростей”, позволяющих увеличить производительность СУБД, но существенно усложнивших последние.

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

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

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

Модель „сущность - связь” (entity - relation).

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

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

Набор сущностей (entity set) - множество сущностей одного типа (обладающих одинаковыми свойствами). Примеры: все люди, предприятия, праздники и т.д. Наборы сущностей не обязательно должны быть непересекающимися. Например, сущность, принадлежащая к набору МУЖЧИНЫ, также принадлежит набору ЛЮДИ.

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

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

Связь (relationship) - это ассоциация, установленная между несколькими сущностями.

Роль сущности в связи - функция, которую выполняет сущность в данной связи. Например, в связи РОДИТЕЛЬ-ПОТОМОК сущности ЧЕЛОВЕК могут иметь роли "родитель" и "потомок". Указание ролей в модели "сущность-связь" не является обязательным и служит для уточнения семантики связи.

Набор связей (relationship set) - это отношение между n (причем n не меньше 2) сущностями, каждая из которых относится к некоторому набору сущностей.

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

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

- один к одному (обозначается 1 : 1 ). Это означает, что в такой связи сущности с одной ролью всегда соответствует не более одной сущности с другой ролью;

- один ко многим ( 1 : n ). В данном случае сущности с одной ролью может соответствовать любое число сущностей с другой ролью.

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

Еще одной важной характеристикой связи помимо ее степени является класс принадлежности входящих в нее сущностей или кардинальность связи. Например, в каждом отделе обязательно должен быть руководитель, то каждой сущности "ОТДЕЛ" непременно должна соответствовать сущность "СОТРУДНИК". Однако, не каждый сотрудник является руководителем отдела, следовательно в данной связи не каждая сущность "СОТРУДНИК" имеет ассоциированную с ней сущность "ОТДЕЛ". Таким образом, говорят, что сущность "СОТРУДНИК" имеет обязательный класс принадлежности (этот факт обозначается также указанием интервала числа возможных вхождений сущности в связь, в данном случае это 1,1), а сущность "ОТДЕЛ" имеет необязательный класс принадлежности (0,1). Теперь данную связь мы можем описать как 0,1:1,1.

Пример. Рассмотрим пример некоторой промышленной компании ("KnowWare, Inc."). Обычно подобному предприятию требуется записывать информацию об имеющихся проектах (Projects), используемых в этих проектах деталях (Parts), поставщиках (Suppliers) деталей, складах (Warehouses), на которых хранятся детали, служащих (Employees), работающих над проектами, и т.д. Проекты, детали, поставщики и т.л. представляют собой основные сущности (entity), о которых компании KnowWare, Inc. необходимо хранить информацию. Термин "сущность" обычно используется в теории баз данных для обозначения любого отличимого объекта, который может быть представлен в базе данных.

Кроме собственно основных сущностей (в данном примере это поставщики, детали и т.д.), существуют еще и связи (relationships) между ними, которые объединяют эти основные сущности. На рис. 1.5 связи представлены ромбами с соединительными линиями. Например, между поставщиками и деталями существует связь SP: каждый поставщик поставляет определенные детали, и, наоборот, каждая деталь поставляется определенными поставщиками. (Точнее, каждый поставщик поставляет определенные виды деталей и каждый вид деталей поставляется определенными поставщиками.) Аналогично детали используются в проектах, а для реализации проектов требуются детали (связь PJ); детали хранятся на складах, а склады хранят детали (связь HP) и т.д. Обратите внимание, что эти связи двусторонние, т.е. их можно рассматривать в обоих направлениях. В частности, используя связь SP между поставщиками и деталями, можно ответить на следующие вопросы:

1. Задан поставщик, и требуется определить поставляемые им детали.

2. Задана деталь, и необходимо найти поставщиков, поставляющих такую деталь.

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

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

I. Хотя большинство связей на этой диаграмме связывает два типа сущностей (т.е. они являются бинарными), это вовсе не означает, что все связи должны быть бинарными. В примере есть одна связь (SPJ), связывающая три типа сущностей (Suppliers, Parts и Projects). Это пример тернарной (тройной) связи. Интерпретация данной связи такова: определенные поставщики поставляют определенные детали для определенных проектов. Обратите особое внимание на то. что в общем случае такая тернарная связь не эквивалентна простой комбинации из трех бинарных связей; ""поставщики поставляют детали", "детали используются в проектах" и "проекты снабжаются поставщиками". В частности, приведенное ниже утверждение а говорит нам больше, чем последующие три утверждения.

Рисунок 2. Сущности и связи

а) "Смит поставляет разводные гаечные ключи для Манхэттенского проекта";

б) "Смит поставляет разводные гаечные ключи";

в) "Разводные гаечные ключи используются в Манхэттенском проекте";

г) "Манхэттенский проект снабжается Смитом".

Зная только утверждения б, в и г, мы не сможем доказать справедливость утверждения а. Точнее, зная утверждения б, в и г, мы можем лишь сделать заключение, что Смит поставляет разводные гаечные ключи для какого-то проекта (скажем, проекта J2). что какой-то поставщик (скажем, поставщик Sx) поставляет разводные гаечные ключи для Манхэттенского проекта и что Смит поставляет какую-то деталь (скажем, деталь Ру) для Манхэттенского проекта. Однако мы не можем точно утверждать, что поставщик Sx— это Смит, деталь Py— это разводной гаечный ключ, а проект Jz — это Манхэттенский проект. Такие ложные выводы называются ловушкой соединения (connection trap).

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

3. Вообще говоря, для заданного набора типов сущностей может существовать любое количество связей. В представленной на рис. 2 диаграмме присутствуют две различные связи между сущностями Projects и Employees: первая (EJ) представляет тот факт, что служащие заняты в проектах, а вторая (MJ) — что служащие управляют проектами.

Лекция 3. Реляционная модель

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

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

Литература. [1, 192-227, 243-278, 301-327; 4, 115-130, 137-159, 218-223; 5, 58-69]

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

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

аспект целостности — эти таблицы удовлетворяют определенным условиям целостности (что мы еще обсудим в конце раздела).

аспект обработки — в распоряжении пользователя имеются операторы манипулирования данными (например, выборки информации), которые генерируют новые таблицы на— основании уже имеющихся и среди которых есть по крайней мере операторы выборки (restrict), проекции (project) и объединения (join).

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

Рисунок 2 – Основные понятия реляционной модели

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

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

Ответ прост — “relation” (отношение) — это математическое название определенного вида таблицы (точнее, определенного вида таблиц).

В настоящее время в неформальном контексте термины “отношение” и “таблица” принято считать синонимами. На практике в подобном контексте термин “таблица” используется гораздо чаще, чем термин “отношение”.

Однако, следует четко различать переменные отношений, т. е. их значения — это значения отношений (различные значения отношений в разное время), и сами отношения. Для переменной отношения (relation variable) используют термин переменная-отношение (сокращенный английский вариант— relvar), и только его, во всех случаях, когда речь будет идти не об отношении, а о переменной отношения.

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

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

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

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

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

• в них нет одинаковых кортежей;

• кортежи отношения не имеют упорядоченности в направлении сверху вниз;

• атрибуты в кортежах не упорядочены слева направо;

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

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

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

Отсутствие упорядочения атрибутов (слева направо). Данное свойство следует из того факта, что заголовок отношения также определен как множество (атрибутов).

Каждый кортеж содержит ровно одно значение для каждого атрибута. Последнее свойство непосредственно следует из определения кортежа: кортеж является множеством из n компонентов или упорядоченных пар вида A_i:v_i (i=1, 2… n). Отношение, удовлетворяющее этому свойству, называется нормализованным или представленным в первой нормальной форме (1НФ).

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

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

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

Реляционная база данных — это такая база данных, которая воспринимается ее пользователями как множество переменных, значениями которых являются отношения (т. е. переменных-отношений — relvars) или, менее формально, таблиц.

Реляционная система — это система, которая поддерживает реляционные базы данных и операции над ними, включая, в частности, операцию выборки строк RESTRICT (иначе называемую SELECT), операцию выборки столбцов PROJECT (также называемую проекцией) и операцию соединения таблиц JOIN. Эти и подобные им операции выполняются на уровне множеств.

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

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

Формальная теория, положенная в основу реляционных систем, называется реляционной моделью данных. Реляционная модель изучает материал только на логическом уровне и не затрагивает физический уровень. В модели рассматриваются три принципиальных аспекта данных — их структура, сохранение их целостности и манипулирование данными. Структурный аспект касается собственно отношений, аспект целостности имеет отношение (помимо всего прочего) к первичным и внешним ключам, а аспект манипулирования данными связан с операторами (RESTRICT, PROJECT, JOIN и т. д.). Информационный принцип утверждает, что все информационное содержимое реляционной базы данных должно быть представлено одним и только одним способом, а именно— явным заданием значений, помещенных в позиции столбцов в строках отношений.

Каждое отношение имеет заголовок и тело; заголовок— это набор пар “имя столбца: имя типа”, а тело отношения состоит из набора строк, которые соответствуют заголовку.

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

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

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

Примечание.

Следует отметить, что понятия, приведенные в таблице 1, “эквивалентны” показанным на рисунке только приблизительно (и каждый из терминов имеет точное определение). Так, “отношение” и “таблица” — это не одно и то же, хотя, на практике данные понятия часто отождествляются.

Таблица 1 – Соотношения между формальными и неформальными терминами

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

Література. [4, 115-130, 137-159, 218-223; 5, 58-69; 1, 192-227, 243-278, 301-327]

Лекция 4

Реляционная алгебра и реляционное исчисление

Цель: изучение состава и назначения основных операторов реляционной алгебры и основ реляционного исчисления.

Ключевые слова: реляционная алгебра, операции, объединение отношений, пересечение отношений, разность отношений, произведение отношений, проекция отношений, деление отношений, соединение отношений, ограничение отношений.

Література. [4, 115-130, 137-159, 218-223; 5, 58-69; 1, 192-227, 243-278, 301-327]

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

В состав теоретико-множественных операций входят операции:

• объединения отношений;

• пересечения отношений;

• взятия разности отношений;

• прямого произведения отношений.

Специальные реляционные операции включают:

• ограничение отношения;

• проекцию отношения;

• соединение отношений;

• деление отношений.

Все операции предложенного выше набора обладают очевидной и простой интерпретацией:

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

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

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

• При выполнении прямого произведения двух отношений производится отношение, кортежи которого являются конкатенацией (сцеплением) кортежей первого и второго операндов.

• Результатом ограничения отношения по некоторому условию является отношение, включающее кортежи отношения-операнда, удовлетворяющее этому условию.

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

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

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

• Операция переименования производит отношение, тело которого совпадает с телом операнда, но имена атрибутов изменены.

• Операция присваивания позволяет сохранить результат вычисления реляционного выражения в существующем отношении БД.

Выводы:

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

• Традиционно определяют восемь реляционных операторов, объединенных в две группы.

• Теоретико-множественные операторы: объединение, пересечение, вычитание, декартово произведение.

• Специальные реляционные операторы: выборка, проекция, соединение, деление.

• Для выполнения некоторых реляционных операторов требуется, чтобы отношения были совместимы по типу.

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

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

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

Лекция 5. Реляционные ключи

Цель: изучение реляционных ключей и применение их в базах данных.

Ключевые слова: ключ, внешний ключ, первичный ключ.

Литература.

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

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

Теперь о внешних ключах:

• Если сущность С связывает сущности А и В, то она должна включать внешние ключи, соответствующие первичным ключам сущностей А и В.

• Если сущность В обозначает сущность А, то она должна включать внешний ключ, соответствующий первичному ключу сущности А.

Связь между первичными и внешними ключами сущностей иллюстрируется рис. 3

Рис. 3 Структуры: а - ассоциации; б - обозначения (характеристики)

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

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

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

2. Что должно случиться при попытке УДАЛЕНИЯ целевой сущности, на которую ссылается внешний ключ? Например, при удалении поставщика, который осуществил по крайней мере одну поставку. Существует три возможности:

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

3. Что должно происходить при попытке ОБНОВЛЕНИЯ первичного ключа целевой сущности, на которую ссылается некоторый внешний ключ? Например, может быть предпринята попытка обновить номер такого поставщика, для которого имеется по крайней мере одна соответствующая поставка. Этот случай для определенности снова рассмотрим подробнее. Имеются те же три возможности, как и при удалении:

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

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

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

NULL-значения не допустимы

УДАЛЕНИЕ ИЗ (цель) КАСКАДИРУЕТСЯ

ОБНОВЛЕНИЕ (первичный ключ цели) КАСКАДИРУЕТСЯ

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

Внешние ключи

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

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

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

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

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

Лекция 6

Реляционное исчисление. Исчисление кортежей.

Цель: изучить реляционное исчисление, исчисление кортежей и доменов.

Ключевые слова: кортежи, домены.

Литература.