Спирин Н.А., Лавров В.В. Информационные системы в металлургии

Подождите немного. Документ загружается.

Глава 3. Основы систем управления базами данных

3-39

жить идентификатором (ключевой атрибут) для обозначения отдельных экземп-

ляров сущности. Связи между сущностями отображают функциональные аспек-

ты информации, представленной сущностями.

Существует несколько подходов к построению диаграмм типа "сущность-

связь". Общим для всех подходов является набор из четырех основных проект-

ных решений или шагов:

1) определение сущностей;

2) определение атрибутов

сущностей;

3) идентификация ключевых атрибутов сущностей;

4) определение связей между сущностями.

Выполнение этих шагов в том или ином порядке для каждого приложения

называют моделированием частных представлений. При этом требования каждо-

го пользователя анализируются и представляются в общей форме. Объекты и со-

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

множеством сущностей,

атрибутов и связей между сущностями.

Для построения концептуальной модели (иногда употребляют термин

"информационно-логическая (инфологическая) модель") требуется произвести

далее интеграцию частных представлений. Концептуальные требования от-

дельных пользователей, определенные в стандартной форме, такой как диаграм-

мы "сущность-связь", сливаются в единое глобальное представление. При этом

должны быть выявлены и ликвидированы

противоречивые и избыточные дан-

ные. Важно помнить, что результат – первоначальная концептуальная модель,

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

лит обеспечить гибкость процесса проектирования.

Этап 3. Проектирование реализации

После построения первоначальной концептуальной модели следует ее

уточнение и совершенствование. Главной целью этапа проектирования реализа-

ции является создание СУБД-

ориентированной схемы (логической модели) с ис-

пользованием в качестве исходных данных результатов концептуального проек-

тирования и требований обработки конкретной СУБД.

Вначале анализируется содержание требований обработки данных. Фор-

мат локальных информационных структур, подлежащих обработке, соответству-

ет формату первоначальной структуры, полученной на этапе концептуального

проектирования. К локальным информационным структурам относят, в частно-

сти, внешние модели, рассмотренные ранее (см. рис. 3.15), а также даталогиче-

ские модели, представленные на языке описания данных конкретной СУБД. По-

сле того как представлены все виды обработки, первоначальная концептуальная

модель может быть объединена со всеми внешними моделями в новую инфор-

мационную структуру – логическую модель данных. Затем, используя знания,

полученные в

процессе пересмотра и объединения внешних моделей, учитывая

связи обрабатываемых данных и характеристики типов записей, допускаемых

СУБД, можно сформировать предварительные типы записей.

Построенная таким образом логическая модель данных может быть оцене-

на количественно с помощью таких характеристик, как число обращений к логи-

ческим записям, объем обрабатываемых в каждом приложении данных, общий

Глава 3. Основы систем управления базами данных

3-40

объем хранимых данных. Эти оценки помогут приблизительно определить эф-

фективность функционирования физической базы данных в терминах затрачи-

ваемого на обработку времени и требуемой физической памяти. С учетом этих

оценок логическая модель может быть усовершенствована с целью достижения

большей эффективности. Основными показателями эффективности функциони-

рования физической БД являются:

•

время ввода-вывода

– время, затрачиваемое на выборку данных с

внешней памяти в оперативную, включая время передачи данных;

время доступа – промежуток времени между выдачей команды, со-

держащей обращение к некоторым данным, и фактическим получени-

ем данных для обработки;

время отклика – промежуток времени между вводом запроса к базе

данных в компьютере и

завершением обработки запроса с представле-

нием результатов.

Этап 4. Физическое проектирование

Практика проектирования физической базы данных прошла несколько

этапов своего развития, начиная от проектирования файлов и кончая проектиро-

ванием физических структур интегрированных баз данных в рамках сущест-

вующих ныне СУБД. Эта практика включает различные известные методы хра-

нения структур, поисковые механизмы

, сегментацию записей. Можно разделить

