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

Реляционная модель впервые была предложена Э.Ф.Коддом в 1970 году. Реляционная модель является основой современной технологии баз данных. Знания, умения и опыт в области баз данных нельзя признать удовлетворительными, если человек не имеет глубокого и ясного представления о реляционной модели.

Реляционные системы базируются на теории, которая называется реляционной моделью данных. Основным понятием этой теории является понятие отношения. Отношение – это математическое понятие, физическим представлением которого является определенного вида таблица. В таблице содержатся некоторые факты, относящиеся к объектам Отдел и Служащий. Отношение – это и есть множество фактов, касающееся объектов, которые можно обсуждать. Таблица – это физическое представление отношения, то есть множества фактов, относящихся к обсуждаемым объектам. Факты связаны с отношениями точно так же, как существительные связаны с предложениями. То, что мы можем обсуждать, — это номера служащих, их имена, номера отделов и значения денежных сумм, а то, что мы можем сказать об этих объектах, — это какое-то высказывание типа: «Служащий с определенным номером имеет определенное имя, работает в определенном отделе и получает определенную зарплату». Таким образом, необходимы и факты, и отношения (без фактов нам не о чем говорить, без отношений мы ничего не сможем сказать). Кроме того, факты и отношения достаточны так же, как и необходимы, то есть, логически говоря, нам не нужно что-либо еще.

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

Структуры данных Наиболее важные термины описания структуры данных представлены на рисунке 12.

Отношение – плоская таблица, состоящая из столбцов и строк.

Атрибут – поименованный столбец отношения.

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

Кортеж – строка отношения.

Степень – количество атрибутов, содержащихся в отношении.

Кардинальность – количество кортежей, которое содержит отношение.

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

Реляционная база данных – набор отношений (нормализованных

Каждый кортеж отношения представляет собой определенное высказывание об объекте

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

Точное определение термина отношение:

Пусть задано множество доменов Тi (I = 1, 2,..n), все из которых необязательно должны быть различными. Тогда r будет отношением, определенным на этих доменах, если оно состоит из двух частей – заголовка и тела, где

а) заголовок – это множество из n атрибутов вида Ai: Ti; здесь Ai – имена атрибутов, а Ti – соответствующие им имена типов.

б) тело – это множество из m кортежей t; здесь t, в свою очередь, является множеством компонентов вида Ai: Vi, в которых Vi – значение типа Ti, то есть значение атрибута Ai в кортеже t (I = 1, 2,..n).

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

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

Отношения обладают следующими свойствами:

в них нет одинаковых кортежей;

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

атрибуты в кортежах не упорядочены слева направо;

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

Свойство 1: Свойство следует из того факта, что тело отношения – это математическое множество (кортежей), а в математике множества по определению не содержат одинаковых элементов.

Таблица, в общем случае, может содержать одинаковые строки (при отсутствии правил, запрещающих это).

Свойство 2: Свойство следует из того, что тело отношения – это математическое множество, а простые множества в математике не упорядочены.

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

Свойство 3: Свойство следует из того факта, что заголовок отношения также определен, как множество (атрибутов). Атрибут всегда определяется по имени, а не по расположению.

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

Свойство 4: Свойство следует из определения кортежа: кортеж является множеством из n компонентов. Отношение, удовлетворяющее этому свойству, называется нормализованным или представленным в первой нормальной форме (1НФ).

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

Дополнительные свойства:

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

Каждый атрибут имеет уникальное имя.

Значения атрибута берутся из одного и того же домена.

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

Реляционные ключи

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

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

Потенциальный ключ – это суперключ, который не содержит подмножества, также являющегося суперключом данного отношения.

Такой ключ обладает двумя свойствами:

уникальность – в каждом кортеже отношения значение ключа единственным образом идентифицирует этот кортеж;

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

Отношение может иметь несколько потенциальных ключей. Если ключ состоит из нескольких атрибутов, то он называется составным ключом.

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

Внешний ключ – это атрибут или множество атрибутов, которое соответствует какому-либо потенциальному ключу некоторого (может быть, того же самого) отношения.

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

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

Манипулирование данными

