Теоретический анализ

5 ТЕОРЕТИЧЕСКИЙ АНАЛИЗ

5.1 Концептуальное моделирование структуры данных

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

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

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

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

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

Концептуальные модели данных

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

Обычно различают концептуальные модели двух видов:

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

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

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

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

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

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

Модель «сущность-связь»

Одной из наиболее популярных семантических моделей данных является модель «сущность-связь» (часто называемая также ER-моделыо — по первым буквам ан­глийских слов Entity (сущность) и Relation (связь)).

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

Для моделирования структуры данных используются ER-диаграммы (диаграммы «сущность-связь»), которые в наглядной форме представляют связи между сущ­ностями. В соответствии с этим ER-диаграммы получили распространение в CASE-системах, поддерживающих автоматизированное проектирование реляционных баз данных. Наиболее распространенными являются диаграммы, выполненные в со­ответствии со стандартом IDEF1X, который используют наиболее популярные CASE-системы (в частности, ERwm, Design/IDEF, Power Designer).

5.2 Информационный анализ предметной области и выделение информационных объектов

Входная информация задачи «Учета и анализа ассортимента готовой продукции» разделяется на условно-постоянную и оперативно-учетную информацию.

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

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

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

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

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

Таблица 5.1 - Функциональные зависимости реквизитов

Наименование документа	Наименование реквизитов	Имя реквизита	Функциональные зависимости
1	2	3	4
Заявка	Номер заявки	НомЗаяв
Дата размещения	Дата разм
Дата назначения	Дата назн
Дата исполнения	Дата испол
Заказчик	Клиент
Получатель	Получатель
Бригадир	Бригадир
Товар	Наименование
Ткань	Ткань
Еденица измерения	Ед. Изм
Количество	Количество
Цена	Цена
Карточка учета готовой продукции	Номер карточки	НомКарт
Наименование товара	Наименование
Ткань	Характеристика ткани
Размер	Размер
Дата	Дата
Приход	Количество
Расход	Количество
Адрес получателя	Получатель
Примечание	Примечание
Остаток	Остаток

Фактура	Номер фактуры	НомФак
Наименование и адрес организации	Продавец
Дата составления	Дата испол
Адрес получателя	Заказчик
Порядковый номер изделия	ПорНом
Наименование изделия	Наименование
Единица измерения	ЕдИзм
Количество	Количество
Цена	Цена
Сумма	Сумма
Журнал приема готовой продукции	Дата приема	Дата приема
Бригадир	Бригадир
Наименование продукции	Наименование
Размер	Размер
Количество	Количество

Продолжение таблицы 5.1

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

Таблица 5.2 – Соответствие описательных и ключевых реквизитов

Описательные (зависимые реквизиты)	Ключевые реквизиты	Вид ключа	Имя ИО, включающего реквизит
1	2	3	4
Номер заявки	НомЗаяв	Простой уникальный	ЗАКАЗ
Дата размещения	НомЗаяв	Простой уникальный	ЗАКАЗ
Дата назначения	НомЗаяв	Простой уникальный	ЗАКАЗ

Продолжение таблицы 5.2

Дата исполнения	НомЗаяв	Простой уникальный	ЗАКАЗ
Заказчик	НомЗаяв Клиент	Простой уникальный	КЛИЕНТ
Получатель	НомЗаяв Клиент	Составной уникальный	КЛИЕНТ
Бригадир	НомЗаяв Наименование	Составной уникальный	БРИГАДА
Наименование	НомЗаяв Наименование	Составной уникальный	ТОВАР
Ткань	НомЗаяв Наименование	Составной уникальный	ТОВАР
Еденица измерения	НомЗаяв Наименование	Составной уникальный	ТОВАР
Количество	НомЗаяв Наименование	Составной уникальный	ЗАКАЗАНО
Цена	НомЗаяв Наименование	Составной уникальный	ЗАКАЗАНО
Номер карты	НомКарт	Простой уникальный	ЗАКАЗ
Наименование товара	Наименование	Простой уникальный	ЗАКАЗ
Ткань	НомКарт Наименование	Составной уникальный	ЗАКАЗ
Размер	НомКарт Наименование	Составной уникальный	ЗАКАЗ
Дата	НомКарт Наименование	Составной уникальный	ЗАКАЗ
Приход	НомКарт Наименование	Составной уникальный	ТОВАР
Расход	НомКарт Наименование Получатель	Составной уникальный	ЗАКАЗ
Кому отпущено	НомКарт Наименование Получатель	Составной уникальный	КЛИЕНТ
Примечание	НомКарт Наименование Получатель	Составной уникальный	ЗАКАЗ
Остаток	НомКарт Наименование	Составной уникальный	ЗАКАЗ