основные проектные решения в физическом проектировании по меньшей мере

на три категории.

• Проектирование формата хранимых записей. Сюда включаются все

виды представления и сжатия данных в хранимых записях. Сюда же

относится распределение элементов данных записи по различным уча-

сткам физической памяти в зависимости от размеров и

характеристик

их использования.

• Анализ и проектирование кластеров. Кластеризация включает разме-

щение экземпляров записей в смежных участках физической памяти,

распределение по различным устройствам внешней памяти, выбор

размеров блоков с целью эффективной выборки.

• Проектирование путей доступа. Сюда включаются такие параметры,

от которых в значительной степени зависит стоимость доступа при

поиске и обновлении данных (например, логическое упорядочение

записей, выбор указателей, методы доступа).

Отметим, что эти характеристики имеют важное значение и на этапе 3, то

есть вопросы проектирования реализации и физического проектирования пере-

секаются.

3.7.4. Обеспечение свойств БД в процессе проектирования

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

фундаментальных свойств:

1) целостность, согласованность, восстанавливаемость;

2) безопасность;

3) эффективность, рост, размер, эксплуатационные ограничения.

Глава 3. Основы систем управления базами данных

3-41

Это разделение свойств на группы отображает степени свободы проекти-

ровщика баз данных. Первая группа обычно отображает требования пользовате-

лей и состоит из "жестких" ограничений, в рамках которых должен работать

проектировщик. Вторая и третья группы свойств обычно предоставляют проек-

тировщику больше свободы в выборе средств. Обеспечение свойств третьей

группы, как правило,

осуществляется, когда уже найдено возможное решение,

удовлетворяющее требованиям пользователей.

Напомним, что целостность – это правильность и точность данных в базе

данных. База данных обладает свойством целостности, если она удовлетворяет

некоторым определенным ограничениям значений данных и сохраняет это свой-

ство при всех модификациях (замена, добавление или удаление) базы данных. В

качестве примера

рассмотрим ограничение целостности "зарплата служащего не

может быть больше зарплаты его руководителя", определенное для базы данных

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

го служащего с зарплатой его руководителя. Если это ограничение не удовле-

творяется для какого-либо служащего, то запись о данном служащем удаляется

из базы данных.

В дальнейшем это ограничение должно контролироваться вся-

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

ется поле, в котором содержатся сведения о зарплате служащего. Из смысла это-

го ограничения следует, что оно не должно проверяться при операциях удаления

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

проверять либо во время операций обновления, либо удаления, либо в обоих

случаях.

База данных обладает свойством согласованности по отношению к неко-

торой совокупности пользователей, если в любой момент времени база данных

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

ный ими конкретный запрос получают одинаковый ответ

). В качестве примера

рассмотрим файл МАТЕРИАЛОВ, используемый совместно несколькими поль-

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

на материалы, а в то же самое время бухгалтер, используя базу данных, готовит

бухгалтерский отчет. Если прикладная программа кладовщика не имеет возмож-

ности блокировать доступ к базе данных (т. е. исключить

всех других пользова-

телей) на все время выполнения корректировки сведений о ценах на материалы,

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

можность блокирования доступна как кладовщику, так и бухгалтеру и использу-

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

тов. Существует много способов поддержания согласованности базы

данных.

Восстанавливаемость – это запроектированная возможность восстанов-

ления с помощью СУБД целостности базы данных после любого сбоя системы.

Процесс проектирования такой возможности включает разработку систем про-

верки адекватности баз данных, предназначенных для того, чтобы избежать по-

терь данных. В случае сбоя системы основной задачей является восстановление

в течение приемлемого времени

существовавшего до сбоя состояния данных.

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

количественная характеристика. Однако такая характеристика должна включать

четкое определение того, кем или чем будет инициироваться процесс восстанов-

Глава 3. Основы систем управления базами данных

3-42

ления: СУБД, операционной системой или оператором пульта управления. Это,

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

рационная система или технические средства.

Под безопасностью понимается защита данных от преднамеренного или

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