Как уже говорилось ранее для управления отношениями в реляционных СУБД можно использовать процедурные и непроцедурные языки. Коддом были предложены формальные (а не дружественные пользователю) языки – реляционная алгебра и реляционное исчисление.

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

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

Реляционная алгебра и реляционное исчисление эквивалентны друг другу. Для каждого выражения алгебры существует эквивалентное выражение в реляционном исчислении (и наоборот).

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

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

Восемь операторов составляют две группы по четыре оператора:

1. Традиционные операции над множествами – объединение, пересечение, разность и декартово произведение (с учетом того, что их операндами являются отношения, а не произвольные множества).

2. Специальные реляционные операции – выборка, проекция, соединение и деление.

5.5.1. Специальные реляционные операции

Выборка

Результат операции выборка — отношение, содержащее все кортежи из заданного отношения, удовлетворяющие определенным условиям (рис 14).

Проекция

Результат операции проекция — отношение, содержащее кортежи заданного отношения, состоящие из определенных атрибутов (остальные атрибуты исключены) (рис.15).

Соединение

Результат операции соединение — отношение, содержащее все возможные кортежи, которые представляют собой комбинацию атрибутов двух кортежей, принадлежащих двум заданным отношениям, при условии, что в этих двух комбинируемых кортежах присутствуют одинаковые значения в одном или нескольких общих для исходных отношений атрибутах (причем эти общие значения в результирующем кортеже появляются один раз, а не дважды) (рис.16).

Деление

Результат операции деления для заданных двух отношений (унарных) и одного бинарного — отношение, содержащее все кортежи из первого унарного отношения, которые содержатся также в бинарном отношении и соответствуют всем кортежам во втором унарном отношении (рис.17).

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

5.5.2. Традиционные операции над множествами

Объединение

Результат операции объединение — отношение, содержащее все кортежи, которые принадлежат либо одному из двух заданных отношений, либо им обоим (рис. 18).

Произведение

Результат операции произведение — отношение, содержащее все возможные кортежи, которые являются сочетанием двух кортежей, принадлежащих соответственно двум заданным отношениям.

Пересечение

Результат операции пересечение — отношение, содержащее все кортежи, которые принадлежат одновременно двум заданным отношениям. (рис. 20).

Разность

Результат операции разность — отношение, содержащее все кортежи, которые принадлежат первому из двух заданных отношений и не принадлежат второму (рис.21).

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

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

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

Нормализация отношений

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

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

Нормализация – это метод создания набора отношения с заданными свойствами на основе требований к данным.

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

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

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

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

Аномалии вставки

Существуют два основных типа аномалий вставки.

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

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

Аномалии удаления

При удалении из отношения строки с информации о последнем сотрудники некоторого отделения, сведения об этом отделении будут полностью удалены из БД.

Первые два отношения позволяют избежать возникновения этой проблемы.

Аномалии обновления

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

Приведенные примеры иллюстрируют, что первые два отношения обладают более приемлемыми свойствами, чем отношение Staff-Branch.

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

Но вначале следует познакомиться с концепцией функциональной зависимости.

Функциональные зависимости

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

Если в отношении R, содержащем атрибуты А и В, атрибут В функционально зависит от атрибута А (что обозначается А → В), то каждое значение атрибута А связано только с одним значением атрибута В. (При этом каждый из атрибутов А и В может состоять из одного или нескольких атрибутов) (рис.22).

А В

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

В отношении Staff – может быть несколько сотрудников с одинаковыми должностями.

Связь между атрибутами StaffNo и Position относится к типу 1:1, поскольку для каждого номера сотрудника имеется только одна должность. А связь между атрибутами Position и StaffNo имеет тип 1:N, так как существует несколько номеров сотрудников, занимающих одну и ту же должность.

Для выявления ключей отношения Staff — Branch необходимо найти атрибут (или группу атрибутов), который уникальным образом идентифицирует каждую строку этого отношения. Это атрибут StaffNo.

Процесс нормализации

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

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

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

1НФ — отношение, в котором на пересечении каждой строки и каждого столбца содержится только одно значение (отсутствуют повторяющиеся группы данных).

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

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

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

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

