Рис. 2. Диаграмма декомпозиции «Авиационно

Оглавление
1
Введение .............................................................................................................................................. 2
2
Разработка системы с помощью BPwin ............................................................................................. 4
3
4
2.1
Контекстная диаграмма верхнего уровня ................................................................................. 4
2.2
Диаграмма декомпозиции «Государственная историко-культурная экспертиза» ............... 5
2.3
Диаграмма декомпозиции «Исполнение работы» .................................................................. 6
2.4
Диаграмма декомпозиции «Подготовительная работа» ........................................................ 6
2.5
Диаграмма декомпозиции «Проведение экспертизы» ............ Error! Bookmark not defined.
Разработка с помощью ERwin ............................................................................................................ 7
3.1
Диаграмма описаний сущностей ............................................................................................... 7
3.2
Диаграмма отношений между сущностями ............................................................................. 8
3.3
Диаграмма первичных ключей .................................................................................................. 8
3.4
Диаграмма всех атрибутов всех сущностей .............................................................................. 8
3.5
SQL запросы для создания таблиц ............................................................................................. 9
Разработка с помощью Rational Rose ..............................................................................................11
4.1
Диаграмма прецедентов ..........................................................................................................11
4.2
Потоки событий для прецедентов ...........................................................................................11
4.2.1
Поток событий для прецедента «Заказать экспертизу» ................................................11
4.2.2
Поток событий для прецедента «Назначить исполнителей» ........................................12
4.2.3
Поток событий для прецедента «Устранение замечаний при согласовании» ............12
4.3
Диаграмма последовательности для прецедента «Заказать экспертизу» ..........................13
4.4
Кооперативная диаграмма для прецедента «Заказ экспертизы» ........................................14
4.5
Диаграмма состояний для объекта «Контракт» .....................................................................14
4.6
Диаграмма классов ...................................................................................................................15
4.7
Диаграмма компонентов ..........................................................................................................16
4.8
Описание проектируемого пользовательского интерфейса и его функций ........................16
4.9
Схема базы данных ...................................................................................................................17
4.10
SLQ-запросы для создания таблиц...........................................................................................18
5
Заключение ........................................................................................................................................19
6
Список литературы ............................................................................................................................20
1
1 Введение
Примерный состав авиакомпании:







Коммерческий департамент;
Финансовый департамент;
Производственный департамент;
Летная служба;
Служба бортпроводников;
Авиационно техническая база;
Кадровая служба.
В данном курсовом проекте разрабатывается информационная модель авиационнотехнической базы, как отдела авиакомпании. Данный отдел обеспечивает исправность и
готовность парка самолетов, то есть в первую очередь проводит техническое обслуживание
самолетов. В ходе проектирования будут использованы такие средства, как BPwin, Erwin, Rational
Rose.
BPwin - инструмент для моделирования, анализа, документирования и оптимизации бизнеспроцессов. Используется для графического представления бизнес-процессов. Графически
представленная схема выполнения работ, обмена информацией, документооборота
визуализирует модель бизнес-процесса. Графическое изложение этой информации позволяет
перевести задачи управления организацией из области сложного ремесла в сферу инженерных
технологий. BPwin помогает четко документировать важные аспекты любых бизнес-процессов:
действия, которые необходимо предпринять, способы их осуществления и контроля,
требующиеся для этого ресурсы, а также визуализировать получаемые от этих действий
результаты. Он повышает бизнес-эффективность ИТ-решений, позволяя аналитикам и
проектировщикам моделей соотносить корпоративные инициативы и задачи с бизнестребованиями и процессами информационной архитектуры и проектирования приложений.
Таким образом, формируется целостная картина деятельности предприятия: от потоков работ в
небольших подразделениях до сложных организационных функций.
BPwin поддерживает сразу три стандартные нотации:
1. IDEF0 (функциональное моделирование);
2. DFD (моделирование потоков данных);
3. IDEF3 (моделирование потоков работ).
Эти три основных ракурса позволяют описывать предметную область более комплексно.
ERwin - CASE-средство для проектирования и документирования баз данных, которое позволяет
создавать, документировать и сопровождать базы данных, хранилища и витрины данных. Модели
данных помогают визуализировать структуру данных, обеспечивая эффективный процесс
организации, управления и администрирования таких аспектов деятельности предприятия, как
уровень сложности данных, технологий баз данных и среды развертывания. ERwin предназначен
для всех компаний, разрабатывающих и использующих базы данных, для администраторов баз
данных, системных аналитиков, проектировщиков баз данных, разработчиков, руководителей
проектов. Он позволяет управлять данными в процессе корпоративных изменений, а также в
условиях стремительно изменяющихся технологий. Так же позволяет наглядно отображать
2
сложные структуры данных. Это удобная в использовании графическая среда, она упрощает
разработку базы данных и автоматизирует множество трудоемких задач, уменьшая сроки
создания высококачественных и высокопроизводительных транзакционных баз данных и
хранилищ данных. Данное решение улучшает коммуникацию в вашей организации, обеспечивая
совместную работу администраторов и разработчиков баз данных, многократное использование
модели, а также наглядное представление комплексных активов данных в удобном для
понимания и обслуживания формате.
Rational Rose - средство визуального моделирования объектно-ориентированных
информационных систем компании Rational Software Corp. Работа продукта основана на
универсальном языке моделирования UML (Universal Modeling Language). Благодаря уникальному
языку моделирования Rational Rose способен решать практически любые задачи в
проектировании информационных систем: от анализа бизнес процессов до кодогенерации на
определенном языке программирования. Rational Rose позволяет разрабатывать как
высокоуровневые, так и низкоуровневые модели, осуществляя тем самым либо абстрактное
проектирование, либо логическое. Так же Rational Rose осуществляет такие подходы, как прямое и
обратное проектирование, а так же Round Trip Engineering. Такой арсенал позволит не только
проектировать новую систему, но и доработать старую, произведя процесс обратного
проектирования.
3
2 Разработка системы с помощью BPwin
2.1 Контекстная диаграмма верхнего уровня
Моделирование системы производится с точки зрения директора отдела. Контекстная диаграмма
типа IDEF0 самого верхнего уровня показана на рисунке 1.
USED AT:
AUTHOR: niki
DATE:
05.01.2012
WORKING
PROJECT: AviationTechnicalBase
REV:
07.01.2012
DRAFT
READER
DATE
CONTEXT:
TOP
RECOMMENDED
NOTES: 1 2 3 4 5 6 7 8 9 10
PUBLICATION
региональные,
технологии
национальные и
обслуживания
международные
авиационной
авиационные
промышл енности
власти
не об служенные самолеты
сведения о ресурсах и
отчетная д окумментация
наработке самолетов,
агрегатов и д еталей
Авиационно - Техническая База
обслуженные самолеты
обнаруженные неисправности
0
внешние
личный
состав
NODE:
TITLE:
финансирование
ремонтные
материал ьно -
организации
техническая база
Авиационно - Техническая База
NUMBER:
A-0
Рис. 1. Контекстная диаграмма верхнего уровня
На схеме видна главная цель отдела авиационно-технической базы – обслуживание самолетов.
Выполнение работ происходит в соответствии с региональными, национальными и
международными авиационными власти, а в приделах известных технологий обслуживания
авиационной промышленности.
Обслуживание производится согласно сведеньям о ресурсах и наработке самолетов, агрегатов и
деталей, а так же при выявленных поломках.
В результате выполнения работ самолетам предоставляется должное обслуживание.
Обслуживание может производиться так же и на внешних ремонтных организациях.
4
2.2 Диаграмма декомпозиции «Авиационно-Техническая База»
Работа, производимая на Авиационно-Технической Базе делиться на документирование и
собственно обслуживание, это продемонстрировано на следующей схеме:
USED AT:
AUTHOR: niki
DATE:
05.01.2012
WORKING
PROJECT: AviationTechnicalBase
REV:
07.01.2012
DRAFT
READER
DATE
CONTEXT:
RECOMMENDED
NOTES: 1 2 3 4 5 6 7 8 9 10
PUBLICATION
A-0
региональные,
технологии
национальные и
обслуживания
международные
авиационной
авиационные власти
промышл енности
отчетная
докумментация
сведения о ресурсах и
наработке самолетов,
производственно -
агрегатов и д еталей
диспетчерский
отдел
1
детали
подлежащие
тестированию,
ремонту или
замене
обнаруженные неисправности
обслуживание
обслуженные
самол еты
не об служенные самолеты
2
материал ьно личный состав
NODE:
TITLE:
финансирование
техническая база
Авиационно - Техническая База
внешние
ремонтные
организации
NUMBER:
A0
Рис. 2. Диаграмма декомпозиции «Авиационно-Техническая База»
Производственно-технический отдел занимается хранением документации, паспортов и т.п. на
каждый агрегат. Так же согласно этим документам контролирует эксплуатируемость различных
агрегатов. В случае необходимости на соответствующие отделы авиационной компании
сообщается о необходимости в замене, тестировании того или иного оборудования на самолете.
Отчетная документация, сформированная в результате обслуживания оборудования,
возвращается обратно в производственно-технический отдел на хранение, тем самым сохраняется
актуальная информация о нем.
5
2.3 Диаграмма декомпозиции «Обслуживание»
Обслуживание заключается в последовательном осмотре, тестировании и ремонте оборудования:
USED AT:
AUTHOR: niki
DATE:
05.01.2012
WORKING
PROJECT: AviationTechnicalBase
REV:
07.01.2012
DRAFT
READER
DATE
CONTEXT:
RECOMMENDED
NOTES: 1 2 3 4 5 6 7 8 9 10
PUBLICATION
A0
региональные,
технологии
национальные и
обслуживания
международные
авиационной
авиационные
промышл енности
власти
детали
подлежащие
тестированию,
ремонту или
отчетная
замене
докумментация
обнаруженные
осмотр
неисправности
не
1
обслуженные
на
самол еты
обслуженные
тестирование
самол еты
тестирование
на ремонт
2
ремонт и
устранение
замечаний
3
личный
материал ьно -
состав
внешние
техническая
NODE:
TITLE:
ремонтные
база
финансирование
обслуживание
организации
NUMBER:
A2
Рис. 3. Диаграмма декомпозиции «Обслуживание»
На этапе осмотра формируется информация о деталях нуждающихся либо сразу в ремонте, либо о
подозрительных элементах, нуждающихся в дальнейшем тестировании на неисправность.
Тестирование выявляет дефекты в оборудовании. Если такие находятся, то они отправляются
прямиком на ремонт.
Ремонт может проходить и на внешних ремонтных организациях. Но в любом случае на этом
этапе формируется отчетная документация о проделанной работе.
Самолеты прошедшие весь комплекс мероприятий считаются обслуженными.
6
3 Разработка с помощью ERwin
3.1 Диаграмма описаний сущностей
Диаграмма описаний сущностей выглядит следующим образом (рис. 6):
детали_самолетов
Детали из которых
состоит самолет.
самолет
деталь
Тип самолета
Детали из которых
ав иакомпании.
состоят самолеты.
св едения
Св едения о ресу рсах
и наработке
самолетов ,
агрегатов и деталей.
Рис. 6. Диаграмма описаний сущностей
На данной схеме имеется четыре сущности:




самолет – представитель парка самолетов авиакомпании
деталь – агрегаты, оборудования и детали самолета
сведения – сведения необходимые для проведения обслуживания
детали_самолетов – вспомогательная сущность, получившаяся в результате
преобразования связи «многие-ко-многим».
7
3.2 Диаграмма отношений между сущностями
Диаграмма отношений между сущностями представлена на рис. 7:
D:R
D:R
U:R
детали_самолетов
состоит_из
U:R
принадлежит
I:R
I:R
U:R
U:R
самолет
деталь
D:R
D:R
U:R
U:R
I:R
I:R
U:R
_имеет /
_имеються_на
св едения
Z
U:R
имеет /
Z
имеются_на
Рис. 7. Диаграмма отношений между сущностями
3.3 Диаграмма первичных ключей
Диаграмма первичных ключей выглядит следующим образом (рис. 8):
детали_самолетов
состоит_из
id_plane (FK)
принадлежит
id_detail (FK)
самолет
деталь
id_plane
id_detail
_имеет /
_имеються_на
св едения
id_plane (FK)
имеет /
имеются_на
id_detail (FK)
Рис. 8. Диаграмма первичных ключей
3.4 Диаграмма всех атрибутов всех сущностей
Диаграмма всех атрибутов всех сущностей представлена на рис. 9:
8
Рис. 9. Диаграмма всех атрибутов всех сущностей
3.5 SQL запросы для создания таблиц
Данный SQL код был сгенерирован в результате прямого проектирования:
CREATE TABLE FulfillOrder
(
ExpertCode SMALLINT NOT NULL,
OrderCode SMALLINT NOT NULL,
code_work INTEGER NULL
);
ALTER TABLE FulfillOrder
ADD PRIMARY KEY (code_work);
CREATE UNIQUE INDEX XAK1FulfillOrder ON FulfillOrder
(
ExpertCode,
OrderCode
);
CREATE TABLE Order
(
WhoCustomer SMALLINT NOT NULL,
OrderType VARCHAR(20) NULL,
OrderDescription BLOB NULL,
DateOrdered DATE NULL,
OrderCode SMALLINT NULL
);
ALTER TABLE Order
ADD PRIMARY KEY (OrderCode);
CREATE TABLE Customer
(
CustomerCode SMALLINT NULL,
CustomerName VARCHAR(20) NULL,
Telephone VARCHAR(20) NULL
);
ALTER TABLE Customer
ADD PRIMARY KEY (CustomerCode);
CREATE UNIQUE INDEX XAK1Customer ON Customer
(
CustomerName
9
);
CREATE INDEX XIE1Customer ON Customer
(
CustomerName,
Telephone
);
CREATE TABLE Expert
(
ExpertCode SMALLINT NULL,
FULLNAME VARCHAR(20) NULL,
Telephone VARCHAR(20) NULL,
LicenseNumber SMALLINT NULL
);
ALTER TABLE Expert
ADD PRIMARY KEY (ExpertCode);
CREATE UNIQUE INDEX XAK1Expert ON Expert
(
FULLNAME
);
CREATE INDEX XIE1Expert ON Expert
(
FULLNAME,
Telephone
);
ALTER TABLE FulfillOrder
ADD FOREIGN KEY performed_by (OrderCode) REFERENCES Order(OrderCode);
ALTER TABLE FulfillOrder
ADD FOREIGN KEY perform (ExpertCode) REFERENCES Expert(ExpertCode);
ALTER TABLE Order
ADD FOREIGN KEY R_2 (WhoCustomer) REFERENCES Customer(CustomerCode);
10
4 Разработка с помощью Rational Rose
4.1 Диаграмма прецедентов
Диаграмма прецедентов для разрабатываемой системы представлена на рисунке 10.
Рис. 10. Диаграмма прецедентов
Заказчик в виде физического или юридического лица может взаимодействовать с
разрабатываемой моделью посредством вызова прецедента «Заказать экспертизу».
При выполнении этой работы автоматически выполняется работа «Назначить исполнителей». На
схеме она связана с основной работой стрелкой включения.
Данная работа также может быть модифицирована до работы «Устранение замечаний при
согласовании». Она выполняется, если заказчик уже заказывал экспертизу, но она не прошла
согласование.
И физическое и юридическое лицо в общем случае являются заказчиком, что показано на схеме
стрелками генерализации.
4.2 Потоки событий для прецедентов
4.2.1
Поток событий для прецедента «Заказать экспертизу»
Краткое описание:
Вариант использования "Заказать экспертизу" позволяет заказчику (физическому или
юридическому лицу) заказать проведение горударственной историко-культурной экспертизы.
Предусловия:
Заказчик должен иметь все необходимые документы, которые потребуются при проведении
экспертизы. Исполнитель должен иметь в штате требуемое количество аттестованных экспертов
Основной поток:
- Прецедент начинается, когда заказчик приходит в офис архитектурной мастерской
- Проводятся начальные переговоры. Заказчик излагает свою проблему (необходимость
выполнения историко-культурной экспертизы)
11
- Исполнитель подтверждает свою возможность выполнить работу (сообзает о наличии
требуемого количества аттестованных экспертов)
- Назначается дата новых переговоров, до проведения которых, имполнитель проводит первичное
изучение обьекта и определяет трудоемкость работы, её стоимость и сроки.
- На новых переговорах исполнитель предлагает стоимость и сроки выполнения работы. Если
заказчик не согласен по выполняется альтернативный поток А1
- Подписание контракта
Альтернативный поток А1 - заказчик не доволен условиями предложенными
исполнителем
- Заказчик предлагает свои условия. Если исполнитель не согласен, то работа не выполняется
- Если исполнитель согласен, то контракт заключается на измененных условиях.
Постусловия
Заказчик должен составить техническое задание и подписать его вместе с исполнителем.
4.2.2
Поток событий для прецедента «Назначить исполнителей»
Краткое описание:
Из экспертов работающих в штате исполнителя формируется экспертная комиссия. Назначается
председатель и ответственный секретарь. Распределяются работы между членами комиссии.
Предусловия:
Все эксперты должны быть соответствующим образом аттестованы.
Основной поток:
- Определяется состав экспертной комиссии
- Выбирается председатель и секретарь
- распределяются работы между исполнителями
- составляется протокол, график выполнения работы
- определяется состав привлекаемых специалистов
4.2.3
Поток событий для прецедента «Устранение замечаний при согласовании»
Краткое описание:
Устранение исполнителем замечаний, полученных в процессе согласования историко-культурной
экспертизы в гос. органе охраны культурного наследия.
Предусловия:
Заказчик должен иметь официальный список замечаний к историко-культурной экспертизе,
выданный гос. органом охраны культурного наследия.
Основной поток:
- заказчик передает список с замечаниями исполнителю
- исполнитель проводит заседание экспертной комиссии на котором рассматривается список.
- между экспертами распределяются работы по устранению замечаний
- эксперты посещают гос. орган по охране культ. наследия для обсуждения замечаний
- исполнитель вносит изменения в акт и приложения в соответствии с замечаниями
- исполнитель передает заказчику исправленную историко-культурную экспертизу (акт и
приложения) для повторной подачи на согласование в гос. орган охраны культ. наследия.
12
4.3 Диаграмма последовательности для прецедента «Заказать
экспертизу»
Последовательность действий выполняемых при выполнении работы по заказу экспертизы
выглядит следующим образом (рис.11):
Рис. 11. Диаграмма последовательности прецедента «Заказать экспертизу»
Пояснения:
Задача в данном случае – это текст технического задания с прилагаемыми к нему документами.
Во время выполнения этапа «Изучение задания» определяются сроки и стоимость выполнения
работы, которые в дальнейшем сообщаются заказчику на этапе переговоров. Если заказчик
согласен с условиями выполнения работы то он, вместе и исполнителем, подписывает контракт.
13
4.4 Кооперативная диаграмма для прецедента «Заказ экспертизы»
Кооперативная диаграмма для прецедента «Заказ экспертизы» представлена на рисунке 12.
Рис. 12. Кооперативная диаграмма для прецедента «Заказ экспертизы»
Данная схема аналогична предыдущей, однако, на ней лучше видны связи между различными
объектами.
4.5 Диаграмма состояний для объекта «Контракт»
Диаграмма состояний для объекта «Контракт» представлена на рисунке 13.
Рис. 13. Диаграмма состояний для объекта «Контракт».
Текст контракта обсуждается, пока обе стороны не придут к согласию относительно условий
выполнения работы.
Контракт завершает свое существование после выполнения исполнителем работы и выплаты
заказчиком остатка оговоренной суммы.
14
4.6 Диаграмма классов
Диаграмма классов для разрабатываемой модели представлена на рисунке 14.
Рис. 14. Диаграмма классов
Примечания:
Поле «лицензия» в сущности «исполнитель» - это уникальный номер документа, который эксперт
получает после аттестации в органе охраны.
В данной модели задачу может создавать только заказчик, а контракт – только исполнитель.
Поле «Текст задания» в сущности, исполнитель – это сокращенный вариант текста который
находится в техническом задании для данной работы.
Выполнение задание сможет начаться только после подписания контракта обеими сторономи, то
есть в обоих полях «Подпись заказчика» и «Подпись исполнителя» сущности «Контракт» должны
стоять значения TRUE.
Первичным ключом сущности «Контракт» является поле «Номер контракта», а сущности «Задача»
- поле «Номер задачи».
Как видно из схемы каждый контракт и каждая задача должны иметь одного заказчика и одного
исполнителя.
15
4.7 Диаграмма компонентов
Диаграмма компонентов состоит из единственного элемента – основной программы. Её схема
представлена на рисунке 15.
Рис. 15. Диаграмма компонентов
4.8 Описание проектируемого пользовательского интерфейса и его
функций
Интерфейс программы состоит из двух окон: окна «Заказчик» (рис. 16) и «Исполнитель» (рис. 17).
Рис. 16. Форма «Заказчик»
Рис. 17. Форма «Исполнитель»
16
Данная программа позволяет наладить взаимодействие между заказчиком и исполнителем.
Обычная последовательность действий при использовании программы такова:
1. Заказчик пишет текст задание в поле «Текст задания» и нажимает кнопку «Создать»
2. Исполнитель, ознакомившись с заданием, пишет условия работы в специально
предназначенном для этого поле и нажимает кнопку «отправить»
3. Заказчик ознакамливается с условиями работы и нажимает на кнопку ОК, если он согласен
и «отмена» если нет. Если заказчик не согласен с условиями, то исполнитель должен
изменить их и снова нажать на кнопку «отправить». Так происходит пока стороны не
придут к согласию.
4. После того как заказчик согласился с условиями выполнения работы, исполнителю
становится доступна кнопка «Создать и подписать контракт», при нажатии которой
создается новый контракт, заполняется необходимыми данными, подписывается со
стороны исполнителя и его номер отправляется заказчику.
5. Заказчик, получив сообщение о том, что контракт создан, нажимает на кнопку
«подписать». При этом контракт подписывается со стороны заказчика и работа программы
завершается.
4.9 Схема базы данных
Данная схема получилась в результате прямого проектирования (рис. 18):
Рис. 18. Схема базы данных.
17
4.10 SLQ-запросы для создания таблиц
Данный код был получен в результате прямого проектирования:
ALTER TABLE "S_8"."T_Заказчик" DROP CONSTRAINT "FK_T_Заказчик20";
ALTER TABLE "S_8"."T_Контракт" DROP CONSTRAINT "FK_T_Контракт18";
ALTER TABLE "S_8"."T_Контракт" DROP CONSTRAINT "FK_T_Контракт24";
ALTER TABLE "S_8"."T_Задача" DROP CONSTRAINT "FK_T_Задача22";
ALTER TABLE "S_8"."T_Задача" DROP CONSTRAINT "FK_T_Задача23";
DROP TABLE "S_8"."T_Заказчик";
DROP TABLE "S_8"."T_Контракт";
DROP TABLE "S_8"."T_Задача";
DROP TABLE "S_8"."T_Исполнитель";
CREATE TABLE "S_8"."T_Заказчик" (
"Заказчик_название" VARCHAR ( 255 ) NOT NULL,
"Адрес" VARCHAR ( 255 ) NOT NULL,
"Номер_контракта" INTEGER,
CONSTRAINT "PK_T_Заказчик11" PRIMARY KEY ("Заказчик_название")
);
CREATE TABLE "S_8"."T_Контракт" (
"Номер_контракта" INTEGER NOT NULL,
"Заказчик" VARCHAR ( 255 ) NOT NULL,
"Исполнитель" VARCHAR ( 255 ) NOT NULL,
"Текст_задания" VARCHAR ( 255 ) NOT NULL,
"Дата_создания" DATE NOT NULL,
"Подпись_заказчика" SMALLINT NOT NULL,
"Подпись_исполнителя" SMALLINT NOT NULL,
"Исполнитель_название" VARCHAR ( 255 ) NOT NULL,
"Заказчик_название" VARCHAR ( 255 ) NOT NULL,
CONSTRAINT "PK_T_Контракт10" PRIMARY KEY ("Номер_контракта")
);
CREATE TABLE "S_8"."T_Задача" (
"Номер_задачи" INTEGER NOT NULL,
"Техническое_задание" VARCHAR ( 255 ) NOT NULL,
"Заказчик" VARCHAR ( 255 ) NOT NULL,
"Исполнитель_название" VARCHAR ( 255 ) NOT NULL,
"Заказчик_название" VARCHAR ( 255 ) NOT NULL,
CONSTRAINT "PK_T_Задача8" PRIMARY KEY ("Номер_задачи", "Заказчик_название",
"Исполнитель_название")
);
CREATE TABLE "S_8"."T_Исполнитель" (
"Исполнитель_название" VARCHAR ( 255 ) NOT NULL,
"Адрес" VARCHAR ( 255 ) NOT NULL,
"Лицензия" VARCHAR ( 255 ) NOT NULL,
CONSTRAINT "PK_T_Исполнитель9" PRIMARY KEY ("Исполнитель_название")
);
CREATE INDEX "S_8"."TC_T_Заказчик41" ON "S_8"."T_Заказчик" ("Номер_контракта");
CREATE INDEX "S_8"."TC_T_Задача47" ON "S_8"."T_Задача" ("Исполнитель_название");
CREATE INDEX "S_8"."TC_T_Задача46" ON "S_8"."T_Задача" ("Заказчик_название");
ALTER TABLE "S_8"."T_Заказчик" ADD CONSTRAINT "FK_T_Заказчик20" FOREIGN KEY
("Номер_контракта") REFERENCES "S_8"."T_Контракт" ("Номер_контракта") ON DELETE NO
ACTION ON UPDATE NO ACTION;
ALTER TABLE "S_8"."T_Контракт" ADD CONSTRAINT "FK_T_Контракт18" FOREIGN KEY
("Исполнитель_название") REFERENCES "S_8"."T_Исполнитель" ("Исполнитель_название") ON
DELETE NO ACTION ON UPDATE NO ACTION;
ALTER TABLE "S_8"."T_Задача" ADD CONSTRAINT "FK_T_Задача22" FOREIGN KEY
("Заказчик_название") REFERENCES "S_8"."T_Заказчик" ("Заказчик_название") ON DELETE
NO ACTION ON UPDATE NO ACTION;
ALTER TABLE "S_8"."T_Задача" ADD CONSTRAINT "FK_T_Задача23" FOREIGN KEY
("Исполнитель_название") REFERENCES "S_8"."T_Исполнитель" ("Исполнитель_название") ON
DELETE NO ACTION ON UPDATE NO ACTION;
Стоит отметить, что данный код можно использовать для создания таблиц, только после внесения
определенных изменений, в частности необходимо избавиться от текста написанного
кириллицей, заменив его словами, написанными латинскими буквами, и добавить код для
создания непосредственно базы данных, в которой будут находиться данные таблицы.
18
5 Заключение
В результате выполнения данного курсового проекта была разработана информационная система
для фирмы, занимающейся проведением государственных историко-культурных экспертиз. С
помощью этой системы можно повысить производительность работы, и автоматизировать
функции, которые до этого приходилось выполнять в ручную.
Средства автоматизированного проектирования оказались чрезвычайно полезными в этой работе,
так как помогли упростить разработку и создание всей системы, значительно сократив время,
которое потребовалось на выполнение этой работы, если бы мы не использовали данные
системы.
19
6 Список литературы
1) Маклаков С. В. «Создание информационных систем с AllFusion Modelling Suite» – Москва,
«Диалог МИФИ», 2005. – 432 с.
2) Трофимов С.А. CASE – технологии: практическая работа в Rational Rose – М.: ЗАО
«Издательство БИНОМ», 2001. – 272 с.
20