Реляционные базы данных. реляционные БД (от англ. relation — отношение) стали широко использоваться в программировании начиная с 70-х годов

реляционные БД (от англ. relation — отношение) стали широко использоваться в программировании начиная с 70-х годов. В таких БД объекты и взаимосвязи между ними представляются в виде таблиц, состоящих из строк и столбцов (рис. 3).

Рис 3. Схема реляционной базы данных

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

34.

35.

36.

37. Моделирование потоков данных (DFD).

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

Для построения DFD традиционно используются две различные нотации, соответствующие методам Йордана и Гейна-Сэрсона. Далее будем использовать нотацию Гейна-Сэрсона.

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

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

38. Компоненты DFD диаграммы: внешние сущности системы, подсистемы, процессы, накопители данных, потоки данных.

Основными компонентами диаграмм потоков данных являются:

· внешние сущности;

· системы и подсистемы;

· процессы;

· накопители данных;

· потоки данных.

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

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

Рис.1. Графическое изображение внешней сущности.

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

Рис.2. Подсистема по работе с физическими лицами (ГНИ - государствен­ная налоговая система).

Номер подсистемы служит для ее идентификации. В поле имени вводится наиме­нование подсистемы в виде предложения и соответствующими определения­ми и дополнениями.

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

Рис.3. Графическое изображение процесса

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

Использование таких глаголов, как «обработать», «модернизировать», или «от­редактировать», означает недостаточно глубокое понимание данного процесса и требует дальнейшего анализа.

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

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

Накопитель данных может быть реализован физически в виде ящика в картоте­ке, таблицы в оперативной памяти, файла на магнитном носителе и т.д. Накопи­тель данных на диаграмме потоков данных (рис. 4) идентифицируется букво­й “ D ” и произвольным числом. Имя накопителя выбирается из соображения наибольшей информативности для проектировщика.

Рис.4. Графическое изображение накопителя данных

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

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

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

Рис.5. Поток данных

39. Построение иерархии диаграмм потоков данных:

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

· размещать на каждой диаграмме от 3 до 6-7 процессов. Верхняя граница соответст­вует человеческим возможностям одновременного восприятия и пони­мания структуры сложной системы с множеством внутренних связей, нижняя граница выбрана по соображениям здравого смысла: нет необходимости детали­зировать процесс диаграммой, содержащей всего процесс или два;

· не загромождать диаграммы не существенными на данном уровне деталями;

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

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

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

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

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

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

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

· правило нумерации – означает, что при детализации подсистем должна поддержи­ваться их иерархическая нумерация. Например, подсистемы, детализи­рующие подсистему с номером 2, получают номера 2.1, 2.2, 2.3 и т.д.

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

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

В соответствии с вышесказанным процесс построения модели разбивается на следующие этапы:

1. Выделение множества требований в основные функциональные группы - процессы.

2. Выявление внешних объектов, связанных с разрабатываемой системой.

3. Идентификация основных потоков информации, циркулирующей между системо­й и внешними объектами.

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

5. Проверка предварительной контекстной диаграммы и внесение в нее изменени­й.

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

7. Проверка основных требований контекстной диаграммы.

8. Декомпозиция каждого процесса текущей DFD с помощью детализирующей диаграм­мы или спецификации процесса.

9. Проверка основных требований по DFD соответствующего уровня.

10. Добавление определений новых потоков в словарь данных при каждом их появле­нии на диаграммах.

11. Проверка полноты и наглядности модели после построения каждых двух-трех уровней.