поддержания безопасности базы данных является запрещение несанкциониро-

ванного доступа к

данным при минимальных затратах. Поэтому контроль досту-

па является наиболее важной проблемой реализации. Он может быть осуществ-

лен посредством внешних моделей, которые позволяют отдельным пользовате-

лям иметь дело только с той частью логической модели данных, которая им не-

обходима. Внутри такой модели можно усовершенствовать контроль доступа

(только читать, писать, включить

и т.д.) с помощью механизма блокирования.

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

отдельные записи и элементы данных. Выбор объектов блокирования может

оказать значительное влияние на эффективность. Блокирование легче всего осу-

ществить на уровне базы данных, однако это может лишить пользователей воз-

можности доступа ко многим

нечувствительным и срочно необходимым дан-

ным. Блокирование на уровне элементов данных представляет наибольшую гиб-

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

данных.

Наиболее приемлемым, по-видимому, будет решение, позволяющее без

излишних накладных расходов на обработку добиться обеспечения безопасности

на более низком уровне детализации данных. Поэтому четкое определение огра

ничений безопасности наряду с требованиями производительности (время от-

клика и т. д.) является решающим для достижения приемлемого компромисса

при проектировании схемы базы данных.

При проектировании и реализации мер безопасности необходимо также

принимать во внимание способы реализации и алгоритмы, используемые для

обеспечения целостности и согласованности. Необходимо проектировать систе-

му таким образом

, чтобы поддержка целостности возлагалась на тех пользовате-

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

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

Реализация методов поддержания целостности и согласованности оказы-

вает существенное влияние на эффективность СУБД. Разумный подход при их

реализации может сократить связанные с этим

накладные расходы в любой

СУБД и, следовательно, повысить эффективность. В общем же случае поддер-

жание целостности и согласованности увеличивает время отклика. Разумные ме-

тоды и алгоритмы могут только минимизировать это увеличение. Если можно

спланировать работу системы таким образом, что поддержание целостности и

согласованности осуществляется в то время, когда система не

занята обслужива-

нием пользователей, то рост времени отклика может быть снижен до нуля. По-

этому влияние этих компонентов на эффективность системы зависит исключи-

тельно от методов реализации. Чтобы оценить влияние поддержания целостно-

сти на эффективность, можно определить частоту и удельную стоимость процес-

са поддержания целостности в терминах вычислительных ресурсов (например,

процессорного

времени и времени ввода-вывода) и рассматривать программное

Глава 3. Основы систем управления базами данных

3-43

обеспечение целостности как одно из приложений наряду с приложениями ко-

нечных пользователей. Поддержание согласованности, восстанавливаемости и

безопасности может быть оценено таким же способом.

3.8. Проектирование реляционных баз данных

с использованием принципов нормализации

Как было показано в материале предыдущего параграфа, при проектиро-

вании базы данных решаются две основные проблемы.

•

Каким

образом отобразить объекты предметной области в абстрактные объ-

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

предметной области и было по возможности лучшим (эффективным, удоб-

ным и т.д.)? Часто эту проблему называют проблемой логического проекти-

рования баз данных.

Как обеспечить эффективность выполнения запросов к базе данных, т.

е. ка-

ким образом, имея в виду особенности конкретной СУБД, расположить дан-

ные во внешней памяти, создания каких дополнительных структур (напри-

мер, индексов) потребовать и т.д.? Эту проблему называют проблемой физи-

ческого проектирования баз данных.

В случае реляционных баз данных трудно представить какие-либо общие

рецепты по части физического проектирования

. Здесь слишком много зависит от

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

проектирования реляционных баз данных, которые существенны при использо-

вании любой реляционной СУБД.

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

данных состоит в обоснованном принятии решений о том,

из каких отношений должна состоять БД,

какие атрибуты должны быть у этих отношений.

Основная цель проектирования БД – это сокращение избыточности хра-

нимых данных, а следовательно, экономия объема используемой памяти,

