55
объект или сохранить только объект категории. Это решение, принятое в
физической интерпретации, но оно не может быть сделано должным образом,
если информация отсутствует в то время.
Наконец, домены всех атрибутов должны быть определены, и должны
быть определены любые правила ограничения, управляющие этими доменами.
Информация о домене может быть определена как выполнение специальных
бизнес-правил в области бизнес-задач. Примерами этого являются правила
редактирования, допустимые значения для содержимого домена, допустимые
диапазоны для содержимого домена и алгоритмы выводимых данных для
содержимого домена. Однако они не являются специфичными для логической
модели, но имеют решающее значение для проверки того, что вся информация
об ограничениях домена была определена и что она не была ошибочно отнесена
к объектам как данным.
Наряду с логической моделью данных должна быть модель процесса того
же уровня спецификации. Он должен содержать информацию о процессах,
которые влияют на объекты в логической модели данных. Он может быть в
форме иерархически определенных диаграмм разложения или графически
изображенного процесса в подробном потоке данных.
Модель сущность-связь (модель ER) существует уже более 35 лет. Она
хорошо подходит для моделирования данных для использования с базами
данных, потому что она довольно абстрактна. ER модели легко переводятся в
отношения. ER-модели, также называемые ER-схемами, представлены ER-
диаграммами.
ER моделирование основано на двух концепциях:
Объекты, определенные как таблицы, которые содержат
конкретную информацию (данные)
Отношения, определяемые как ассоциации или взаимодействия
между сущностями.
56
Сущность - это объект в реальном мире с независимым существованием,
которое можно отличить от других объектов. Сущность может быть
Объект с физическим существованием (например, лектор, студент,
автомобиль)
Объект с концептуальным существованием (например, курс, работа,
должность)
Сущности могут быть классифицированы на основе их силы. Сущность
считается слабой, если она зависит от других сущностей, то есть она не может
существовать без отношений с другим объектом. Первичный ключ получен из
первичного ключа родительского объекта.
Сущность считается сильной, если она может существовать отдельно от
всех связанных с ней сущностей.
Другой термин, который нужно знать, - это тип объекта, который
определяет набор похожих объектов.
Набор сущностей - это совокупность сущностей типа сущности в
определенный момент времени. На диаграмме отношений сущностей (ERD)
тип сущности представлен именем в поле.
Существование сущности зависит от существования связанной сущности.
Она зависит от существования, если имеет обязательный внешний ключ (то
есть атрибут внешнего ключа, который не может быть нулевым).
Виды сущностей. Существуют различные виды сущностей, включая
независимые сущности, зависимые сущности и характерные сущности.
Независимые сущности. Независимые объекты, также называемые
ядрами, являются основой базы данных. Они - то, на чем основаны другие
таблицы. Ядра имеют следующие характеристики:
Они являются строительными блоками базы данных.
Первичный ключ может быть простым или составным.
Первичный ключ не является внешним ключом.
Они не зависят от другого существа для их существования.
57
Зависимые сущности, также называемые производными сущностями,
зависят от других таблиц по своему значению. Эти объекты имеют следующие
характеристики:
Зависимые объекты используются для соединения двух ядер.
Говорят, что они зависят от двух или более таблиц.
Отношения многие ко многим становятся ассоциативными
таблицами, по крайней мере, с двумя внешними ключами.
Они могут содержать другие атрибуты.
Внешний ключ идентифицирует каждую связанную таблицу.
Существует три варианта первичного ключа:
Использовать композицию внешних ключей связанных таблиц, если
они уникальны
Использовать комбинацию внешних ключей и уточняющий столбец
Создать новый простой первичный ключ
Характеристические сущности предоставляют больше информации о
другой таблице. Эти объекты имеют следующие характеристики:
Они представляют многозначные атрибуты.
Они описывают другие сущности.
Как правило, они имеют отношения один ко многим.
Внешний ключ используется для дальнейшей идентификации
характеризуемой таблицы.
Есть несколько типов атрибутов:
Простые атрибуты - это те, которые взяты из доменов атомарных
значений; они также называются однозначными атрибутами.
Составные атрибуты - это те, которые состоят из иерархии
атрибутов.
Многозначные атрибуты - это атрибуты, которые имеют набор
значений для каждого объекта.
58
Есть несколько типов ключей. Они описаны ниже.
Ключ-кандидат - это простой или составной ключ, который уникален и
минимален. Он уникален, потому что никакие две строки в таблице не могут
иметь одинаковое значение в любое время. Он минимален, потому что каждый
столбец необходим для достижения уникальности.
Составной ключ состоит из двух или более атрибутов, но он должен быть
минимальным.
Первичный ключ - это ключ-кандидат, который выбирается
разработчиком базы данных для использования в качестве механизма
идентификации для всего набора сущностей. Он должен однозначно
идентифицировать кортежи в таблице и не быть нулевым.
Вторичный ключ - это атрибут, используемый исключительно для
поисковых целей (может быть составным), например: Телефон и Фамилия.
Альтернативные ключи - это все ключи-кандидаты, не выбранные в
качестве первичного ключа.
Внешний ключ (FK) - это атрибут в таблице, который ссылается на
первичный ключ в другой таблице, ИЛИ он может быть нулевым. И внешние, и
первичные ключи должны быть одного типа данных.
Ноль (NULL) - это специальный символ, независимый от типа данных,
который означает либо неизвестный, либо неприменимый.
Исходя из выше сказанного была разработана инфологическая модель БД,
которая представлена на рисунке 3.1.
59
ОрганизаторТендера
#
o
o
o
o
o
o
o
кодОрганизатора
НазваниеОрганизатора
ПочтовыйАдрес
Отдел
КонтактноеЛицо
ТелефонОрг
ФаксОрг
emailОрг
...
Integer
Variable characters (255)
Variable characters (255)
Variable characters (100)
Variable characters (100)
Variable characters (50)
Variable characters (50)
Variable characters (50)
Заказчик
#
o
o
o
o
o
o
o
o
o
o
o
o
o
кодЗаказчика
НазваниеЗаказ
ИНН
КПП
ОКОНХ
ОГРН
РС
Банк
КС
БИК
Отдел
Контакт
телКонтакта
emailКонтакт
...
Integer
Variable characters (100)
Integer
Integer
Integer
Integer
Integer
Variable characters (255)
Integer
Variable characters (100)
Variable characters (255)
Variable characters (255)
Variable characters (100)
Variable characters (100)
ОбъектТ ендера
#
o
o
кодОбъекта
НазваниеОбъекта
Опис аниеОбъекта
...
Integer
Variable characters (255)
Text
Тендер
#
o
o
o
o
o
o
o
o
o
кодТендера
кодОрганизатора
кодЗаказчика
кодОбъекта
ДатаНачала
ДатаОкончания
ОбщаяСумма
УсловияПоставки
ОбщиеТребования
ТребованияСопровождения
...
Integer
Integer
Integer
Integer
Date
Date
Decimal (10,2)
Text
Text
Text
РольДоговоре
#
o
кодРоли
НазваниеРоли
Integer
Variable characters (100)
Договор
#
o
o
o
o
o
o
o
o
o
o
кодДоговора
кодРоли
кодЗаказчика
НаименованиеДог
Страна
ХарактерРаботы
Ос обыеУсловия
Стоимос ть
ДатаЗаключения
ДатаОкончания
СрокВыполнения
...
Integer
Integer
Integer
Variable characters (255)
Variable characters (100)
Variable characters (255)
Variable characters (255)
Decimal (10,2)
Date
Date
Integer
Рисунок 3.1 – ER-модель базы данных
Описание сущностей ER-модели представлено на рисунках 3.3-3.7.
Рисунок 3.2 - Описание атрибутов сущности Заказчик
60
Рисунок 3.3 - Описание атрибутов сущности Организатор тендера
Рисунок 3.4 - Описание атрибутов сущности Роль в договоре
Рисунок 3.5 - Описание атрибутов сущности Договор
Рисунок 3.6 - Описание атрибутов сущности Тендер
61
Рисунок 3.7 - Описание атрибутов сущности Объект тендера
Процесс проектирования базы данных включает в себя создание трех
типов схем - концептуальной, логической и физической. Структура базы
данных, документированная в этих схемах, преобразуется через язык
определения данных, который затем может быть использован для создания
базы данных. Полная атрибутивная модель (FA – fully attributed) данных
содержит подробные атрибуты (описания) для каждой сущности. Термин
«проектирование базы данных» может описывать множество различных частей
конструкции общей системы баз данных. В принципе и, что наиболее
правильно, это можно рассматривать как логическую структуру базовых
структур данных, используемых для хранения данных. В реляционной модели
это таблицы и представления. В базе данных объектов сущности и отношения
отображаются непосредственно в классы объектов и именованные отношения.
Однако термин «проектирование базы данных» также может использоваться
для применения к общему процессу проектирования, а не только к базовым
структурам данных, но также к формам и запросам, используемым как часть
общего приложения базы данных в системе управления базами данных или
СУБД.
Реализация физической модели данных требует понимания характеристик
и ограничений производительности используемой системы базы данных.
Довольно часто это реляционная база данных, и необходимо понимание, как
таблицы, столбцы, типы данных и связи между таблицами и столбцами
62
реализованы в конкретной системе управления реляционной базой данных.
Даже если это база данных другого типа (многомерная, столбчатая или какая-
либо другая частная база данных), необходимо понять особенности этой СУБД,
чтобы реализовать модель.
Проектирование физической модели данных требует глубоких знаний о
конкретной СУБД, используемой для того, чтобы:
Представлять логическую модель данных в схеме базы данных.
Добавлять сущности и определения атрибутов, необходимые для
удовлетворения эксплуатационных требований.
Конфигурировать и настраивать базу данных для требований к
производительности.
Характеристики физической модели данных включают в себя:
Специфичные для СУБД определения.
Определения таблиц, столбцов и других физических объектов в СУБД,
которые представляют объекты и атрибуты в логической модели данных.
Атрибуты столбцов, такие как типы данных, определяются и реализуются
по-разному в конкретных СУБД.
Правила ссылочной целостности, устанавливающие отношения между
таблицами и столбцами. Ссылочная целостность будет включать внешние
ключи, ограничения и триггеры, которые различаются в зависимости от
конкретной базы данных.
Объекты производительности и оптимизации, основанные на
определенных функциях СУБД, таких как индексы, триггеры, процедуры,
табличные пространства, разделы и материализованные представления.
Первоначальный дизайн основан на оценках объемов данных и частоты
обновления; эти физические объекты могут быть изменены в зависимости
от изменений, возникающих при развертывании и эксплуатации.
63
FK_ДОГОВОР_RELATIONS_РОЛЬДОГО
FK_ДОГОВОР_RELATIONS_ЗАКАЗЧИК
FK_ТЕНДЕР_RELATIONS_ОРГАНИЗА
FK_ТЕНДЕР_RELATIONS_ЗАКАЗЧИК
FK_ТЕНДЕР_RELATIONS_ОБЪЕКТТЕ
ОрганизаторТендера
кодОрганизатора
НазваниеОрганизатора
ПочтовыйАдрес
Отдел
КонтактноеЛицо
ТелефонОрг
ФаксОрг
emailОрг
...
int
varchar(255)
varchar(255)
varchar(100)
varchar(100)
varchar(50)
varchar(50)
varchar(50)
<pk>
Заказчик
кодЗаказчика
НазваниеЗаказ
ИНН
КПП
ОКОНХ
ОГРН
РС
Банк
КС
БИК
Отдел
Контакт
телКонтакта
emailКонтакт
...
int
varchar(100)
int
int
int
int
int
varchar(255)
int
varchar(100)
varchar(255)
varchar(255)
varchar(100)
varchar(100)
<pk>
ОбъектТендера
кодОбъекта
НазваниеОбъекта
Опис аниеОбъекта
...
int
varchar(255)
text
<pk>
Тендер
кодТендера
кодОрганизатора
кодЗаказчика
кодОбъекта
ДатаНачала
ДатаОкончания
ОбщаяСумма
УсловияПос тавки
ОбщиеТребования
ТребованияСопровождения
...
int
int
int
int
datetime
datetime
decimal(10,2)
text
text
text
<pk>
<fk1>
<fk2>
<fk3>
РольДоговоре
кодРоли
НазваниеРоли
int
varchar(100)
<pk>
Договор
кодДоговора
кодРоли
кодЗаказчика
НаименованиеДог
Страна
ХарактерРаботы
ОсобыеУсловия
Стоимость
ДатаЗаключения
ДатаОкончания
СрокВыполнения
...
int
int
int
varchar(255)
varchar(100)
varchar(255)
varchar(255)
decimal(10,2)
datetime
datetime
int
<pk>
<fk1>
<fk2>
Рисунок3.8 – Физическая модель данных
В результате сформирована трансформационная модель,
ориентированная на формат выбранной СУБД и включает все сущности,
атрибуты, их типы данных, ограничения контроля целостности и
согласованности (рисунок 3.8). Трансформационная модель в виде SQL скрипта
представлена в Приложении А.
3.2. Тестирование программного обеспечения
Тест-план приложения «Информационная система проведения и
архивации тендеров»
Целью настоящего тест плана является описание процесса тестирования
приложения «Информационная система проведения и архивации тендеров».
Данный документ позволяет получить представление о плановых работах,
сроках, а также кейсах и процессе тестирования.
Определения
Проект – Приложение «Информационная система проведения и
архивации тендеров» служит для автоматизации учет проведенных тендеров в
компании ООО «Контакт-Эксперт».
64
Тестирование – процесс исследования программного обеспечения с
целью получения информации о качестве продукта, направленный на
выявление дефектов и ошибок в программном продукте путем поиска
несоответствий между ожидаемым результатом и полученным.
Функциональное тестирование – тестирование функций приложения на
соответствие требованиям и выявление, решение возникающих ошибок.
ТЗ (Техническое задание) – документ, описывающий набор технических и
функциональных требований к программному продукту.
БД – База данных
Стресс-тестирование – оценка надежности и устойчивости системы в
условиях превышения пределов нормального функционирования. Тестовая
среда – набор программного обеспечения для воспроизведения действий
пользователя максимально приближенных к реальным.
Юзер стори – пошаговая инструкция, воспроизводящая действия
пользователя.
Целью тестирования Проекта является проверка всех его
функциональных возможностей и совместимости с различными
операционными системами, а также проведение серии стресс-тестов для
выявления узких мест и уязвимостей Проекта.
Тестирование предполагается вести в ручном режиме, без использования
автоматизированных систем.
Функциональное тестирование
Цель: Выявление функциональных ошибок, несоответствий ТЗ и
ожиданиям пользователя путем реализации стандартных.
Классификация функций:
Авторизация пользователя
Регистрация пользователя
Работа с формой Тендеров:
Работа кнопок меню Формы Тендеров