CC BY
94
УДК 004.04
ОПЫТ ОБЪЕКТНОГО ПРОЕКТИРОВАНИЯ СТРУКТУРЫ БАЗЫ ДАННЫХ ИНФОРМАЦИОННОЙ СИСТЕМЫ РЕКЛАМНО-ИЗДАТЕЛЬСКОГО ЦЕНТРА
Герасимова Ольга Игоревна, Шахтинский институт (филиал) Южно-Российского государственного технического университета (Новочеркасского политехнического института), Россия,
Шахты, itblack@rambler.ru
Олейник Павел Петрович, к.т.н., Системный архитектор программного обеспечения,
ОАО «Астон», Россия, Ростов-на-Дону, xsl@list.ru
В статье рассматривается процесс проектирования и реализации структуры БД для информационной системы рекламно-издательского цента с подробным описанием ключевых этапов (концептуального и логического проектирования). Актуальность работы обуславливается тем, что в настоящее время все большее количество организаций переходит от ведения учета на бумажных носителях к использованию единых информационных систем (ИС). Корректно спроектированная и реализованная ИС позволяет сделать процесс учета более быстрым и удобным, одновременно способствуя повышению конкурентоспособности организации на рынке.
Проектирование структуры базы данных (БД) - одна из наиболее ответственных фаз реализации программного обеспечения, успех которой во многом зависит от выбранной методологии. В данной работе использована методология сущность-связь, подробно описанная в [1-2]. Этап проектирования БД начинается с установления границ будущей разрабатываемой системы и определения функционала, который необходимо реализовать в приложении. Концептуальное проектирование БД позволяет описать высокоуровневую модель и начинается с создания концептуальной модели данных организации, полностью независимой от любых деталей реализации. К последним относятся выбранный тип СУБД, состав программ приложения, используемый язык программирования, конкретная аппаратная платформа, вопросы производительности и любые другие физические особенности реализации.
Следующим этапом является логическое проектирование БД, под которым понимается конструирование информационной модели предприятия на основе существующих конкретных моделей данных, но без учёта специфики используемой СУБД и прочих условий реализации [1].
В общем случае, логическое проектирование БД заключается в преобразовании концептуальной модели данных в логическую модель данных предприятия с учетом выбранного типа СУБД. Логическая модель данных является источником информации для этапа физического проектирования. Она предоставляет разработчику физической модели данных средства проведения всестороннего анализа различных аспектов работы с данными, что имеет важное значение для выбора эффективного проектного решения.
Последним этапом является физическое проектирование БД, под которым понимается описание конкретной реализации БД, размещаемой во внешней памяти. Физический проект реализует базовые отношения, определяет организацию файлов и состав индексов, применяемых для обеспечения эффективного доступа к данным, а также регламентирует все соответствующие ограничения целостности и меры защиты [1].
Физическое проектирование БД предусматривает принятие разработчиком окончательного решения о способах реализации создаваемой базы. Поэтому физическое проектирование должно производиться с учетом всех особенностей используемой СУБД. Т.к. объектно-ориентированный подход является одним из часто используемых, применяемых при разработке программного обеспечения, то принято решение использовать именно объектно-ориентированную систему управления базами данных, допускающую создание новых типов данных на основе существующих, поддерживающую продолжительные транзакции и наследование, что способствует ускорению разработки и
60
упрощению сопровождения БД. Между этапами физического и логического проектирования всегда имеется определенная обратная связь, поскольку решения, принятые на этапе физического проектирования с целью повышения производительности разрабатываемой системы могут потребовать определенной корректировки логической модели данных.
В ходе анализа предметной области было выявлено, что необходимо разработать структуру БД, позволяющую сохранять следующую информацию:
• о сотрудниках организации;
• об отделах, в которых работают сотрудники;
• о клиентах, с которыми работает организация;
• о заявках на оказание услуг, подаваемых клиентами;
• о статусе обработки заявки;
• об оказываемой услуге;
• об истории изменения цен на услуги;
• об информационных партнерах, у которых размещается рекламная продукция;
• о заключенных контрактах и конкретных услугах, предоставляемых в его рамках;
• об уже выполненных контрактах и конкретных услугах, предоставленных в рамках
контракта.
LT11 (R)
1Т10(1) 1Т7(1) lT9(R)lT8(R)
Includeln
1..1
Contract
ft~11(R) l^. |T10(I)
Contractltem
ContractName ContractDate ContractDescription
Service
ServiceName ServiceDescription
0..’
Has
1..1
|T8(I)
Contract tem Price
WillBe
1-1 0..
1..1
1..1
InformationPartner
InformationPartnerName
Address
fT5(l)
o..*
Describe
Price
DateStart
DateFinish
Value
[19(1)
>г' 1 1 W 0..1 ExecuteWork Assigned € ПгНо r\ i
/ T10(R) / W OrderDate OrderPrice OrderDescription
ExecuteWorkDate Execute WorkDescription О ' * О о
0..* Inplacedln ^T11(R) 1..1 |T10(R) o4T9(R) o..* iT9(R)
Worker
i..i
WorkerName
Post
Address
Client
For
ClientName ClientDescription Address
o.
jT2( <
LT2(R)
1..1
LTi(i)
OrganizationType
Works In
1..
Tt6(I)
InformationPartnerType Department
InformationPartnerTypeName DepartmentName
T6(R)
1..1
Have
1..*
MustHave
OrganizationTypeName jJ2(l)
1..1
Contacted By
T3(l)
T3(l)
1..
Telephone
TelephoneName Number
T1. Добавление нового типа организации (клиента)
Т2. Добавление нового клиента ТЗ. Добавление нового отдела рекламного агентства Т4. Добавление нового типа информационного партнёра Т5. Добавление нового информационного партнёра Тб. Добавление нового работника организации
Рис. 1 - Карта выполнения транзакций
Т5(1)
Т7. Добавление новой услуги
Т8. Ввод цены на предоставляемую услугу
T9. Регистрация заявки клиента
Т10. Оформление нового контракта на услуги
Т11. Занесение информации о выполненной услуги
На этапе концептуального проектирования информационной модели предприятия, независящей от каких-либо физических условий реализации, необходимо определить типы сущностей, т.е. объекты, информация о которых будет сохраняться в БД.
Список типов сущностей предметной области:
• Service - услуга, оказываемая клиентам;
• Price - история изменения цен на услуги;
• Client - клиент, подающий заявку на оказание услуг;
61
• OrganizationType - тип организации клиента (ООО, ОАО и тп)
• Worker - сотрудник организации, оказывающий услуги и регистрирующий заявки;
• Department - отдел, в котором работает сотрудник;
• Telephon - контактный телефон;
• Contract - договор об оказании услуг клиенту;
• ContractItem - строка контракта, в которой указана оказываемая в рамках контракта услуга;
• ExecuteWork - выполненная услуга, входящая в контракт;
• InformationPartner - средство массовой информации, выступающее в качестве информационного партнёра;
• InformationPartnerType - тип информационного партнёра (газета, журнал и т.п.).
Дальнейшим этапом является выделение всех связей, имеющихся между сущностями.
Все выделенные связи наглядно представлены на рисунке 1, на котором также изображены все основные атрибуты, определённые для сущностей и связей.
Для графического представления сущностей и связей создаваемой БД (см. рис.1) разработана ER-диаграмма предметной области, для отображения которой использована нотация унифицированного языка моделирования UML [3]. После того, как построена концептуальная модель БД, необходимо проверить ее на достоверность с помощью определения соответствия транзакциям пользователя. Проверим выполнимость транзакций (T1..T11) при помощи графического представления путей её реализации (карты транзакций), изображённой на рис. 1.
Для каждой транзакции в круглых скобках указаны операции, выполняемые транзакцией над данной сущностью: I (Insert) - вставка нового экземпляра сущности, U (Update) - обновление значений атрибутов, R (Read) - чтение значений атрибутов, D (Delete) - удаление сущности из БД.
Рис.2 - Логическая модель
Из рис.1 следует, что все описанные ранее транзакции выполнимы, следовательно, концептуальное проектирование структуры БД выполнено верно и можно приступать к логическому проектированию.
Следующим этапом является логическое проектирование БД, которое в общем случае заключается в преобразовании концептуальной модели данных в логическую модель данных предприятия с учетом выбранного типа СУБД (в нашем случае в понятия объектной СУБД, т.е. в логическую объектно-ориентированную). Так как при проектировании системы
62
используются методы объектно-реляционного отображения, то этап логического проектирования выполняется в понятиях объектной модели данных. Поэтом при преобразовании концептуальной модели в логическую необходимо выполнить следующие операции:
1. Выполнить обобщение/специализацию.
2. Преобразовать связи с атрибутами в отдельные классы.
3. Преобразовать сложные связи в отдельные классы.
Результат проделанных операций представлен на рис. 2.
Для тестирования корректности спроектированной БД реализуем графическое приложение, заполним созданную БД тестовой информацией и проверим разработанное приложение. На рис. 3 приведена экранная форма, иллюстрирующая работу созданного приложения.
Рис. 3 - Диалоговое окно разработанного приложения
Резюмируя вышесказанное, можно сделать вывод, что разработанное приложение полностью удовлетворяет описанным требованиям и позволяет сохранять всю необходимую информацию. В настоящее время выполняется внедрение системы и его отладка в конкретной организации.
На некоторых предприятиях учет оказанных услуг ведется вручную, тогда как внедрение созданной ИС позволит усовершенствовать этот процесс и сделать его намного более быстрым и удобным. Также внедрение поспособствует повышению конкурентоспособности предприятия на рынке, так как в настоящее время множество предприятий уже перешло от ведения учета вручную к использованию ИС и, чтобы не потерять свое место на рынке, необходимо следить за развитием информационных технологий. В статье представлено практическое применение методологии «сущность-связь», что продемонстрировано созданием концептуальной, логической моделей структуры БД.
63
Литература
1. Коннолли, Томас, Бегг, Каролин. Базы данных. Проектирование, реализация и сопровождение. Теория и практика. 3-е издание. : Пер. с англ. - М. : Издательский дом "Вильямс", 2003. - 1440 с. : ил. - Парал. тит. англ.
2. Дейт К. Дж., Введение в системы баз данных, 7-е издание. : Пер. с англ. - М. : Издательский дом «Вильямс», 2001. - 1072 с. : ил. - Парал. тит. англ.
3. Мюллер Р. Дж., Базы данных и UML проектирование: Пер. с англ. - М. : Лори, 2002. - 420с.: ил. - Парал. тит. англ.
УДК 004.43:378.09
ПОЛИМОРФИЗМ И ИСПОЛЬЗОВАНИЕ ВИРТУАЛЬНЫХ ФУНКЦИЙ
Мясникова Нелли Александровна, доцент, Южно-Российский государственный технический университет (Новочеркасский политехнический институт), Россия, Новочеркасск, mnela@list.ru Шепилов Владислав Александрович, студент, Южно-Российский государственный технический университет (Новочеркасский политехнический институт), Россия, Новочеркасск, ship3000@mail.ru
Для построения иерархий классов в любом языке программирования высокого уровня должен быть реализован механизм полиморфизма, который обеспечивает возможность определения разнообразных аспектов некоторого единого метода по названию для классов разных уровней иерархии. Также различают простой полиморфизм, который базируется на механизме раннего связывания, и сложный полиморфизм, который использует механизм позднего связывания.
Простой (еще называют статический) полиморфизм поддерживается языком C++ на этапе компиляции (так называемое раннее связывание) и реализуется с помощью механизма переопределения функций. Такие полиморфные функции в C++ называют переопределяемыми, в соответствии с общими правилами, они могут отличаться типом возвращаемого параметра и сигнатурой.
Такой подход позволяет строить более гибкие и совершенные иерархии классов, заменяя в производных классах методы. Чтобы показать использование статического полиморфного метода рассмотрим пример 1. В нем функция print() является статическим полиморфным методом. Функция show(), вызывает метод print() и наследуется в производных классах.
Пример 1. Использование раннего связывания
#include < iostream. h>
#include <conio.h> class A {
int a; public: void show()
{
cout<<"Содержимое полей объекта"<<endl;
print ();
} //вызов статической полиморфной функции void print(void)
// первый аспект статической полиморфной функции {
cout<<a<<endl;
}
A(int v):a(v){}
};
class В: public А
64