Вторая нормальная форма основана на понятии полной функциональной зависимости.

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

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

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

Если в отношении нет составного первичного ключа и оно находится в 1НФ, то оно автоматически также находится и в 2НФ.

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

Третья нормальная форма основана на понятии транзитивной зависимости.

Транзитивная зависимость. Если для атрибутов А, В и С некоторого отношения существуют зависимости вида А В и В С, то говорят, что атрибут С транзитивно зависит от атрибута А через атрибут В (при условии., что атрибут А функционально не зависит ни от атрибута В, ни от атрибута С).

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

то есть статус поставщика определяется его местонахождением, например, все поставщики из Лондона должны иметь статус 20.

Отношение, которое находиться в 2НФ, но не находится в 3НФ, всегда может быть преобразовано в эквивалентный набор (двух) отношений, находящихся в 3НФ. Для этого транзитивно зависимые атрибуты удаляются из такого отношения и помещаются в новое отношение вместе с копией их детерминанта (табл.15,16).

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

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

Нормальная форма Бойса-Кодда (НФБК)

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

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

Отношение находится в НФБК тогда и только тогда, когда каждый его детерминант является потенциальным ключом.

Для отношения с единственным потенциальным ключом его 3НФ и НФБК являются эквивалентными.

Для проверки принадлежности отношения к НФБК необходимо найти все его детерминанты и убедиться в том, что они являются потенциальными ключами. (Детерминантом является один или несколько атрибутов, от которых полностью функционально зависит другой атрибут).

С другой стороны, три результирующих отношения Sp, SC и CS находятся и в 3НФ и в НФБК, поскольку в каждом из них имеется единственный потенциальный ключ, являющийся единственным детерминантом для данного отношения.

Рассмотрим другой пример. Пусть имеется отношение S (табл. 17) с атрибутами (SNo, SNAME, CITY, STATUS), в котором атрибуты SNo и SNAME являются его потенциальными ключами, т.е. каждый поставщик имеет уникальный номер и уникальное имя.

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

Подходы к проектированию БД

Существует два подхода к проектированию БД – подход, основанный на принципах нормализации, и подход, основанный на использовании моделей «сущность- связь».

Ранее был рассмотрен подход, основанный на нормализации отношений. Теперь рассмотрим второй подход.

Модель «сущность-связь» представляет собой концептуальную модель данных, которая была предложена в 1976 году Ченом. Данная модель данных основана на наборе понятий (концепций), с помощью которых можно представить структуру базы данных. Основная цель разработки концептуальной модели заключается в создании пользовательского восприятия данных, не зависимого от конкретного типа СУБД.

Понятия ER- модели

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

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

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

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

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

Слабый тип сущности — тип сущности, существование которого зависит от какого-то другого типа сущности.

Сильный тип сущности- тип сущности существование которого не зависит от какого-то другого типа сущности.

Книга — сильная сущность, формуляр (на каждый экземпляр книги) — слабая сущность.

 

Атрибуты - свойство типа сущности или типа связи.

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

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

Каждый атрибут связан с набором значений, который называется доменом.

Атрибуты могут быть потенциальными ключами, первичными ключами.

Ключи могут быть составными.

Типы связей — осмысленная ассоциация между сущностями разных типов.

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

Например, книга связанна с автором связью «Написана». Книга связана с формуляром связью «Имеет».

Связь — ассоциация между сущностями, включающая по одной сущности из каждого участвующего в связи типа сущности

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

Охваченные некоторой связью сущности называются участниками. Связь со степенью два называется бинарной. Связь со степенью три называется тернарной (рис.26).

Рекурсивная связь — в которой одни и те же сущности участвуют несколько раз и в разных ролях (рис.27).

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

Наиболее распространенными являются бинарные связи с показателями кардинальности 1:1, 1:N и M:N.

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

Сильная Слабая

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

Книга

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

Существует два варианта участия сущности в связи: полное (обязательное) и частичное (необязательное) – рисунки 31,32.

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

Первая нотация рассматривает связанности со стороны объекта (рис.33), а не дуги (связи). Объект 1 связан только с одним объектом, а объект 2 связан с N объектами 1.

