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

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

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

3-29

• один к одному;

• один ко многим;

• многие ко многим.

Связь «один к одному» предполагает, что в каждый момент времени каж-

дому элементу (кортежу) отношения А соответствует 0 или 1 элементов (корте-

жей) отношения В. Например, за каждым работником предприятия закреплен

один и только один табельный номер (рис. 3.14, а).

Связь «один

ко многим» состоит в том, что в каждый момент времени ка-

ждому элементу (кортежу) отношения А соответствует несколько элементов

(кортежей) отношения В (рис. 3.14, б). В качестве примера можно привести

связь между отношениями «Цех» и «Технологический агрегат»: в одном цехе

расположено несколько технологических агрегатов, каждый агрегат установлен

только в одном цехе

Связь «многие ко многим» предполагает, что в каждый момент времени

множеству элементов отношения А соответствует множество элементов отно-

шения В. К сожалению, этот тип связи в реляционных СУБД непосредственно не

поддерживается. На рис. 3.14, в приведен пример такого типа связи для отноше-

ний «Изделие» и «Технологическая операция»: каждое изделие проходит

мно-

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

ция выполняется для множества изделий.

3.6.2. Общая характеристика реляционной модели данных

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

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

Эти рассуждения в равной степени относились к

любой системе, при построении

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

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

ных. Модель данных описывает некоторый набор родовых понятий и признаков,

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

ных, если они основываются на этой модели. Наличие

модели данных позволяет

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

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

надлежит К.Дж.Дейту, известному американскому специалисту в области реля-

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

разные аспекты реляционного подхода:

• структурной части;

• манипуляционной части;

• целостной части.

В структурной части модели фиксируется, что единственной структурой

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

ние. Процедуру нормализации данных рассмотрим позже.

В манипуляционной части модели утверждаются два фундаментальных

механизма манипулирования реляционными БД – реляционная алгебра и реля-

ционное исчисление. Первый механизм базируется в основном на классической

теории множеств (с некоторыми

уточнениями), а второй – на классическом ло-

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

3-30

гическом аппарате исчисления предикатов первого порядка. Далее мы рассмот-

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

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

реляционности любого конкретного языка реляционных БД: язык называется ре-

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

реляционная алгебра или

реляционное исчисление.

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

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

онной СУБД. Первое требование называется требованием целостности сущно-

стей. Объекту или сущности реального мира в реляционных БД соответствуют

кортежи отношений. Конкретно требование состоит в том, что любой кортеж

любого отношения

отличим от любого другого кортежа этого отношения, т.е.,

другими словами, любое отношение должно обладать первичным ключом – уни-

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

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

свойства отношений.

Второе требование называется требованием целостности по ссылкам и

является несколько более

сложным. Очевидно, что при соблюдении нормализо-

ванности отношений (набора условий для формирования реляционной модели

данных) сложные сущности реального мира представляются в реляционной БД в

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

нам требуется показать в реляционной базе данных сущность ОТДЕЛ с атрибу-

тами ОТД_НОМЕР (номер отдела), ОТД_КОЛ (количество

сотрудников) и

ОТД_СОТР (набор сотрудников отдела). Для каждого сотрудника нужно хра-

нить СОТР_НОМЕР (номер сотрудника), СОТР_ИМЯ (имя сотрудника) и

СОТР_ЗАРП (заработная плата сотрудника). Как мы вскоре увидим, при пра-

вильном проектировании соответствующей БД в ней появятся два отношения:

ОТДЕЛЫ (

ОТД_НОМЕР, ОТД_КОЛ) (первичный ключ – ОТД_НОМЕР)

СОТРУДНИКИ (

СОТР_НОМЕР, СОТР_ИМЯ, СОТР_ЗАРП,

СОТР_ОТД_НОМ ) (первичный ключ – СОТР_НОМЕР).

Как видно, атрибут СОТР_ОТД_НОМ появляется в отношении

СОТРУДНИКИ не потому, что номер отдела является собственным свойством

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

ходимости полную сущность ОТДЕЛ. Значение атрибута СОТР_ОТД_НОМ

любом кортеже отношения СОТРУДНИКИ должно соответствовать значению

атрибута ОТД_НОМ в некотором кортеже отношения ОТДЕЛЫ. Атрибут такого

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

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

(т.е. задают значения их первичного ключа). Говорят, что отношение, в котором

определен внешний ключ, ссылается