Продолжение таблицы 5.2

Номер фактуры	НомФак	Простой уникальный	ЗАКАЗ
Наименование и адрес организации	НомФак	Простой уникальный	КЛИЕНТ
Дата составления	НомФак Заказчик	Составной уникальный	КЛИЕНТ
Адрес получателя	НомФак Заказчик	Простой уникальный	КЛИЕНТ
Порядковый номер изделия	НомФак	Простой уникальный	ТОВАР
Наименование изделия	НомФак Наименование	Составной уникальный	ЗАКАЗ
Единица измерения	НомФак Наименование	Составной уникальный	ТОВАР
Количество	НомФак	Простой уникальный	ЗАКАЗ
Цена	НомФак Наименование	Составной уникальный	ТОВАР
Сумма	НомФак	Простой уникальный	ЗАКАЗ
Дата приема	Наименование	Простой уникальный	ТОВАР
Бригадир	Наименование	Простой уникальный	ТОВАР
Наименование продукции	Наименование	Простой уникальный	ТОВАР
Размер	Наименование	Простой уникальный	ТОВАР
Количество	Наименование	Простой уникальный

Таблица 5.3- Группировка реквизитов ИО

Реквизиты ИО	Признак ключа	Имя ИО	Семантика ИО
1	2	3	4
Наименование Характеристика ткани Единица измерения Цена Размер НаСкладе	Простой уникальный	ТОВАР	Сведения о готовой продукции
НомЗаяв Заказчик Получатель Адрес получателя Адрес заказчика	Простой уникальный	КЛИЕНТ	Сведения о клиентах, делающих заказ
НомЗаяв ДатаРазмещения ДатаНазначения ДатаИсполнения	Простой уникальный	ЗАКАЗ	Хронологические данные о выполнении заказа
НомЗаяв Бригадир	Простой уникальный	БРИГАДА	Ответственный за выполнение заказа
НомЗаяв Наименование Количество Цена	Составной уникальный	ЗАКАЗАНО	Потенциально оплаченный товар
КодТипа Категория Омисание	Простой уникальный	ТИПЫ	Указатель для товаров

5.3 Определение связей информационных объектов и построение информационно-логической модели

Необходимо определить связи между информационными объектами. Поскольку в таблицах: КЛИЕНТ, ЗАКАЗ, БРИГАДА, ЗАКАЗАНО фигурирует один первичный ключ, что не допускает реляционная модель данных, то будем использовать суррогатные ключи: КодБригады, КодЗаказа, КодКлиента, КодТипа.

Связи между объектами КЛИЕНТ и ЗАКАЗ характеризуются одно-многозначными отношениями, поскольку один клиент может сделать несколько заказов.

Связь между ними осуществляется по уникальному суррогатному ключу объекта КЛИЕНТ – код клиента. Аналогично устанавливаются связи между остальными выявленными информационными объектами. Они определяются реальными отношениями между парами объектов. Эти связи показаны в табл. 5.4

Таблица 5.4 – Связи информационных объектов

Ключ связи	Главный ИО	Подчиненный ИО	Тип отношения
1	2	3	4
КодКлиента	КЛИЕНТ	ЗАКАЗ	1:М
КодБригады	БРИГАДА	ЗАКАЗ	1:М
КодЗаказа	ЗАКАЗЫ	ЗАКАЗАНО	1:М
Наименование	ТОВАРЫ	ЗАКАЗАНО	1:М
КодТипа	ТИПЫ	ТОВАРЫ	1:М

Для упрощения дальнейшей работы и контроля выявленных отношений предметной области воспользуемся распространенным CASE средством ER-win 4.0.

Рисунок 5.1 – Логическая структура реляционной базы данных. Состав атрибутов сущностей (FA - уровень)