Модели данных: схемы и подсхемы
Если бы назначение базы данных было только хранение данных, то структура ее была бы простой. Причина же ее сложности объясняется тем, что она должна обеспечивать еще и связи между различными элементами данных.
Минимальным фрагментом данных является элемент данных (поле, элемент). Элемент данных не может подразделяться на меньшие типы данных, не теряя при этом смысла для пользователя; это атом данных (и состоит он из таких частиц, как биты и байты). В последующих диаграммах для представления элемента данных будем использовать эллипс, внутри которого будем записывать имя типа элемента данных. Например,
Сам по себе элемент данных ничего не представляет. Он приобретает смысл только тогда, когда он связан с другими элементами данных. Эта связь изображается следующим образом:
База данных состоит из элементов данных и связей между ними.. В базе данных много различных типов элементов данных, и поэтому необходима специальная схема, позволяющая изобразить связи между типами элементов данных. Эта схема иногда называется моделью данных. Существуют различные способы изображения такой схемы. На диаграмме, которую мы используем здесь, не показан способ физического хранения данных. На ней показаны только логические связи между элементами данных. Официальная схема Лондонского метрополитена не имеет отношения к физическому расположению путей и станций. На ней не показаны реальные изгибы путей и реальные расстояния между станциями. Подобно схеме базы данных, на ней просто представлены связи между станциями. Ее можно рассматривать как модель реального мира, которая не имеет в общем-то большого сходства с действительностью, но которая может быть полезной ее пользователям в качестве одного из представлений реального мира.
Описанию физического размещения данных должно предшествовать рассмотрение моделей данных, необходимых пользователям. Эти модели являются логическим, представлением данных. Лондонский метрополитен можно представить в виде логического описания транспортной системы. Строители могут изменить физические пути, прокладывая дорогу над Темзой, а не под ней, но при этом логическая схема не изменится.
Прежде чем описывать физическую реализацию связей между данными, мы должны обсудить способ, с помощью которого конечные пользователи базы данных (обращающиеся к ней с помощью терминалов или прикладных программ) представляют эти связи. Существуют различные способы представления логических связей. Одни из них вполне удовлетворительны, другие довольно запутанны и могут ввести в заблуждение, третьи ограниченны в том смысле, что с их помощью нельзя представить все реально существующие связи. Некоторые способы негибки, т. е. не позволяют легко представить расширения и изменения данных в случае возможного развития базы данных. В этой и в последующих главах обсуждается логическое представление данных. Часть 11 книги посвящена физическому представлению данных.
Способность программных средств управления данными отделить физическую структуру данных от представления пользователей или от «логической» организации данных дает пользователям возможность (по крайней мере, теоретически) представлять логическую структуру данных независимо от их физической реализации. Представление пользователей о структуре данных должно быть описано в любой удобной для него и его коллег (настоящих и будущих) форме; средства управления данными должны осуществлять преобразование логической структуры в любую физическую структуру данных, обеспечивающую высокую производительность.
В практике разработки и использования вычислительных машин еще не существует идеальных программных средств управления данными, и поэтому, как мы увидим ниже, выбирают компромиссное решение: раздельное описание логической и физической структур.
СХЕМА
Структуру данных необходимо описывать формальным образом. Описания логической и физической структур базы данных используются программными средствами управления базами данных при обработке требований пользователей, на получение той информации, которую содержит база данных. Описание общей логической структуры базы данных называют схемой. Ее называют иногда общей моделью данных, концептуальной моделью или концептуальной схемой. Эти термины примерно равнозначны. Схема представляет собой таблицу типов используемых данных. Она содержит имена объектов н их атрибуты и определяет существующую между ними связь. Схема представляет собой структуру, в которой могут быть помещены значения элементов данных. Подобно табло в аэропорту, на котором высвечивается информация о прибытии и отправлении самолетов, схема не меняется, в то время как величины, помещенные в ней, время от времени изменяются. Рис. 5.3 можно было бы рассматривать как схему, если бы из нее были убраны значения атрибутов объектов.
Если схема содержит значения элементов данных подобно тому, как это показано на рис. 5.3, ее называют экземпляром схемы.
Мы должны различать понятия тип записи и экземпляр записи. Когда мы говорим о «персональной записи», мы имеем в виду тип записи, а не связанные с ней значения данных. Запись (подобно схеме) - такая структура, в которую можно помещать конкретные значения данных. «Персональная запись .ДЖОНС БИЛЛ» может быть более корректно названа записью. Совсем не обязательно, чтобы запись содержала постоянные значения данных, - эти значения время от времени могут изменяться. В некоторый момент времени «персональная запись ДЖОЙС БИЛЛ» будет иметь значения данных, которые проставлены в верхней строке на рис. 5.3. Такую строку будем называть экземпляром записи.
Подобное отличие между записью и экземпляром записи существует и для элементов данных, и для агрегатов данных, и для всех других категорий данных, перечисленных на рис. 5.1. Для краткости в этой книге (так же как и в других) иногда используют такие термины, как элемент данных ЗАРПЛАТА, в то время как на самом деле это элемент данных типа ЗАРПЛАТА; или запись ПОСТАВЩИК, в то время как это запись типа ПОСТАВЩИК, и т. д.
Изображения схем и записей можно представлять в виде расположенных одного за другим прямоугольников так, чтобы они определяли все значения каждого элемента данных.