на соответствующее отношение, в котором

такой же атрибут является первичным ключом.

Требование целостности по ссылкам, или требование внешнего ключа, со-

стоит в том, что для каждого значения внешнего ключа, появляющегося в ссы-

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

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

3-31

кортеж с таким же значением первичного ключа либо значение внешнего ключа

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

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

дел должен существовать.

Ограничения целостности сущности и по ссылкам должны поддерживать-

ся СУБД. Для

соблюдения целостности сущности достаточно гарантировать от-

сутствие в любом отношении кортежей с одним и тем же значением первичного

ключа. С целостностью по ссылкам дела обстоят несколько более сложно.

Понятно, что при обновлении ссылающегося отношения (вставке новых

кортежей или модификации значения внешнего ключа в существующих корте-

жах) достаточно следить за тем,

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

внешнего ключа. Но как быть при удалении кортежа из отношения, на которое

ведет ссылка? Здесь существуют три подхода, каждый из которых поддерживает

целостность по ссылкам.

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

кортежа, на который существуют ссылки (т.е. сначала нужно либо удалить ссы

лающиеся кортежи, либо соответствующим образом изменить значения их

внешнего ключа). При втором подходе при удалении кортежа, на который име-

ются ссылки, во всех ссылающихся кортежах значение внешнего ключа автома-

тически становится неопределенным. Наконец, третий подход (каскадное уда-

ление) состоит в том, что при удалении кортежа из отношения, на которое ведет

ссылка, из ссылающегося отношения автоматически удаляются все ссылающие-

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

держания целостности по ссылкам для каждой отдельной ситуации определения

внешнего ключа. Конечно, для принятия такого решения необходимо анализи-

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

3.6.3. Манипулирование данными с помощью языка запросов SQL

Ранее уже было отмечено, что языковые средства СУБД, обеспечивающие

обработку (представление и редактирование) данных, являются ее важнейшей

компонентой. Развитие реляционной модели данных привело к появлению реля-

ционных языков, наиболее распространенным из которых является SQL

(Structured Query Language, язык структурированных запросов). На сегодняшний

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

используется

в большинстве коммерческих систем.

SQL был разработан в компании IBM Research в начале 1970-х годов, с то-

го времени диалекты языка SQL стали Американским национальным стандартом

(ANSI), Международным стандартом (ISO), стандартом системы UNIX, стандар-

том корпорации IBM, описывающим "общий интерфейс базы данных". Язык

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

