Министерство образования российской федерации московский государственный институт электроники и математики (Технический университет)
![]()
|
огра- ничений целостности, которые накладываются на типы объектов, типы связей и/или их экземпляры. 1.4. Назначение и основные компоненты системы баз данных Система БД включает два основных компонента: собственно базу данных и систему управления (рис. 1.3). Большинство СОД включают также програм- мы обработки данных, которые обращаются к данным через систему управле- ния. В соответствии с рис. 1.3. система управления базами данных (СУБД) обеспечивает выполнение двух групп функций: предоставление доступа к базе данных пользователям (или прикладному программному обеспечению, ППО) и управление хранением и обработкой данных в БД. Прикладное программное обеспечение Система управления базами данных База данных Рис.1.3. Компоненты системы баз данных БД является информационной моделью внешнего мира, некоторой пред- метной области. В ней, как правило, хранятся данные об объектах, их свойствах и характеристиках. Во внешнем мире объекты взаимосвязаны, поэтому в БД эти связи должны быть отражены. Если связи между данными в БД отсутствуют, то имеет смысл говорить о нескольких независимых БД, имеющих раздельное хранение. В памяти ЭВМ создаётся динамически обновляемая модель предметной области, что обеспечивает соответствие базы данных текущему состоянию ПО (периодически или в режиме реального времени). Одни и те же данные БД мо- – 10 – гут быть использованы для решения многих прикладных задач. Этим база дан- ных принципиально отличается от любой другой совокупности данных внеш- ней памяти ЭВМ. 1.5. Уровни представления данных Концепции многоуровневой архитектуры СУБД служат основой совре- менной технологии БД. Эти идеи впервые были сформулированы в отчёте ра- бочей группы по базам данных Комитета по планированию стандартов Амери- канского национального института стандартов (ANSI/X3/SPARC), опублико- ванному в 1975 г. В нем была предложена обобщенная трехуровневая модель архитектуры СУБД, включающая концептуальный, внешний и внутренний уровни (рис. 1.4). Основная цель введения подобной архитектуры заключается в отделении пользовательского представления базы данных от её физического представления. Внешний уровень Концептуальный уровень Внутренний уровень Рис.1.4. Уровни представления данных Внешний уровень архитектуры БД предназначен для пользователей. Описание представления данных для группы пользователей называется внеш- ней схемой. В системе БД могут одновременно поддерживаться несколько внешних схем для различных групп пользователей или задач. Концептуальный уровень архитектуры ANSI/SPARC является основ- ным и служит для поддержки единого взгляда на базу данных, общего для всех её приложений и независимого от них. Концептуальный уровень представляет собой формализованную информационно-логическую модель ПО, т.е. это пол- ное представление требований к данным ПО, не зависящее от способов их представления и хранения. Описание этого представления называется концеп- туальной схемой. Внутренний уровень архитектуры поддерживает представление БД в среде хранения – хранимую базу данных. На этом архитектурном уровне БД представлена в полностью "материализованном" виде, тогда как на других уровнях идёт работа на уровне отдельных экземпляров или множества экземп- ляров записей. Описание БД на внутреннем уровне называется внутренней схе- мой или схемой хранения. Совокупность схем всех уровней называется схемой базы данных Каждый из этих уровней может считаться управляемым, если он обладает внешним интерфейсом, который поддерживает возможности определения дан- ных. В этом случае становится возможными формирование и системная под- – 11 – держка независимого взгляда на БД для какой-либо группы персонала или пользователей, взаимодействующих с БД через интерфейс данного уровня. В архитектурной модели ANSI/SPARC предполагается наличие в СУБД механизмов, обеспечивающих междууровневое отображение данных «внешний – концептуальный» и «концептуальный – внутренний». Функциональные воз- можности этих механизмов обеспечивают абстракцию данных и определяют степень независимости данных на всех уровнях. В соответствии с двумя междууровневыми отображениями принято вы- делять логическую и физическую независимость данных. Логическая незави- симость означает защищённость внешних схем от изменений, вносимых в кон- цептуальную схему, а физическая независимость означает защищённость кон- цептуальной схемы от изменений, вносимых в схему хранения. 2. ОСНОВНЫЕ МОДЕЛИ ДАННЫХ 2.1. Понятие модели данных Модель данных – это комбинация трех составляющих: 1. Набора типов структур данных. 2. Набора операторов или правил вывода, которые могут быть применены к любым правильным примерам типов данных, перечисленных в (1), чтобы находить, выводить или преобразовывать информацию, содержащуюся в любых частях этих структур в любых комбинациях. 3. Набора общих правил целостности, которые прямо или косвенно определя- ют множество непротиворечивых состояний базы данных и/или множество изменений её состояния. Модель данных позволяет отделить факты от их интерпретации и вместе с тем обеспечить развитые возможности представления соотношения данных. 2.1.1. Типы структур данных Структуризация данных базируется на использовании концепций "агре- гации" и "обобщения". Первый вариант структуризации данных был предложен Ассоциацией по языкам обработки данных (Conference on Data Systems Lan- guages, CODASYL) (рис.2.1). Элемент данных Агрегат данных Запись Набор База данных Рис.2.1. Композиция структур данных по версии CODASYL Элемент данных – наименьшая поименованная единица данных, к кото- рой СУБД может обращаться непосредственно и с помощью которой выполня- ется построение всех остальных структур. Для каждого элемента данных дол- жен быть определён его тип. – 12 – Агрегат данных – поименованная совокупность элементов данных внут- ри записи, которую можно рассматривать как единое целое. Агрегат может быть простым (включающим только элементы данных, рис.2.2,а) и составным (включающим наряду с элементами данных и другие агрегаты, рис.2.2,б). А(<название>) – агрегат данных А(предприятие) А(дата) А(адрес) число месяц год почтовый индекс город улица и дом а) б) название Рис.2.2. Примеры агрегатов: а) простой и б) составной агрегат Запись – поименованная совокупность элементов данных или элементов данных и агрегатов. Запись – это агрегат, не входящий в состав никакого друго- го агрегата; она может иметь сложную иерархическую структуру, поскольку допускается многократное применение агрегации. Различают тип записи (её структуру) и экземпляр записи, т.е. запись с конкретными значениями элемен- тов данных. Одна запись описывает свойства одного объекта ПО (экземпляра). Среди элементов данных (полей) выделяются одно или несколько ключе- вых полей. Значения ключевых полей позволяют классифицировать объект, к которому относится конкретная запись. Ключи с уникальными значениями на- зываются потенциальными. Каждый ключ может представлять собой агрегат данных. Один из ключей является первичным, остальные – вторичными. Пер- вичный ключ идентифицирует экземпляр записи и его значение должно быть уникальным в пределах записей одного типа. Иногда термин "запись" заменяют термином "группа". Набор (или групповое отношение) – поименованная совокупность запи- сей, образующих двухуровневую иерархическую структуру. Каждый тип набо- ра представляет собой отношение (связь) между двумя или несколькими типа- ми записей. Для каждого типа набора один тип записи объявляется владельцем набора, остальные типы записи объявляются членами набора. Каждый экземп- ляр набора должен содержать только один экземпляр записи типа владельца и столько экземпляров записей типа членов набора, сколько их связано с вла- дельцем. Для группового отношения также различают тип и экземпляр. Групповые отношения удобно изображать с помощью диаграммы Бахма- на, которая названа так по имени одного из разработчиков сетевой модели дан- ных. Диаграмма Бахмана – это ориентированный граф, вершины которого соот- ветствуют группам (типам записей), а дуги – групповым отношениям (рис. 2.3). Здесь запись типа ПОЛИКЛИНИКА является владельцем записей типа ЖИТЕЛЬ и они связаны групповым отношением диспансеризация. Запись типа ОРГАНИЗАЦИЯ также является владельцем записей типа ЖИТЕЛЬ и они свя- заны групповым отношением работают. Записи типа РЭУ и типа ЖИТЕЛЬ яв- ляются владельцами записей типа КВАРТИРА с отношениями соответственно – 13 – обслуживают и проживают. Таким образом, запись одного и того же типа может быть членом одного отношения и владельцем другого. ПОЛИКЛИНИКИ ОРГАНИЗАЦИИ диспансеризация работают ЖИТЕЛИ РЭУ (Ремонтно- эксплуатационные управления) проживают обслуживают КВАРТИРЫ Рис. 2.3. Пример диаграммы Бахмана для фрагмента БД "Город" База данных – поименованная совокупность экземпляров групп и груп- повых отношений. 2.1.2. Операции над данными Модель данных определяет множество действий, которые допустимо производить над некоторой реализацией БД для её перевода из одного состоя- ния в другое. Это множество соотносят с языком манипулирования данными (Data Manipulation Language, DML). Любая операция над данными включает в себя селекцию данных (select), то есть выделение из всей совокупности именно тех данных, над которыми должна быть выполнена требуемая операция, и действие над выбранными дан- ными, которое определяет характер операции. Условие селекции – это некото- рый критерий отбора данных, в котором могут быть использованы логическая позиция элемента данных, его значение и связи между данными. По типу производимых действий различают следующие операции: идентификация данных и нахождение их позиции в БД; выборка (чтение) данных из БД; включение (запись) данных в БД; удаление данных из БД; модификация (изменение) данных БД. Обработка данных в БД осуществляется с помощью процедур базы дан- ных – транзакций. Транзакция – это последовательность операций над данны- ми, которая является логически неделимой, то есть рассматривается как единая макрооперация. Транзакция либо выполняется полностью, либо не выполняется совсем. Никакая другая процедура или операция не могут обратиться к данным, которые обрабатываются стартовавшей процедурой, до тех пор, пока последняя не закончит свою работу. 2.1.3. Ограничения целостности Ограничения целостности обеспечивают непротиворечивость данных при переводе системы баз данных из одного состояния в другое и позволяют адек- – 14 – ватно отражать предметную область данными, хранимыми в БД. Ограничения целостности делятся на явные и неявные. Неявные ограничения определяются самой структурой данных. Напри- мер, тот факт, что записи типа СОТРУДНИК являются обязательными членами какого-либо экземпляра набора данных ПОДРАЗДЕЛЕНИЕ, служит, по суще- ству, ограничением целостности, означающим, что каждый сотрудник органи- зации непременно должен быть в штате некоторого подразделения. Явные ограничения задаются в схеме базы данных с помощью средств языка описания данных (DDL, Data Definition Language). В качестве явных ог- раничений чаще всего выступают условия, накладываемые на значения данных. Например, заработная плата не может быть отрицательной, а дата приема со- трудника на работу обязательно будет меньше, чем дата его перевода на дру- гую работу. За выполнением этих ограничений следит СУБД в процессе своего функционирования. Также различают статические и динамические ограничения целостно- сти. Статические ограничения присущи всем состояниям ПО, а динамические определяют возможность перехода ПО из одного состояния в другое. Примера- ми статических ограничений целостности могут служить требования уникаль- ности номера паспорта или ограничения на дату рождения, которая не может быть больше текущей даты. В качестве примера динамического ограничения целостности можно привести ограничение банковской системы, в соответствии с которым нельзя удалить сведения о клиенте, пока у него не закрыт счёт. В настоящее время разработано много различных моделей данных. Ос- новные – это сетевая, иерархическая и реляционная модели. 2.2. Сетевая модель данных (СМД) Сетевая модель позволяет организовывать БД, структура которых пред- ставляется графом общего вида (пример СМД – на рис. 2.3). Организация дан- ных в сетевой модели соответствует структуризации данных по версии CODASYL. Каждая вершина графа хранит экземпляры сущностей (записи) и сведения о групповых отношениях с сущностями других типов. Каждая запись может хранить произвольное количество значений атрибутов (элементов дан- ных и агрегатов), соответствующих экземпляру сущности. Групповые отношения характеризуют следующие признаки: 1. Способ упорядочения подчинённых записей. Поддерживаются три способа упорядочения: Очередь – добавление в конец списка (FIFO – first input, first output). Стек – добавление в начало списка (LIFO – last input, first output). Сортировка по значению ключа. В этом случае задаётся ключевое поле (по- ля), и вновь поступившая запись добавляется в упорядоченный список в со- ответствии со значением этого поля (значением ключа). 2. Режим включения подчинённых записей. Режим включения бывает автоматический и ручной. – 15 – При автоматическом режиме подчинённая запись связана с записью- владельцем обязательной связью, поэтому она включается в групповое отноше- ние и прикрепляется к записи-владельцу в момент внесения в БД. (Из этого следует, что запись-владелец должна быть внесена в БД до внесения первого экземпляра подчинённой записи.) При ручном режиме включения подчинённая запись может находиться в БД и не быть прикрепленной к записи-владельцу. Она вручную включается в груп- повое отношение тогда, когда это отношение возникает (т.е. устанавливается связь). 3. Режим исключения подчинённых записей. Режим исключения определяется классом членства. Различают три класса членства: фиксированный, обязательный и необязательный. Записи с фиксированным членством удаляются вместе с записью-владельцем. Записи с обязательным членством должны быть удалены до удаления записи-владельца: запись-владелец, к которой прикреплена хотя бы одна запись с обязательным членством, не может быть удалена. Записи с необязательным членством при удалении записи-владельца останутся в БД. В СМД применяются следующие операции над данными: запомнить: внесение информации в БД; включить в групповое отношение: установление связей между данными; переключить: переход члена набора к другому владельцу; обновить: модификация данных; извлечь: чтение данных; удалить: физическое или логическое удаление данных; исключить из группового отношения: разрыв связей между данными. Связи между записями в СМД обычно выполнены в виде указателей (т.е. каждая запись хранит ссылки на другие однотипные записи и записи, связанные с ней групповыми отношениями). Подробнее об этом рассказано в разделе 5.5."Организация связей между хранимыми записями". В сетевой модели данных предусмотрены специальные способы навига- ции и манипулирования данными. Аппарат навигации в графовых моделях служит для установления тех объектов данных, к которым будет применяться очередная операция манипулирования данными. Такие объекты называются текущими. В СМД возможны переходы: – от текущего экземпляра записи определённого типа к другим экземплярам записи этого же типа; – из текущей вершины в любую вершину, с которой текущая связана группо- вым отношением. Наиболее распространенной и стандартизованной из реализаций СМД является модель CODASYL. В соответствии с ней описание схемы БД осущест- вляется на языке COBOL, а манипулирование данными – с помощью вклю- чающего языка программирования высокого уровня. – 16 – 2.3. Иерархическая модель данных (ИМД) Иерархическая модель позволяет строить БД с иерархической древовид- ной структурой. Структура ИМД описывается в терминах, аналогичных терми- нам сетевой модели данных. В основе ИМД лежит понятие дерева. Дерево – это связный неориентированный граф, который не содержит циклов. При работе с деревом выделяют какую-то конкретную вершину, опре- деляют её как корень дерева и рассматривают особо – в эту вершину не заходит ни одно ребро. В этом случае дерево становится ориентированным, ориентация определяется от корня. Дерево как ориентированный граф можно определить следующим образом: имеется единственная особая вершина, называемая корнем, в которую не за- ходит ни одно ребро; во все остальные вершины заходит только одно ребро, а исходит произволь- ное количество ребер; граф не содержит циклов. Конечные вершины, то есть вершины, из которых не выходит ни одной дуги, называются листьями дерева. Количество вершин на пути от корня к ли- стьям в разных ветвях дерева может быть различным. В иерархических моделях данных используется ориентация древовидной структуры от корня к листьям. Графическая диаграмма схемы базы данных на- зывается деревом определения. Пример иерархической базы данных приведён на рис.2.4. Каждая некорневая вершина в ИМД связана с родительской записью иерархическим групповым отношением. Каждая вершина дерева соответствует сущности ПО. Эта сущность характеризуется произвольным количеством атри- бутов, связанных с ней отношением 1:1. Атрибуты, связанные с сущностью от- ношением 1:n, образуют отдельную сущность и переносятся на следующий уровень иерархии. Тип вершины определяется типом сущности и набором её атрибутов. Ка- ждая вершина дерева хранит экземпляры сущностей – записи. Следствием внутренних ограничений иерархической модели является то, что каждому эк- земпляру зависимой группы в БД соответствует уникальное множество экземп- ляров родительских записей – по одному экземпляру (записи) каждого типа вершин вышестоящих уровней. В ИМД также предусмотрены специальные способы навигации. Пере- движение по дереву всегда начинается с корневой вершины, от которой можно прейти на конкретный экземпляр записи любой вершины следующего уровня. Эта вершина становится текущей вершиной, а экземпляр – текущим экземпля- ром (записью). От этой записи можно перейти к другой записи данной верши- ны, к экземпляру записи родительской вершины или к экземпляру записи под- чинённой вершины. |