Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Kolokvium / MARTIN2.DOC
Скачиваний:
35
Добавлен:
19.04.2013
Размер:
27.14 Кб
Скачать

Модели данных: схемы и подсхемы

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

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

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

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

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

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

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

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

СХЕМА

Структуру данных необходимо описывать формальным образом. Описания логической и физической структур базы данных используют­ся программными средствами управления базами данных при обработ­ке требований пользователей, на получение той информации, которую содержит база данных. Описание общей логической структуры базы данных называют схемой. Ее называют иногда общей моделью данных, концептуальной моделью или концептуальной схемой. Эти термины примерно равнозначны. Схема представляет собой таблицу типов ис­пользуемых данных. Она содержит имена объектов н их атрибуты и определяет существующую между ними связь. Схема представляет собой структуру, в которой могут быть помещены значения элементов данных. Подобно табло в аэропорту, на котором высвечивается инфор­мация о прибытии и отправлении самолетов, схема не меняется, в то время как величины, помещенные в ней, время от времени изменяются. Рис. 5.3 можно было бы рассматривать как схему, если бы из нее были убраны значения атрибутов объектов.

Если схема содержит значения элементов данных подобно тому, как это показано на рис. 5.3, ее называют экземпляром схемы.

Мы должны различать понятия тип записи и экземпляр записи. Когда мы говорим о «персональной записи», мы имеем в виду тип записи, а не связанные с ней значения данных. Запись (подобно схе­ме) - такая структура, в которую можно помещать конкретные зна­чения данных. «Персональная запись .ДЖОНС БИЛЛ» может быть более корректно названа записью. Совсем не обязательно, чтобы за­пись содержала постоянные значения данных, - эти значения время от времени могут изменяться. В некоторый момент времени «персо­нальная запись ДЖОЙС БИЛЛ» будет иметь значения данных, кото­рые проставлены в верхней строке на рис. 5.3. Такую строку будем на­зывать экземпляром записи.

Подобное отличие между записью и экземпляром записи существует и для элементов данных, и для агрегатов данных, и для всех других категорий данных, перечисленных на рис. 5.1. Для краткости в этой книге (так же как и в других) иногда используют такие термины, как элемент данных ЗАРПЛАТА, в то время как на самом деле это элемент данных типа ЗАРПЛАТА; или запись ПОСТАВЩИК, в то время как это запись типа ПОСТАВЩИК, и т. д.

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

Соседние файлы в папке Kolokvium