изменение структуры) и над данными (выборка

, добавление, изменение, удале-

ние), а также некоторых сопутствующих операций (сортировка, группировка

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

что считается одним из основных его преимуществ, и не содержит имеющихся в

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

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

3-32

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

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

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

опираются только на логическую структуру базы данных, а не на ее физическую

структуру, что согласуется с требованием реляционной модели. Основным тре

бованием от пользователя является умение правильно сформулировать запрос,

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

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

(Access, Paradox, Visual FoxPro и др.) или современных версий процедурных

языков программирования (Pascal, C++ и др.).

В силу ограниченности объема данной книги отметим только некоторые

функции языка по

организации запросов, иллюстрирующие структуру операто-

ров SQL. Для детального освоения языка SQL читателям можно рекомендовать

специальную литературу [15]. Все запросы на получение практически любого

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

единственного предложения SELECT. В общем случае результатом реализации

предложения SELECT является другая таблица. К этой новой (рабочей) таблице

может быть снова

применена операция SELECT и т.д., т.е. такие операции могут

быть вложены друг в друга. В упрощенном виде оператор SELECT имеет сле-

дующий формат:

SELECT [ALL|DISTINCT] <список данных>

FROM <список таблиц>

[WHERE <условие выборки>]

[GROUP BY <имя столбца> [, <список таблиц>]…]

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

следующим образом:

• SELECT (выбрать) – данные из указанных столбцов и (

если необходимо) вы-

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

ражениями и (или) функциями;

• FROM (из) – перечисленных таблиц, в которых расположены эти столбцы;

• WHERE (где) – строки из указанных таблиц должны удовлетворять указан-

ному перечню условий отбора строк;

• GROUP BY (группируя по) – указанному перечню столбцов с тем, чтобы

по-

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

во фразе SELECT SQL-функции SUM (сумма), COUNT (количество), MIN

(минимальное значение), MAX (максимальное значение) или AVG (среднее

значение).

Кроме традиционных операторов сравнения (= | <> | < | <= | > | >=), в

WHERE фразе используются условия BETWEEN (между), LIKE (похоже на), IN

(принадлежит), IS NULL (не определено) и EXISTS (существует), которые могут

предваряться оператором NOT (не). Критерий отбора строк формируется из од-

ного

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

• AND (и) – когда должны удовлетворяться оба разделяемых с помощью AND

условия;

• OR (или) – когда должно удовлетворяться одно из разделяемых с помощью

OR условий;

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

3-33

• AND NOT (и не) – когда должно удовлетворяться первое условие и не долж-

но второе;

• OR NOT (или не) – когда или должно удовлетворяться первое условие, или не

должно удовлетворяться второе, причем существует приоритет AND над OR

(сначала выполняются все операции AND и только после этого операции

OR). Для получения желаемого результата WHERE условия должны быть

введены в

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

бок.

В качестве иллюстрации возможностей SQL рассмотрим примеры запро-

сов, использующие указанные конструкции.

Запрос "Получить данные о видах загружаемых материалов в доменную

печь" на языке SQL выглядит следующим образом:

SELECT Материалы FROM Доменная_печь

Пример более сложного запроса, предполагающего формирование специ-

альных условий на результат отбора с

помощью фразы WHERE: "Получить дан-

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

доменной печи №1 при выпуске №123212".

SELECT Si_чуг, C_чуг

FROM Доменная_печь

WHERE Д_печь='1' AND N_выпуска='123212'

Запрос, иллюстрирующий использование встроенных статистических

функций (функций множества): "Получить общее количество выпусков на каж-

дой из доменных печей за 01.10.2000".

SELECT COUNT(N_выпуска)

FROM Доменная_печь

WHERE Дата_выпуска=#01.10.2000#

3.7. Основы проектирования реляционных баз данных

3.7.1. Основные требования при проектировании БД

Процесс разработки структуры (схемы) базы данных (БД) в соответствии с

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

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

процессе разработки все более сложных информационных систем (ИС

), которые

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

групп и коллективов. Одна такая интегрированная БД создавалась для решения

многих задач, каждая из которых использовала только "свою" часть данных,

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

главными методами проектирования стали методы исключения избыточности в

данных и формирования

эффективной структуры БД.

Было сформулировано принципиальное требование отделения прикладных

программ от интегрированных данных. Этот принцип направлен на отчуждение

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

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

вергаться изменениям.

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

3-34

Другой важной проблемой проектирования БД явилось обеспечение нуж-

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

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

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

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

ром тот, кто

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

этой задачи.

Сформировалось понимание интегрированной БД как общего информаци-

онного ресурса предприятия. Хранимые данные стали аналогичны большому

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

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

3.7.2. Основы классической методологии проектирования БД

Процесс проектирования

БД начинается с установления концептуальных

требований ряда пользователей (рис. 3.15). Концептуальные требования могут

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

зовываться не будут. Эти требования отдельных пользователей интегрируются в

едином "обобщенном представлении". Последнее называют концептуальной

моделью (схемой). Концептуальная модель представляет объекты и их взаимо-

Пользователь 1:

Концептуальные

требования

Концептуальная

модель

Логическая

модель

Внутренняя

модель

Пользователь N:

Концептуальные

требования

Пользователь 2:

Концептуальные

требования

………………

Прикладная

программа 1:

Внешняя модель

Прикладная

программа 2:

Внешняя модель

Прикладная

программа N:

Внешняя модель

. . .

Рис. 3.15. Модели представления данных

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

3-35

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

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

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

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

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

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

вами выбранной СУБД. Это потребует изменения концептуальной модели. Ва-

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

ся логической моделью. Важно помнить, что логическая модель данных обу-

словлена требованиями и характеристиками СУБД, поэтому при замене СУБД

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

ской модели, называемые внешними моделями (

подсхемами), отражающие их

требования и представления.

Логическая модель отображается в физическую память (например, диски).

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

ним, называется внутренней моделью.

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

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

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

программистов, основан-

ные на внешних моделях и требованиях к обработке данных. В целом эти ре-

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

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

жизненного цикла (ЖЦ) системы баз данных. Жизненный цикл системы баз дан-

ных делится на две отдельные фазы: фазу

анализа и проектирования и фазу экс-

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

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

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

можно детализировать содержание работ, выполняемых в течение этих фаз ЖЦ

системы баз данных. В этом смысле указанные

фазы включают следующие эта-

пы:

Фаза анализа и проектирования

1. Формулирование и анализ требований.

2. Концептуальное проектирование.

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

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

Фаза реализации и функционирования базы данных

1. Реализация базы данных.

2. Анализ функционирования и поддержка.

3. Модификация.

Фаза анализа и проектирования

Формулирование и анализ требований являются

наиболее трудным и

длительным по времени этапом проектирования. Однако он является наиболее

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

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

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

3-36

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

лями базы данных. Анализ требований обеспечивает согласованность целей

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

потоке организации.

Концептуальное проектирование имеет целью построение независимой

от СУБД информационной структуры путем объединения информационных тре-

бований пользователей. Результатом концептуального проектирования является

концептуальная модель.

Проектирование реализации (

проектирование логической схемы БД) со-

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

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

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

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

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

использующих базовый язык программирования

и язык манипулирования дан-

ными СУБД. Результатом являются функциональные спецификации програм-

мных модулей и набор возможных запросов к базе данных.

Физическое проектирование, так же как и проектирование реализации,

состоит из двух компонентов: выбор физической структуры базы данных и

уточнение спецификаций программных модулей, определенных на предыдущем

этапе. Результатом физического проектирования являются

полностью готовая к

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

пользованию.

Фаза реализации и функционирования базы данных

Реализация базы данных подразумевает создание базы данных и при-

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

базы данных, а также загрузку базы данных. Имеющиеся данные необходимо

преобразовывать

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

ской структуры в новую форму, соответствующую результатам проектирования

базы данных. Разработка прикладных программ связана с выбором базового

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

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

летворяющих требованиям пользователей к обработке

данных.

Анализ функционирования и поддержка используются для сбора и ста-

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

позволяет выявить степень обоснованности требований пользователей, а также

«узкие места» в процессе эксплуатации с целью пересмотра системы в будущем.

Поддержка базы данных должна обеспечивать ее целостность и эффективное

восстановление после сбоев.

Модификация

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

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

нирования системы или анализа мнений пользователей о работе системы. Целью

этого этапа является оптимизация функционирования существующей системы

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

3-37

путем реорганизации (корректировки логической или физической структуры БД)

базы данных и/или внесения изменений в программное обеспечение.

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

3.7.3. Основные этапы проектирования базы данных

Есть все основания называть рассматриваемую методологию проектиро-

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

тодические системы, для большинства

методов предложены формализованные

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

можности – нашли реальное применение в практике проектирования. Использо-

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

вниз". Структурность связывается с использованием иерархических структур

для детализации данных и функций и соответствующих достаточно "жестких"

проектных процедур.

Проектная схема получила название "каскадной"

(рис. 3.16).

Этап 1. Формулирование и анализ требований

На этом этапе устанавливаются цели организации, определяются специ-

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

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

ния документируются в форме, доступной как конечному пользователю, так и

проектировщику базы

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

вьюирования персонала различных уровней управления и ведущих специалистов

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

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

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

ется однозначное представление о семантике информационной модели. Специ-

фичные цели и

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

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

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

достигнутой технологии, а также политические и бюрократические ограничения.

Должна быть также оценена политика организации в отношении персонала,

управленческой деятельности и перспектив роста организации. Документирова-

ние может

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

ний или с помощью средств автоматизации. Может оказаться полезным на этапе

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

ных (т. е. связанные со специфичными приложениями), от требований, не зави-

сящих от процесса обработки.

Этап 2. Концептуальное проектирование

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

описанием и синтезом

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

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

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

ность-связь" (Entity-Relationship Diagrams, ER-диаграммы), которые мы рас-

смотрим в дальнейшем. Основу ER-диаграммы составляет набор сущностей

("сущность" в данном случае – синоним понятия "объект"), который представля-

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

3-38

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

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

детализировать свойства сущности. Один или несколько атрибутов могут слу-

Общие информа-

ционные требо-

вания

Характеристики

СУБД

Спецификации

требований

Информационная

структура

Логическая структура

базы данных (СУБД-

ориентированная) и

спецификации при-

кладных программ

Физическая структура

ба-

зы данных

Характеристики опе-

рационной системы

и аппаратно-

технических средств

Этап 2. Концептуальное

проектирование

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

реализации

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

ектирование

Этап 1. Формулировка и

анализ требований

Требования

к обработке

Рис. 3.16. Основные этапы проектирования баз данных