Вторая нотация рассматриваетсвязанности относительно дуги (рис. 34).

Дуга может быть связанаc N объектами 1 и с одним объектом 2.

Использование CASE-инструментов

Проектирование базы данных может предусматривать выбор наиболее подходящего инструмента автоматизированного проектирования — CASE-инструмента (Computer-Aided Software Engineering).

В самом широком смысле термин CASE- инструмент применим к любым средствам автоматизированного проектирования и создания программ.

CASE- инструменты могут включать следующие компоненты:

словарь данных, предназначенный для хранения информации в данных, используемых в создаваемом приложении;

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

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

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

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

CASE- инструменты предназначены для упрощения и автоматизации решения отдельных задач в ходе разработки системы, а поэтому позволяют существенно повысить продуктивность труда разработчиков. CASE- инструменты позволяют повысить качество конечного продукта, поскольку компьютеры лучше, чем человек, справляются с определенными задачами. Кроме того, использование CASE- инструментов существенно упрощает процесс создания и поддержку разнообразных диаграмм и позволяет генерировать более корректную документацию. CASE-инструменты позволяют автоматически преобразовать фрагменты спецификаций проекта(например, физическую диаграмму данных) в SQL операторы и выполняемый код, что сокращает объем работы по созданию готовой системы.

Методология проектирования БД с помощью Case-инструментов SILVERRUN

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

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

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

Логическое проектирование БД необходимо для создания информационной модели предприятия на основе разработанного концептуальной модели с учетом используемого типа СУБД (но не конкретной СУБД и прочих физических условий реализации).

Физическое проектирование БД — это процесс создания описания конкретной реализации БД с учетом особенностей выбранной СУБД. Эта фаза заканчивается созданием конкретной БД для создаваемого приложения, на основании разработанной ранее логической модели.

CASE- инструменты SILVERRUN содержат три программных пакета SILVERRUN-BPM, SILVERRUN-ERX и SILVERRUN-RDM, которые (в основном) используются на соответствующих фазах проектирования- концептуальном, логическом и физическом проектировании.

Ниже приведен перечень основных этапов работы с CASE- инструментом SILVERRUN. Более детальное описание практического использования этого CASE- средства вместе с вариантами индивидуальных заданий содержится в методических указаниях по выполнению лабораторных работ по курсу «Базы данных».

Использование SILVERRUN-BPM

Для моделирования процессов предметной области целесообразно использовать CASE- средство SILVERRUN-BPM (Business Process Modeling).

Вначале необходимо сформулировать назначение разрабатываемого приложения БД. Цель должна быть сформулирована кратко без обширных пояснений и обоснования.

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

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

Рассмотрим следующий пример, с помощью которого будут рассмотрены основные фазы и этапы проектирования БД (для конкретного приложения).

Компания занимается реализацией комплектующих для персональных компьютеров. Назначение разрабатываемого приложения: помощь компании в заключении договоров с клиентами на покупку комплектующих. Название приложения DEALER.

Назначение приложения — система DEALER обслуживает процесс торговли.

Функции приложения:

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

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

система генерирует договоры на продажу комплектующих.

Контекстная диаграмма

Анализ предметной области начинается с создания контекстной диаграммы с помощью CASE- средства SILVERRUN- BPM.

Основные элементы диаграмм CASE- средства SILVERRUN-BPM: Внешние объекты Процессы Потоки информации Накопители

Детализирующая диаграмма

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

Анализ информационных потоков показывает, что в модели должны быть три накопителя (рис.36):

складе

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

 

CONTENT QTY Количество покупаемых комплектующих

CONTENT SUMСебестоимость покупаемых комплектующих

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

С накопителем CLIENT следует связать сущность CLIENT (табл. 23).

С накопителем DOGOV следует связать две сущности – DOGOV и CONTENT (табл. 24), при этом сущность CONTENT необходимо сделать слабой, т. к. перечень приобретаемых комплектующих не может существовать без (наличия) договора. Поэтому в структуре данных DOGOV необходимо предусмотреть подструктуру CONTENT.

После определения указанных выше объектов модели необходимо запустить на выполнение SILVERRUN-BPM и создать в нем концептуальную модель данных.