Расчет показателей экономической эффективности проекта

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

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

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

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

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

Таких сущностей будет 4: :

1. Договор
2. Фирма
3. Товар
4. Документ

 

Проанализируем связи  между сущностями.

 

Название связи	Между сущностями
Заключает	Фирма	Договор
Получает	Фирма	Товар
Оформляет	Фирма	Документ

 

 

Изобразим графически каждый объект (сущность)  и его свойства (атрибуты)  см. на рисунках ниже.

 

 

Рисунок 2.1 Изображение связи «Объект - Свойство» для объекта «Договор»

 

 

Рисунок 2.2 Изображение связи «Объект - Свойство» для объекта «Фирма»

 

 

 

Рисунок 2.3 Изображение связи «Объект - Свойство» для объекта «Товар»

 

 

 

Рисунок 2.4 Изображение связи «Объект - Свойство» для объекта «Документ»

 

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

Она должна включать такое формализованное  описание предметной области, которое  легко будет «читаться» как специалистами  по базам данных, так и всеми  пользователями. И это описание должно быть настолько емким, чтобы можно было оценить глубину и корректность проработки проекта БД, и конечно, оно не должно быть привязано к конкретной СУБД. Выбор СУБД — это отдельная задача, для корректного ее решения необходимо иметь проект, который не привязан ни к какой конкретной СУБД. Инфологическое проектирование прежде всего связано с попыткой представления семантики предметной области в модели БД, которая слабо отражается в сетевых, иерархических моделях данных.  Было предложено несколько моделей данных, названных семантическими моделями. У всех этих моделей были свои положительные и отрицательные стороны, но испытание временем выдержала только модель «сущность—связь», или Entity Relationships, которая стала фактическим стандартом при инфологическом моделировании баз данных. Общепринятым стало сокращенное название ER-модель, а большинство современных CASE-средств содержат инструментальные средства для описания данных в формализме этой модели. Кроме того, разработаны методы автоматического преобразования проекта БД из ER-модели в реляционную БД, при этом одновременно выполняется преобразование в модель конкретной СУБД. Все CASE-системы имеют развитые средства документирования процесса разработки, автоматические генераторы отчетов позволяют подготовить отчет о текущем состоянии проекта с подробным описанием объектов БД и их отношений, что существенно облегчает ведение проекта.  В настоящий момент не существует единой общепринятой системы обозначений для ER – модели, и разные CASE-системы используют разные графические нотации, но разобравшись с одной, можно легко понять и другие. Как любая модель, модель «сущность—связь» имеет несколько базовых понятий, которые образуют исходные кирпичики, из которых строятся уже более сложные объекты по заранее определенным правилам.

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

Рассмотрим базовые понятия, лежащие  в основе ER-модели

1. Сущность, с помощью которой моделируется класс однотипных объектов. Сущность имеет имя, уникальное в пределах моделируемой системы. Так как сущность соответствует некоторому классу однотипных объектов, то предполагается, что в системе существует множество экземпляров данной сущности. Объект, которому соответствует понятие сущности, имеет свой набор атрибутов — характеристик, определяющих свойства данного представителя класса. При этом набор атрибутов должен быть таким, чтобы можно было различать конкретные экземпляры сущности.

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

Модель разрабатываемой БД представлена на рисунке 2.5.

 

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

3. Построение реляционной схемы из ER – модели данных

 

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

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

• Текстовый. Текст или числа, не требующие проведения расчётов.
• МЕМО.  Поле этого типа предназначено для хранения небольших текстовых данных (до 64000 символов). Поле этого типа не может быть ключевым или проиндексированным.
• Числовой.  Этот тип данных содержит множество подтипов. От выбора подтипа (размера) зависит точность вычислений.
• Счётчик.  Уникальные, последовательно возрастающие  числа, автоматически вводящиеся при добавлении новой записи в таблицу.
• Логический.  Логические значения, а так же поля, которые могут содержать одно из двух возможных значений.
• Денежный. Денежные значения и числовые данные, используемые в математических вычислениях.
• Дата/Время. Дата и время хранятся в специальном фиксированном формате.
• Поле объекта OLE. Включает звукозапись, рисунок и прочие типы данных. Поле этого типа не может быть ключевым или проиндексированным.
• Гиперсвязь.  Содержит адреса Web-страниц.

 

Поэтому далее необходимо определить состав  реляционной схемы базы данных из ER-модели. Для этой цели используются следующие правила:

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

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

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

• Если многие из объектов обладают рассматриваемым свойством, то его можно

хранить в базе данных так же, как  и обычное.

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

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

Если связь между объектами 1:1 и классы принадлежности обоих объектов являются обязательными, то для отображения  данных объектов и связей между ними можно:

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

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

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

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

Если между объектами предметной области имеется связь 1 : М и  оба класса принадлежности не обязательны, то поступают аналогично пункту 7 (создают  три таблицы: по одной для каждого  объекта и одну для связи между ними)

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

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

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

При отображении обобщенных объектов могут быть приняты разные решения:

• Всему обобщенному объекту может быть поставлена в соответствии одна таблица.
• Каждой из категорий ставится в соответствии отдельная таблица, которая

содержит в себе идентификатор  объекта, общие свойства и свойства данной категории.

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

При отображении составного объекта  так же возможны варианты: Если речь идет о составе изделий, то между изделием и деталью связь будет М:М.

В этом случае – см. пункты 7, 9, 10.

• Если речь идет о составе какой-нибудь организации, то между объектами скорее всего будет связь 1:М. В этом случае – см. пункты 8, 9.

 

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

 

Договор (Код договора, Дата подписания, Номер документа, Сумма договора, Код товара, Код валюты, Дата поставки, Фирма, Статус договора);

Товар (Код товара, Вид товара, Время записи);

Фирма (Код фирмы, Оргформа, Название, Адрес(Страна, Город, Улица, Дом), Телефон, Контактное лицо, Вид деятельности, Статус);

Документ (Код документа, Номер документа, Тип документа, Дата документа).

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

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

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

Тип поля – определяет тип данных, которые могут содержаться в данном поле.

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

Формат поля – определяет способ форматирования данных в ячейках, принадлежащих полю.

Маска ввода – определяет форму, в которой вводятся данные в поле (средство автоматизации ввода данных).

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

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

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

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

Обязательное поле – свойство, определяющее обязательность заполнения данного поля при наполнении базы.

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