Технология проектирования и администрирования баз данных и систем данных-Конспект

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

•Выводимый элемент данных – элемент, значение которого получается в результате вычислений с участием значений других элементов данных. Для каждого выводимого элемента данных необходимо указать алгоритм (формулу) вычисления его значения и используемые при этом элементы данных. Последние должны быть определены в словаре.

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

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

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

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

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

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

Кроме приведенных выше основных элементов, в базе данных должны

содержаться следующие описания взаимосвязей между ними:

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

1.Использовать точные и недвусмысленные определения. Избегать таких фраз, как «ряд сотрудников», «отдельные изделия». Употреблять конкретные фразы, например «уволенные сотрудники», «бумажные изделия».

2.Применять сокращения только при необходимости, причем по возможности стандартные.

3.Не употреблять специальных терминов, понятных лишь специалистам, например в области обработки данных, бухгалтерского учета, трудовых

отношений и т. п.

4.Указывать единицы измерений (тыс. дол., м, см и т. п.) или периодичность изменения (раз в год, раз в день и т. п.) по возможности для всех числовых значений.

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

4. МОДЕЛИ ДАННЫХ

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

В настоящей главе рассматриваются три модели данных: реляционная, иерархическая и сетевая [2]. В качестве иллюстрации приводятся примеры из упрощенной информационной системы некоторого госпиталя [4].

4.1. Что такое модель данных

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

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

Концептуальную модель (называемую также «моделью предметной области») необходимо отобразить в логическую модель, обеспечиваемую конкретной СУБД, а логическую модель в свою очередь – в физическую. (Последнюю называют еще «внутренней моделью» или «физической структурой»). Логическая модель данных может быть либо реляционной, либо иерархической, либо сетевой. Термин «модель данных» мы приводим здесь в обобщенном смысле. В каждом конкретном случае речь может идти о концептуальной, логической или внутренней (физической) модели.

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

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

4.2. Взаимосвязи в модели данных

Взаимосвязь выражает отображение или связь между двумя множествами

данных. Различают взаимосвязи типа «один к одному», «один ко многим» и «многие ко многим». Ниже приводятся примеры, иллюстрирующие эти взаимосвязи.

В рассматриваемой системе госпиталя определенное число пациентов находится на лечении. Если пациент поступает в госпиталь впервые, осуществляется первичная регистрация его истории болезни. Если же пациент поступает в госпиталь повторно, в его историю болезни вносятся изменения. Вне зависимости от того, сколько раз данный пациент находился на лечении, он имеет уникальный идентификационный номер. Информация о каждом пациенте включает имя, регистрационный номер пациента и его адрес. Таким образом, атрибутами объекта ПАЦИЕНТ являются «номер пациента», «имя пациента» и «адрес пациента».

Следующий представляющий для нас интерес объект – ХИРУРГ. Этот объект имеет атрибуты «номер патента хирурга» и «имя хирурга».

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

Третий рассматриваемый объект – КОЙКА. Его атрибутами являются «номер палаты» и «номер койки».

4.2.1.Взаимосвязь «один к одному» (между двумя типами объектов)

Вопределенный момент времени одному пациенту выделяется одна койка Между объектами ПАЦИЕНТ и КОЙКА устанавливается взаимосвязь «один к одному», обозначаемая одинарными стрелками (рис 4.1).

4.2.2. Взаимосвязь «один ко многим» (между двумя типами объектов)

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

4.2.3. Взаимосвязь «многие ко многим» (между двумя типами объектов)

В нашем примере каждый хирург может оперировать нескольких пациентов. С другой стороны, находясь в госпитале в различное время каждый пациент может быть прооперирован несколькими хирургами. Между объектами ПАЦИЕНТ и ХИРУРГ существует взаимосвязь «многие ко многим». Мы обозначаем такую взаимосвязь двойными стрелками (рис 4.1).

Рис 4.1

1)«один к одному» – в данный момент времени пациент приписан к одной койке;

2)«один ко многим» – в данный момент времени к каждой палате приписано нуль один или несколько пациентов, но любой пациент может быть приписан только к одной палате;

3)«многие ко многим» – хирург может прооперировать нескольких пациентов или пациент, находясь в госпитале в различное время, может

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

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

