Инфологическое проектирование.

На данном зтапе проектирования баз данных разрабатывается инфологическая модель (ИЛМ) предметной области.

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

Основные понятия и требования, предъявляемые к ИЛМ.

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

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

Основные требования, предъявляемые к ИЛМ.

Инфологическая модель должна:

а) адекватно отображать предметную область;

б) иметь однозначность трактовки;

в) быть конечной:

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

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

Основные компоненты инфологической модели

1.Центральной компонентой ИЛМ является описание объектов предметной области и связей между ними (ER - модель).

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

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

В качестве одного из средств описания ИЛМ используются графические средства (ER-диаграммы). Они подробно были рассмотрены в предыдущем разделе.

Модель арифметических вычислений

Модель арифметических вычислений основывается на графе взаимосвязей показателей (файлов).

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

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

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

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

П(Р1, Р2, …,РК, Q), где

P1, P2, …,РК – атрибуты – признаки; Q – атрибут – основание.

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

Показатель удобно применять как обобщенную единицу измерения объема данных.

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

Так показатель ПЗ (Кмат. Цена) соответствует величине С(i), где С(i) – цена материала с i – м кодом материала Кмат.

Отличие состоит в том. что индекс i переменной С обычно изменяется от 1 до некоторого фиксированного значения, а номенклатурные номера материалов могут кодироваться многими способами, необязательно порядковыми кодами.

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

Таким образом, модель арифметических вычислений есть граф G(S, U). Множество вершин S={s{i)} представляет собой все показатели (файлы) s(i) и s(j), хранящиеся в базе данных. Дуга u(ij) or s(i) к s(j) существует в том смысле, если существует расчетное соотношение для показателя s(j) и в правой части этого соотношения присутствует показатель s(i).

Даталогическое проектирование

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

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

Нe все виды связей, существующие в предметной области, могут быть непосредственно отображены в конкретной даталогической модели. Так отношение М : М между элементами не поддерживают многие СУБД, в частности Microsoft Access. В этом случае в даталогическую модель вводится дополнительный элемент, отображающий связь между рассматриваемыми элементами.

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

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

Основные подходы к созданию реляционной базы данных

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

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

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

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

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

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

2.Если у объекта имеются множественные свойства, то каждому из них ставится в соответствие отдельное отношение

Инфологические конструкции Реляционные схемы

R1 (ИО1, С1, С2, С3)

R1 (ИО1, С1, С2)

R2 (ИО1, С3)

R 3 (ИО1, С4)

R1 (ИО1, С1, С2)

или

R1 (ИО1, С)

R1 (ИО1, С1, ИО2, С2)

или

R1 (ИО1, С1, ИО2)

R2 (ИО2, С2)

R1 (ИО1, С1)

R2 (ИО2, С2, ИО1)

R1 (ИО1, С1)

R2 (ИО2, С2, ИО1)

R1 (ИО1, С1)

R2 (ИО1, С2)

R3 (ИО1, ИО2)

З.Для отображения объектов, между которыми существует связь 1:1, можно использовать одно отношение, если связь 1:1 реализована на одном и том же множестве объектов (экземпляров объектов) (рис. 3,г ).

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

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

5.Для хранения информации об объектах, имеющих связи. М:М, необходимы три отношения, по одному для каждой сущности, и одно – для отображения связи между ними (рис. 3,ж). Возможны и другие варианты реляционных схем для отображения инфологических конструкций.

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

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

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

Алгоритм перехода от ER – модели к реляционной схеме данных

Шаг 1. Каждая простая сущность превращается в таблицу. Простая сущность - сущность, не являющаяся подтипом и не имеющая подтипов. Имя сущности становится именем таблицы.

Шаг 2. Каждый атрибут становится возможным столбцом с тем же именем; может выбираться более точный формат. Столбцы, соответствующие необязательным атрибутам, могут содержать неопределенные значения; столбцы, соответствующие обязательным атрибутам, - не могут.

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

Шаг 4. Связи многие-к-одному (и один-к-одному) становятся внешними ключами. Т.е. делается копия уникального идентификатора с конца связи "один", и соответствующие столбцы составляют внешний ключ. Необязательные связи соответствуют столбцам, допускающим неопределенные значения; обязательные связи - столбцам, не допускающим неопределенные значения.

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

Шаг 6. Если в концептуальной схеме присутствовали подтипы, то возможны два способа:

• все подтипы в одной таблице

• для каждого подтипа - отдельная таблица.

Средства автоматизации проектирования ЭИС (CASE - средства)

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

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

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

Модели структурного проектирования.

Наиболее распространенные:

• диаграммы сущность-связь или ER-диаграмма;

• диаграмма потоков данных DFD (Data Flow Diagrams). Служит для иерархического описания модели системы;

• метод структурного анализа и проектирования Structured Analysis Design Technigue (SADT), служит для построения функциональной модели объекта и др.

Существуют различные признаки классификации CASE – средств:

а) в классификации CASE – средств по функциональной системы, предназначены для решения частных задач на одном или нескольких этапах жизненного цикла. Среди них – ERwin.

При разработке структуры БД с помощью этого средства формируется концептуальная модель данных (КМД), которая впоследствии преобразуется в физическую модель (ФМД). Концептуальная модель предметной области – это ER модель. Сущности изображаются прямоугольниками, внутри которых расположены атрибуты. Индикаторы сущностей (ключевые атрибуты) подчеркиваются.

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

б) построение функциональной модели – создание таблиц для некоторой СУБД. При генерации физической модели данных каждой сущности ставится в соответствии таблице. Атрибуты преобразуются в колонки таблиц. Подчеркнутые атрибуты становятся ключами. Если в КМД связь между сущностями М:М, то при построении ФМД автоматически создается дополнительная таблица. Первичный ключ этой таблицы объединяет колонки первичных ключей двух исходных связанных таблиц.

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

Рассмотренные CASE – средства автоматизации проектирования базы данных. При разработке структуры БД с помощью этого средства формируется концептуальная модель данных (КМД), которая впоследствии преобразуется в физическую модель (ФМД).