уменьшение затрат на многократные операции обновления избыточных копий и

устранение возможности возникновения противоречий из-за хранения в разных

местах сведений об одном и том же объекте. Так

называемый "чистый" проект

БД ("Каждый факт в одном месте") можно создать, используя методологию нор-

мализации отношений, основанную на концепции нормальных форм.

Говорят, что отношение находится в некоторой нормальной форме, если

оно удовлетворяет заданному набору условий. Метод нормализации предполага-

ет последовательное приведение данного набора отношений к некоторой более

желательной форме. Группировка

атрибутов в отношениях должна быть рацио-

нальной, т.е. минимизирующей дублирование (избыточность) данных и упро-

щающей процедуры их обработки и обновления. Окончательная цель нормали-

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

факт появляется лишь в одном месте, т.е. исключена избыточность информации.

Это делается не столько

с целью экономии памяти, сколько для исключения

возможной противоречивости хранимых данных.

Глава 3. Основы систем управления базами данных

3-44

Исходной точкой является представление предметной области в виде од-

ного или нескольких отношений. На каждом шаге проектирования производится

формирование новых наборов схем отношений, обладающих лучшими свойст-

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

можные наборы отношений. Таким образом, процесс проектирования представ-

ляет собой процесс нормализации схем отношений.

Нормализация схем отношений – это формальный аппарат ограничений

на формирование отношений (таблиц), который позволяет устранить дублирова-

ние, обеспечивает непротиворечивость хранимых в базе данных, уменьшает тру-

дозатраты на сопровождение (ввод, корректировку) базы данных.

Каждой нормальной форме соответствует некоторый определенный набор

ограничений, и отношение находится в некоторой нормальной форме, если

удовлетворяет свойственному ей

набору ограничений.

В теории реляционных баз данных выделяются следующие основные

нормальные формы:

•

первая нормальная форма (1НФ);

вторая нормальная форма (2НФ);

третья нормальная форма (3НФ).

Главные свойства нормальных форм заключаются в следующем:

каждая следующая нормальная форма в некотором смысле лучше пре-

дыдущей;

при переходе к следующей

нормальной форме свойства предыдущих

нормальных свойств сохраняются.

Заметим, что уровень нормализации данного отношения определяется се-

мантикой, а не конкретными значениями данных в некоторый момент времени.

Нельзя с первого взгляда на таблицу с данными для заданного отношения опре-

делить, находится ли оно, например, в 3НФ. Для этого также необходимо пред-

ставить

себе их смысл, то есть существующие между ними зависимости. Следу-

ет также отметить: даже зная о зависимостях данного отношения, нельзя дока-

зать того, что оно находится в 3НФ. В таком случае можно лишь показать, что

эти данные не нарушают никаких зависимостей, и высказать предположение о

том, что эти данные не противоречат

гипотезе о принадлежности отношения к

3НФ. Однако этот факт не гарантирует, что предложенная гипотеза верна.

На практике, как правило, исходное отношение приводят к 3НФ, при этом

достигаются основные свойства реляционной модели данных. Поэтому ограни-

чимся рассмотрением процедуры нормализации до 3НФ.

3.8.1. Первая нормальная форма

Первая нормальная форма (1НФ, First Normal Form, 1NF)

– это основа

реляционной системы. В 1НФ нельзя хранить несколько значений в одном

столбце. В терминах теории баз данных каждое значение в столбце таблицы яв-

ляется элементарным (атомарным), то есть состоящим из одного экземпляра.

Рассмотрим, например, систему обеспечения продажи товаров, в которой

все коды заказанных продуктов могут храниться в записи

одного заказа

(рис.3.17). Такой подход к организации данных не удовлетворяет условию нор-

Глава 3. Основы систем управления базами данных

3-45

мализованной базы данных, поскольку в 1НФ не позволяется ввод множества

значений в одной записи (строке). Требуется создать схему, в которой в каждую

запись заказа вводится только одно значение.