Наряду с этим существуют взаимосвязи между атрибутами объекта. Здесь также различают взаимосвязи типа «один к одному», «один ко многим» и «многие ко многим».

4.2.4. Взаимосвязь «один к одному» (между двумя атрибутами)

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

а) взаимосвязь «один к одному» между двумя атрибутами; б) взаимосвязь «один ко многим» между двумя атрибутами. Имена

пациентов могут совпадать, но их номера должны быть уникальными; в) взаимосвязь «многие ко многим» между двумя атрибутами.

Рис. 4.2

4.2.5. Взаимосвязь «один ко многим» (между двумя атрибутами)

Имя пациента и его номер существуют совместно. Пациентов с одинаковыми именами может быть много, но все они имеют различные номера. Каждому пациенту присваивается уникальный номер. Это означает, что данному номеру пациента соответствует только одно имя. Взаимосвязь «один ко многим» обозначается одинарной стрелкой в направлении к «одному» и двойной стрелкой в направлении ко «многим» (рис 4.2).

4.2.6. Взаимосвязь «многие ко многим» (между двумя атрибутами)

Несколько пациентов с одинаковыми именами могли быть прооперированы несколькими хирургами. Несколько хирургов с одинаковыми именами могли прооперировать нескольких пациентов. Между атрибутами «имя пациента» и «имя хирурга» существует взаимосвязь «многие ко многим». Мы обозначаем эту взаимосвязь двойными стрелками (рис. 4.2).

4.2.7. Обзор моделей данных

Иерархическая и сетевая модели данных стали применяться в системах управления базами данных в начале 60-х годов. В начале 70-х годов была предложена реляционная модель данных. Эти три модели различаются в основном способами представления взаимосвязей между объектами.

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

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

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

В сетевой модели данных понятия главного и подчиненных объектов несколько расширены. Любой объект может быть и главным, и подчиненным (в сетевой модели главный объект обозначается термином «владелец набора», а подчиненный – термином «член набора»). Один и тот же объект может одновременно выступать и в роли владельца, и в роли члена набора. Это означает, что каждый объект может участвовать в любом числе взаимосвязей.

4.3. Реляционная модель данных

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

Рассмотрим пример базы данных, показанной на табл. 4.1. Данные в реляционной модели представляются в виде таблицы. В терминологии реляционной модели таблица, подобная представленной на табл. 4.1, называется отношением. Чтобы не смешивать отношения с взаимосвязями между объектами, иногда мы будем называть отношение таблицей. Каждый столбец в таблице является атрибутом. Значения в столбце выделяются из домена, т. е. домен суть множество значений, которые может принимать некоторый атрибут. Так, домен для номера пациента составляют все четырехзначные целые положительные числа (0000, 0001,...., 9999), однако в настоящий момент таблица ПАЦИЕНТЫ содержит только значения 1111, 1234, 2345, 4876, 5123 и 6845. Строки таблицы называются кортежами.0

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

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

Таблица 4.2

Первичным ключом является номер патента хирурга

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

Таблица 4.4 представляет объект ПРЕПАРАТ и побочный эффект от его применения.

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

Столбец или ряд столбцов называются возможным ключом (часто сокращенно – ключом) отношения, если его (их) значения однозначно

идентифицируют строки таблицы. Основные термины реляционной модели приведены на табл. 4.5. Вполне вероятно, что отношение имеет более одного ключа. В этом случае удобно рассматривать один из ключей в качестве первичного. В отношении ПАЦИЕНТЫ, например, если задан номер пациента 1234, который является значением ключа, то и имя пациента — Мэри Джонс, и его адрес — 10, Мэйн стрит, Рай, Н.-Й. будут однозначно определены.

Если столбцам присвоены уникальные имена, то порядок их следования не имеет значения. В таблице не может существовать одинаковых строк. Способ упорядочения таблицы также несуществен.

Любому отношению присущи следующие свойства:

1.Отсутствуют одинаковые строки.

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

3.Порядок столбцов не существен (предполагается, что каждый столбец имеет уникальное имя).

4.Все значения имеют атомарный характер, т е. их нельзя разбить на компоненты (без потери информации).

Отношение представляет собой множество элементов — кортежей, а по

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

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