Номер заказа Код товара Стоимость заказа

1 1320, 1405, 1602, 1201, 1000 1174

2 2001, 1001, 2345 61

3 3021, 4000 186

Рис. 3.17. Фрагмент системы обеспечения продажи товаров

Чтобы реализовать систему обеспечения продажи, удовлетворяющую ус-

ловию 1НФ, необходимо иметь заказ, представленный комбинацией от 1 до N

записей, содержащих информацию о коде элементов заказа. Это решение ус-

ложняет выборку информации о содержании товаров в конкретном заказе, т.к. в

этом случае требуется извлекать каждую

ассоциированную с заказом запись и

проверять, что извлекается именно нужная запись. Результат применения перво-

го прохода при нормализации таблицы базы данных приведен на рис. 3.18.

Номер заказа Код товара Наименование товара Оптовая цена

1 1320 Болты 12

1 1405 Молоток 20

1 1602 Гвозди 10

1 1201 Гайки 16

1 1000 Электропила 880

2 2001 Напильник 19

2 1001 Ключ гаечный 14

2 2345 Отвертка 15

3 3021 Стамеска 24

3 4000 Рубанок 124

Рис. 3.18. Фрагмент организации данных, удовлетворяющих условию 1НФ

3.8.2. Вторая нормальная форма

Первым требованием второй нормальной формы (2НФ, Second Normal

Form, 2NF) является выполнение требований первой нормальной формы. В со-

ответствии со вторым требованием каждая строка в таблице базы данных долж-

на быть уникально идентифицирована.

В таблице заказов на рис. 3.18 на

первый взгляд все выглядит так, как

будто структура соответствует этому правилу. Мы установили идентификатор

заказа (номер заказа). Если его скомбинировать с идентификатором товара (код

товара), то получится уникальный указатель на строку – составной ключ. Однако

можно отметить неполную функциональную зависимость атрибута "Наименова-

ние товара" от этого ключа, поскольку семантика отношения для данного

атри-

бута на самом деле включает следующие функциональные зависимости:

Глава 3. Основы систем управления базами данных

3-46

Номер заказа, Код товара

→

Наименование товара;

Код товара

→

Наименование товара.

Это приводит к следующим аномалиям.

Аномалия включения. Нельзя вставить данные в случае, когда в одном за-

казе может оказаться несколько одинаковых идентификаторов товара. Напри-

мер, при покупке болтов можно заказать несколько коробок болтов в одном и

том же заказе.

Аномалия удаления. Если какой-либо товар удалить из

базы данных (снят

с продажи), то при этом будет потеряна не только информация о тех заказах, в

которых присутствовал этот товар, но и об оптовой цене на этот товар.

Аномалия обновления. При изменении цены или наименования товара не-

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

ние наименования

товара было отражено во всех заказах. Пусть, к примеру, не-

обходимо изменить описание "Болты" на "Болты М6", поскольку на склад по-

ступили болты с другой маркой. Чтобы реализовать такую директиву, следует

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

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

с цело-

стностью информации, которые имеют место в реальных базах данных, могут

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

всего одной таблицы, можно полностью привести в негодность информацию об

этом товаре.

Для того чтобы выполнить требование второй нормальной формы для на-

шего примера, достаточно добавить к

таблице новый столбец – идентификатор

товара в заказе (код товара в заказе на рис. 3.19). Хотя новый товар был добав-

лен под номером 11, он по-прежнему относится к заказу, определенному поряд-

ковым номером заказа. В результате обеспечивается уникальная идентификация

строк в таблице путем ввода нового первичного ключа и преодолевается про-

блема, связанная

с операциями включения данных. Проблемы, связанные с опе-

рациями удаления и обновления, в данном случае не решаются, и необходима

дальнейшая нормализация.

Код това-

ра в заказе

Номер заказа Код товара

Наименование

товара

Оптовая цена

1 1 1320 Болты 12

2 1 1405 Молоток 20

3 1 1602 Гвозди 10

4 1 1201 Гайки 16

5 1 1000 Электропила 880

6 1 1320 Болты 12

1 2 2001 Напильник 19

2 2 1001 Ключ гаечный 14

3 2 2345 Отвертка 15

1 3 3021 Стамеска 24

2 3 4000 Рубанок 124

Рис. 3.19. Фрагмент организации данных, удовлетворяющих условию 2НФ

Глава 3. Основы систем управления базами данных

3-47

3.8.3. Третья нормальная форма

В таблице, соответствующей третьей нормальной форме (3НФ, Third

Normal Form, 3NF), помимо требований для 2НФ, ни одно из неключевых полей

таблицы не должно зависеть функционально от любого другого неключевого

поля. Что это означает?

На приведенном выше рис. 3.19 показан пример нарушения условий 3НФ,

поскольку существует транзитивная функциональная связь

непервичного атри-

бута "Код товара" от ключа "Номер товара в заказе" вида

Наименование товара

→

Код товара

→

Номер товара в заказе

Возникает аномалия включения данных: если товар не участвует в заказе,

то в базе данных нельзя хранить информацию о его оптовой цене. Кроме этого

по-прежнему остаются аномалии удаления и обновления.

На рис. 3.20 представлена таблица 3НФ, в которой проблема скорректи-

рована путем удаления столбцов "Наименование товара

" и "Оптовая цена".

Код товара в заказе Номер заказа Код товара

1 1 1320

2 1 1405

3 1 1602

4 1 1201

5 1 1000

6 2 2001

7 2 1001

8 2 2345

9 3 3021

10 3 4000

11 1 1320

Рис. 3.20. Фрагмент таблицы из базы данных, находящихся в 3НФ

Чтобы не потерять информацию о кодировке товаров и ценах, создадим

дополнительно таблицу "Инвентаризация" (рис. 3.21), в которой можно хранить

информацию о наименовании товаров и ценах, и свяжем ее с исходной таблицей

по ключевому полю "Код товара". Виды взаимосвязей в моделях

данных мы рас-

смотрим далее.

После такой нормализации возникает вопрос о получении полной картины

проданных товаров. Каким образом можно узнать всю информацию об опреде-

ленном товаре, его описание, цену и так далее? В реляционной базе данных для

этого существует механизм связывания таблиц по ключевым полям, для вывода

необходимой информации используются

так называемые виды (или представле-

ния), которые, в отличие от таблиц базы данных, не хранятся в ней постоянно, а

служат лишь для представления результатов на экран. В данном примере две

Глава 3. Основы систем управления базами данных

3-48

таблицы связаны по ключевым полям "Код товара", и нужно просто создать за-

прос к БД, который возвратит всю необходимую информацию. На рис. 3.22 по-

казан вид, который объединяет рассматриваемые таблицы.

Код товара Наименование товара Оптовая цена

1000 Электропила 880

1001 Ключ гаечный 14

1201 Гайки 16

1320 Болты М4 12

1320 Болты М6 12

1405 Молоток 20

1602 Гвозди 10

2001 Напильник 19

2345 Отвертка 15

3021 Стамеска 24

4000 Рубанок 124

Рис. 3.21. Фрагмент таблицы "Инвентаризация"

Номер заказа Код товара Наименование товара Розничная цена

1 1000 Электропила 1100

1 1001 Ключ гаечный 18

1 1201 Гайки 20

1 1320 Болты М4 16

1 1320 Болты М6 16

2 1405 Молоток 25

2 1602 Гвозди 13

2 2001 Напильник 24

3 2345 Отвертка 19

3 3021 Стамеска 30

3 4000 Рубанок 156

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

из двух связанных таблиц

Распределяя информацию по нескольким таблицам, можно, как и раньше,

получить необходимую для работы полноту данных. При этом изменяются толь-

ко методы извлечения данных.

3.9. Семантическое моделирование данных.

Диаграммы «сущность–связь»

3.9.1. Основные понятия