- •Р.А. Файзрахманов, А.В. Архипов
- •ПРОЕКТИРОВАНИЕ АВТОМАТИЗИРОВАННЫХ ИНФОРМАЦИОННЫХ СИСТЕМ НА ОСНОВЕ ОБЪЕКТНО ОРИЕНТИРОВАННОГО ПОДХОДА
- •4.3. Подведение итогов
- •4.4. Контрольные вопросы
- •4.5. Контрольные задачи и упражнения
- •5. ДИАГРАММА КЛАССОВ
- •5.1. Теоретическая часть
- •5.2. Реализация в Rational Rose
- •5.5. Контрольные задачи и упражнения
- •6.1. Теоретическая часть
- •6.2. Реализация в Rational Rose
- •6.3. Подведение итогов
- •6.4. Контрольные вопросы
- •6.5. Контрольная задача
- •7. ДИАГРАММА ПОСЛЕДОВАТЕЛЬНОСТЕЙ
- •7.1. Теоретическая часть
- •7.2. Реализация в Rational Rose
- •7.3. Подведение итогов
- •7.4. Контрольные вопросы
- •7.5. Контрольные задачи
- •8. ДИАГРАММА СОТРУДНИЧЕСТВА
- •8.1. Теоретическая часть
- •8.2. Реализация в Rational Rose
- •8.5. Контрольные задачи
- •9. ДИАГРАММА СОСТОЯНИЙ
- •9.1. Теоретическая часть
- •9.3. Подведение итогов
- •9.4. Контрольные вопросы
- •9.5. Контрольные задачи
- •10. ДИАГРАММА ДЕЯТЕЛЬНОСТЕЙ
- •10.1. Теоретическая часть
- •10.3. Подведение итогов
- •10.4. Контрольные вопросы
- •11. ДИАГРАММА КОМПОНЕНТОВ
- •11.1. Теоретическая часть
- •11.4. Контрольные вопросы
- •11.5. Контрольные задачи
- •12.3. Подведение итогов
- •12.4. Контрольные вопросы
- •12.5. Контрольная задача
- •13. ГЕНЕРАЦИЯ КОДА
- •13.1. Алгоритм получения исходного кода C++
- •13.2. Задания для самостоятельного выполнения
- •ЗАКЛЮЧЕНИЕ
- •СПИСОК ЛИТЕРАТУРЫ
- •ИСПОЛЬЗОВАНИЕ МОДУЛЯ «RATIONAL ROSE C++ ANALYZER» ДЛЯ ОБРАТНОГО ВОССТАНОВЛЕНИЯ МОДЕЛИ ПО ИСХОДНОМУ КОДУ
- •РАЗРАБОТКА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ С ИСПОЛЬЗОВАНИЕМ UML
- •1. Разработка диаграммы прецедентов
- •2. Разработка диаграммы классов
- •3. Разработка диаграмм взаимодействия
- •4. Разработка диаграммы состояний
- •5. Разработка диаграммы деятельности
- •9. Разработка приложения
- •Контрольные вопросы
- •МОДЕЛЬ РАБОТЫ ПРЕДПРИЯТИЯ ОПТОВОЙ ТОРГОВЛИ. РАЗРАБОТКА АВТОМАТИЗИРОВАННОЙ СИСТЕМЫ
- •ОГЛАВЛЕНИЕ
- •1. Деятельность и структура предприятия
- •2.1. Реализация продукции со склада
- •2.2. Возврат товара клиентом
- •2.3. Закупка продукции
- •3.1. Общие требования и принципы построения системы
- •3.2. Обеспечение связи офис - склад
- •3.3. Требования к персоналу
- •4. Диаграмма прецедентов
- •4.1. Реализация продукции со склада
- •5. Диаграмма классов
- •5.2. Контрагенты предприятия оптовой торговли
- •5.3. Продукция предприятия оптовой торговли
- •5.4. Заказ продукции
- •5.5. Накладная на получение товара
- •6. Диаграмма взаимодействия
- •12. Разработка приложения
- •ПРОЕКТИРОВАНИЕ АВТОМАТИЗИРОВАННЫХ ИНФОРМАЦИОННЫХ СИСТЕМ НА ОСНОВЕ ОБЪЕКТНО ОРИЕНТИРОВАННОГО ПОДХОДА
плановое количество по каждой товарной позиции. Назовем данный класс «PurchasePlanPosition». Атрибуты класса следующие:
-measureUnit (единица измерения);
-planQuantity (плановое количество);
-factQuantity (выполнено фактически);
-isMain (признак основного плана).
Атрибута «factQuantity» может и не быть в этом классе, в этом случае фактическое значение отгрузки будет вычисляться в аналити ческом отчете по актам приемки. Атрибут «isMain» определяет тип позиции плана: основная или корректирующая. Основной план со ставляется в начале планового периода, а затем может быть откор ректирован путем добавления позиций с отрицательными или поло жительными значениями. Соответствующая диаграмма классов пред ставлена на рис. П3.27.
6. Диаграмма взаимодействия
В нотации UML взаимодействие элементов рассматривается в информационном аспекте их коммуникации. Другими словами, взаимодействующие объекты обмениваются между собой некоторой информацией. При этом информация представляет собой закончен ные сообщения.
Для описания взаимодействия объектов, участвующих в некото ром прецеденте, используются сценарии. Сценарий - это экземпляр прецедента, определяющий один из возможных потоков событий дан ного прецедента. Сам прецедент приставляет собой переплетение сце нариев - как основных, представляющих нормальное течение собы тий, так и вспомогательных, определяющих логику функционирования системы в ситуациях вида «что произойдет, если...». На ранних стади ях проектирования системы, как правило, ограничиваются рассмотре нием основного сценария для каждого выявленного прецедента.
Создадим реализацию прецедента «Согласование заказа» (рис. П3.28).
Согласование заказа |
Согласование заказа |
(from Logical View)
Построим для данной реализации диаграмму последовательно стей, которая будет описывать сценарий размещения нового заказа, и назовем эту диаграмму, соответственно, «Размещение нового зака за». На данной диаграмме отразим взаимодействие объектов классов: «Customer» (клиент), «Manager» (менеджер), «OrderForm» (форма ра боты с заказами), «OrderControl» (контроль заказа), «OrderPosition» (позиция заказа), «OrderPosForm» (форма работы с позициями зака за). Построенная диаграмма представлена на рис. П3.29.
Диаграммы последовательностей не только отображают взаимо действие объектов, но и позволяют определить/отыскать операции, которые должны выполнять те или иные классы.
Рис. П3.29. Диаграмма последовательностей для описания процесса «Создание заказа»
Диаграмма сотрудничества представляет альтернативный способ описания взаимодействия объектов и акцентирует внимание в пер вую очередь на организации объектов.
Создадим реализацию прецедента «Выписка накладной» (рис. ПЗ.ЗО) и построим диаграмму сотрудничества для сценария «Печать накладной» (рис. П3.31).
Выписка накладной |
Выписка накладной |
(from Logical View ) |
|
Рис. ПЗ.ЗО. Реализация прецедента «Выписка накладной»
2:displayf)
------ >
Рис. П3.31. Печать накладной. Диаграмма сотрудничества
Rational Rose позволяет автоматически создавать диаграмму со трудничества по диаграмме последовательностей и наоборот. Прове рим, как это работает на практике. Создадим несложную диаграмму последовательностей для сценария регистрации сотрудника предпри ятия в системе управления складом (рис. П3.32).
Employee : LoainForm : Svstem llser
1 |
---------------------- |
|
|
|
|
|
inputNameQ |
|
|
|
display |
|
inputPassword() |
i==i |
checkUserQ
register^)
Tl
Рис. П3.32. Регистрация в системе. Диаграмма последовательностей
Затем с помощью меню «Browse» > «Create Collaboration Dia
gram» создадим диаграмму сотрудничества (рис. ПЗ.ЗЗ).
2: display 4: checkUser()
Рис. ПЗ.ЗЗ. Регистрация в системе. Диаграмма сотрудничества
Диаграмма состояний определяет последовательность состояний объекта, вызванных последовательностью событий.
Рассмотрим построение диаграммы для объектов класса «Order» (заказ).
Из спецификации прецедентов следует, что заказ может быть в трех состояниях: «Новый», «Оплаченный» и «Отмененный». В со стояние «Новый» заказ попадает сразу после своего создания и нахо дится в нем до момента перевода его менеджером в состояние «Опла ченный». Событием к переходу является поступление денег в кассу или на расчетный счет предприятия. Условие перехода - оплата долж на производиться не позднее 10 дней со дня оформления заказа. В случае если оплата не производится или производится позже, отве денных 10 дней, заказ переходит в состояние «Отмененный». Соот ветствующая диаграмма состояний представлена на рис. П3.34.
Рис. П3.34. Диаграмма состояний заказа
Далее рассмотрим построение диаграммы состояний для товарно транспортной накладной. Все вновь созданные накладные попадают в состояние «Новая». После печати накладной она переходит в со стояние «Выписанная». В этот момент электронная накладная стано вится доступной кладовщику на складе, и он начинает сборку заказа. По окончании сборки кладовщик переводит накладную в состояние «Готовая». Если по каким-то причинам на складе не оказалось нуж ного товара (брак в партии, просрочка поставщика и т.п.), что делает невозможным сборку заказа, накладная переходит в состояние «При
остановленная». После того как товар отгружен клиенту, накладная переходит в состояние «Отгруженная». Диаграмма состояний для на кладной изображена на рис. П3.35.
Рис. П3.35. Диаграмма состояний для накладной
Диаграмма состояний для плана закупок содержит три состояния: «Новый», «Утвержденный» и «Закрытый» (рис. П3.36). В состояние «Новый» план попадает сразу после своего создания, в состояние «Утвержденный» - после утверждения. По истечении периода дейст вия план переходит в состояние «Закрытый».
Теперь можно легко сгенерировать программный код классов, реализуемых компонентом «Order» (выделив компоненты «Order» и выбрав пункт меню «Tool/OH-/Code Generation»). Ниже представ лен фрагмент программного кода файла заголовка с расширением М для классов компонента «Order». Часть комментариев, которые фор мируются автоматически Rational Rose, была удалена с целью уменьшения объема кода.
# i f n d e f O r d e r _ h
# d e f i n e O r d e r _ h 1
/ / |
P r o d u c t |
|
|
|
# i n c l u d e " P r o d u c t . h " |
|
|
|
|
/ / |
O r d e r |
|
|
|
# i n c l u d e " O r d e r . c p p " |
|
|
|
|
/ / |
P a y m e n t |
|
|
|
# i n c l u d e " P a y m e n t . h " |
|
|
|
|
/ / |
C u s t o m e r |
|
|
|
# i n c l u d e " C u s t o m e r . h " |
|
|
|
|
/ / П о з и ц и я з а к а з а |
|
|
|
|
c l a s s O r d e r P o s i t i o n |
|
|
|
|
{ |
|
|
|
|
|
p u b l i c : |
|
|
|
|
O r d e r P o s i t i o n ( ) ; |
|
|
|
|
O r d e r P o s i t i o n ( c o n s t O r d e r P o s i t i o n b r i g h t ) ; |
|||
|
- O r d e r P o s i t i o n ( ) ; |
|
|
|
|
O r d e r P o s i t i o n |
& |
o p e r a t o r = ( c o n s t |
O r d e r P o s i t i o n |
b r i g h t ) ;
i n t o p e r a t o r = = ( c o n s t i n t o p e r a t o r ! = ( c o n s t
O r d e r P o s i t i o n O r d e r P o s i t i o n
b r i g h t ) |
c o n s t ; |
b r i g h t ) |
c o n s t ; |
/ / П о л у ч и т ь д е й с т в у ю щ у ю ц е н у п о п р а й с - л и с т у d o u b l e g e t A c t u a l P r i c e ( ) ;
/ / П о л у ч е н и е ц е н ы с у ч е т о м н а л о г о в d o u b l e g e t A c t u a l T a x P r i c e ( ) ;
/ / |
Р а с ч е т с у м м ы |
d o u b l e c a l c A m o u n t ( ) ; |
|
/ / |
Р а с ч е т с у м м ы с н а л о г а м и |
d o u b l e c a l c A m o u n t T a x ( ) ;
c o n s t P r o d u c t * g e t _ t h e _ P r o d u c t v o i d s e t _ t h e _ P r o d u c t ( P r o d u c t *
() c o n s t v a l u e ) ;
c o n s t d o u b l e g e t _ q u a n t i t y v o i d s e t _ q u a n t i t y ( d o u b l e
() c o n s t ; v a l u e ) ;
c o n s t c h a r * g e t _ m e a s u r e U n i t v o i d s e t _ m e a s u r e U n i t ( c h a r *
() c o n s t ; v a l u e ) ;
c o n s t d o u b l e g e t _ p r i c e v o i d s e t _ p r i c e ( d o u b l e
() c o n s t ; v a l u e ) ;
c o n s t d o u b l e g e t _ t a x P r i c e v o i d s e t _ t a x P r i c e ( d o u b l e
() c o n s t ; v a l u e ) ;
c o n s t d o u b l e g e t _ a m o u n t v o i d s e t _ a m o u n t ( d o u b l e
() c o n s t ; v a l u e ) ;
c o n s t d o u b l e g e t _ t a x A m o u n t v o i d s e t _ t a x A m o u n t ( d o u b l e
p r o t e c t e d : p r i v a t e :
d o u b l e q u a n t i t y ;
c h a r * m e a s u r e U n i t ; d o u b l e p r i c e d -
d o u b l e t a x P r i c e ; d o u b 1 e a m o u n t ;
d o u b 1 e t a x A m o u n t ;
() c o n s t ; v a l u e ) ;
P r o d u c t * t h e P r o d u c t ;
/ / З а к а з
c l a s s O r d e r
{
p u b l i c :
O r d e r ( ) ;
На диаграмме, представленной на рис. П3.55, изображены только идентифицирующие отношения (Identifying Relationships) и список таб лиц совпадает с числом классов соответствующей диаграммы. Это не означает, что число классов и их структура будут всегда совпадать с ре ляционной моделью. Рассмотрим пример диаграммы модели данных, структура которой отличается от соответствующей диаграммы классов.
Рис. П3.56. Диаграмма заказа продукции
Построим диаграмму для заказа продукции. Соответствующая диаграмма классов представлена на рис. П3.15.
На диаграмме классов представлены классы: «Customer», «Or der», «OrderPositon» и «Product». Диаграмма данных будет содержать четыре одноименные таблицы и ряд дополнительных таблиц. К до полнительным таблицам отнесем таблицу единиц измерений, табли цу состояний документов и таблицу, определяющую набор состояний для конкретного документа.
Диаграмма для заказа продукции представлена на рис. П3.56. Таблица «Заказ» была названа «PROD_ORDER», потому что «ORDER» является служебным словом языка запросов SQL.
Часть операций классов может быть перенесена на уровень базы данных и реализована в виде триггеров, функций и процедур.
Рассмотрим пример создания триггера для таблицы «ORDERPOSITION». Назначение создаваемого триггера - автома тический расчет стоимости товарной позиции.
Для этого в окне спецификации таблицы «ORDER POSITION» перейдем на закладку «Triggers» и, воспользовавшись кнопкой «New», создадим новый триггер. Изменим системное имя триггера на «CALC_VALUES_BUI». Далее отметим события активации триггера («Trigger Event»): «Insert» и «Update». Для «Update» укажем поля «PRODUCT_ID», «MEASURE_UNIT_ID». Тип триггера («Trigger Туре») установим в «Before». Свойство «Granularity», определяющее, когда должен отрабатывать триггер, установим в «Row». В тело триг гера («Action Body») поместим текст, представленный ниже:
DECLARE
V_DATE DATE;
Begin
/^Определим дату заказа*/
SELECT ORDER_DATE
INTO V _DATE
FROM PROD_ORDER
WHERE I D = : NEW. O R D E R _ ID ;
/*Получим действующую цену без налогов на переданный продукт*/
:NEW.P R IC E : = F _ G E T _ C U R R E N T _ P R IC E ( :NEW.PRO DUCT _ID, :N E W .M E A SU R E _ U N IT _ ID , V _ D A T E , 0 ) ;
/*Рассчитаем сумму без налогов*/
:NEW.AMOUNT : = ROUND ( : NEW.P R IC E * : NEW.QUANTITY, 2 ) ;
Третья, заключительная, страница мастера (рис. П3.59) позволяет указать имя файла, в который будет записан DDL-скрипт, и опреде лить необходимость его непосредственного выполнения из Rational
Rose (опция «Execute»).
В случае установки «Execute» и заполнения параметров соедине ния Rational Rose не только создаст DDL-скрипт, но и выполнит его,
используя указанное соединение.
Результат работы мастера для нашей схемы представлен ниже:
CREATE TABLE DEPARTMENT |
( |
|
|
|
|
|
|
|
|||||||
ID NUMBER |
( |
1 0 |
) |
|
NOT |
NULL, |
|
|
|
|
|
||||
NAME VARCHAR2 |
( 1 2 8 |
) |
NOT |
NULL, |
|
|
|
||||||||
PHONE_NUMBER |
VARCHAR2 |
( |
|
3 2 |
) , |
|
|
|
|
||||||
FAX_NUMBER |
VARCHAR2 |
( 3 2 |
) , |
|
|
|
|
||||||||
COMPANY_ID NUMBER ( |
1 0 |
) |
NOT |
NULL, |
|
|
|||||||||
O F F IC E _ ID |
NUMBER |
|
( |
1 0 |
) |
|
NOT NULL, |
|
|
||||||
CONSTRAINT |
PK_DEPARTMENT |
PRIMARY |
KEY |
(CO M PAN Y _ID, |
|||||||||||
O F F I C E _ I D , I D ) , |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
CONSTRAINT TC_DEPARTMENT_NAME |
UNIQUE |
(NAME) |
|||||||||||||
) |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/ |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
CREATE TABLE M EASURE_UNIT |
( |
|
|
|
|
|
|||||||||
ID NUMBER |
( |
1 0 |
) |
|
NOT |
NULL, |
|
|
|
|
|
||||
NAME VARCHAR2 |
( |
3 2 |
) |
NOT |
NULL, |
|
|
|
|||||||
SHORT_NAME |
VARCHAR2 |
( |
1 |
|
) |
NOT |
NULL, |
|
|
||||||
CONSTRAINT TC_MU_SHORT_NAME UNIQUE |
(SH O R T _ N A M E ), |
||||||||||||||
CONSTRAINT PK_M EASURE_UNIT PRIMARY |
KEY ( I D ) , |
||||||||||||||
CONSTRAINT TC_MU_NAME |
UNIQUE |
(NAME) |
|
|
|||||||||||
) |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/ |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
CREATE TABLE |
DOCUMENT_STATE ( |
|
|
|
|
||||||||||
ID NUMBER |
( |
5 |
) |
NOT |
NULL, |
|
|
|
|
|
|||||
ST A T E _ ID |
NUMBER |
( |
1 0 |
) |
NOT |
NULL, |
|
|
|
||||||
DOCUMENTED |
NUMBER |
( |
1 0 |
|
) |
NOT |
NULL, |
|
|
||||||
CONSTRAINT PK_DOCUMENT_STATE PRIMARY KEY |
|||||||||||||||
(DOCUMENT_ID, |
S T A T E E D , |
ID ) |
|
|
|
|
|
|
|
|
|||||
) |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/ |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
CREATE TABLE PROD_ORDER ( |
|
|
|
|
|
|
|
||||||||
ID NUMBER |
( |
1 0 |
) |
|
NOT |
NULL, |
|
|
|
|
|
||||
ORDER_NUMBER |
VARCHAR2 |
( |
|
3 2 |
) |
NOT |
N U LL, |
||||||||
ORDER_DATE DATE NOT NULL, |
|
|
|
|
|
||||||||||
SHIPMENT_DATE |
DATE, |
|
|
|
|
|
|
|
|
|
|||||
P R IO R IT Y |
NUMBER |
( |
1 |
) |
DEFAULT |
9 |
NOT |
|
N U LL, |
CUSTOMER _ID NUMBER ( |
1 0 |
) |
NOT |
NULL, |
|
||||||||||
CONSTRAINT |
PK_ORDER PRIMARY KEY |
( I D ) , |
|
||||||||||||
CONSTRAINT |
A K _ O R D E R _ l |
UNIQUE |
|
(ORDER_DATE, |
|||||||||||
ORDER_NUMBER) |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
) |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/ |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
CREATE |
TABLE |
O R D E R _ P O S IT IO N ( |
|
|
|
|
|
||||||||
ID NUMBER |
( 1 0 |
) |
NOT |
NULL, |
|
|
|
|
|
|
|||||
O R DER _ID NUMBER ( |
|
1 0 |
) |
NOT |
NULL, |
|
|
||||||||
PRO DUC T _ID |
NUMBER |
|
( |
1 0 |
) |
NOT |
|
NULL, |
|
||||||
M E A S U R E _ U N IT _ ID |
NUMBER |
( |
1 0 |
) |
NOT |
NULL, |
|||||||||
QUANTITY NUMBER |
( |
|
1 0 , |
3 |
) DEFAULT 0 NOT NULL, |
||||||||||
P R IC E NUMBER |
( |
1 0 , |
2 |
) |
DEFAULT |
0 |
NOT NULL, |
||||||||
T A X _ P R IC E |
NUMBER |
( |
1 0 , |
2 |
) DEFAULT 0 NOT NULL, |
||||||||||
AMOUNT NUMBER |
( |
1 0 , |
2 |
) |
DEFAULT |
0 |
NOT |
NULL, |
|||||||
TAX_AMOUNT |
NUMBER |
|
( |
1 0 |
) |
DEFAULT |
0 NOT |
NULL, |
|||||||
CONSTRAINT |
P K _ O R D E R _ P O S IT IO N 6 |
PRIMARY |
KEY (O R D E R _ID , |
||||||||||||
ID) |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
) |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/ |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
CREATE |
TABLE |
O F F IC E |
( |
|
|
|
|
|
|
|
|
|
|||
ID NUMBER |
( 1 0 |
) |
NOT |
NULL, |
|
|
|
|
|
|
|||||
NAME |
VARCHAR2 |
( |
1 2 8 |
) |
NOT |
NULL, |
|
|
|
||||||
ADDRESS VARCHAR2 |
( |
2 5 6 |
) , |
|
|
|
|
|
|
||||||
COMPANY_ID |
NUMBER |
|
( |
1 0 |
) |
NOT |
|
NULL, |
|
||||||
CONSTRAINT |
P K _ O F F IC E |
PRIMARY |
|
KEY |
(COMPANY_ID, ID ) , |
||||||||||
CONSTRAINT |
T C _O FFIC E _N A M E |
UNIQUE |
(NAME) |
||||||||||||
) |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/ |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
CREATE |
TABLE |
COMPANY |
( |
|
|
|
|
|
|
|
|
|
|||
ID NUMBER |
( 1 0 |
) |
NOT |
N U LL, |
|
|
|
|
|
|
|||||
NAME |
VARCHAR2 |
( |
2 5 6 |
) |
NOT |
NULL, |
|
|
|
||||||
INN |
VARCHAR2 |
( |
1 2 |
|
) |
NOT |
NULL, |
|
|
|
|
||||
J U R ID IC A L _ A D D R E S S |
|
VARCHAR2 |
( |
|
2 5 6 |
) NOT |
NULL, |
||||||||
P O ST _A D D R E SS VARCHAR2 |
( |
2 5 6 |
) , |
|
|
|
|||||||||
PHONE_NUMBER |
VARCHAR2 |
( |
3 2 |
) , |
|
|
|
|
|||||||
FAX_NUMBER |
VARCHAR2 |
( |
3 2 |
) , |
|
|
|
|
|
||||||
CONSTRAINT |
A K _CO M PA NY _l |
UNIQUE |
(NAME, |
IN N , |
|||||||||||
JU R ID IC A L _ A D D R E SS) , |
|
|
|
|
|
|
|
|
|
|
|
|
|
||
CONSTRAINT |
P K _ C o m p a n y |
PRIMARY |
KEY |
( I D ) , |
|||||||||||
CONSTRAINT |
T C _ C o m p a n y _ N A M E |
UNIQUE |
(NAME) |
||||||||||||
) |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/ |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
CREATE TABLE PRODUCT (
ID NUMBER ( 1 0 ) NOT N U LL,
PRODUCT CODE VARCHAR2 ( 3 2 ) NOT NULL,
ШШЕ |
VARCHAR2 |
( |
1 2 8 |
) |
NOT |
NULL, |
|
|
||||||
D E SC R IPT IO N VARCHAR2 |
( 2 5 6 |
) , |
|
|
|
|
||||||||
PRODUCER VARCHAR2 |
( |
1 2 8 |
) , |
|
|
|
|
|
||||||
ITEM_WEIGHT |
NUMBER |
( 1 2 , |
6 ) NOT N U LL, |
|||||||||||
CONSTRAINT |
PK_PRODUCT PRIMARY KEY |
( I D ) , |
||||||||||||
CONSTRAINT |
TC_PRODUCT_NAME |
UNIQUE |
(N A M E ), |
|||||||||||
CONSTRAINT |
TC_PRODUCT_CODE |
UNIQUE |
( PRODUCT_CODE) |
|||||||||||
) |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/ |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
CREATE |
TABLE |
WAREHOUSE |
( |
|
|
|
|
|
|
|
||||
ID NUMBER |
( |
1 0 |
) |
NOT |
NULL, |
|
|
|
|
|
||||
NAME |
VARCHAR2 |
( 1 2 8 |
) |
NOT |
NULL, |
|
|
|||||||
ADDRESS VARCHAR2 |
( |
2 5 6 |
) |
NOT |
NULL, |
|
||||||||
PHONE_NUMBER |
VARCHAR2 |
( |
3 2 |
) , |
|
|
|
|
||||||
FAX_NUMBER |
VARCHAR2 |
( |
3 2 |
) , |
|
|
|
|
||||||
COMPANY_ID |
NUMBER |
( |
1 0 |
) |
NOT |
NULL, |
|
|||||||
CONSTRAINT |
PK_WAREHOUSE |
PRIMARY KEY |
(CO M PAN Y _ID, I D ) , |
|||||||||||
CONSTRAINT |
TC |
WAREHOUSE |
UNIQUE |
(NAME) |
||||||||||
) |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/ |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
CREATE |
TABLE |
CONTRACTOR |
( |
|
|
|
|
|
|
|||||
I D NUMBER |
( |
1 0 |
) |
NOT |
NULL, |
|
|
|
|
|
||||
NAME |
VARCHAR2 |
( |
2 5 6 |
) |
NOT |
NULL, |
|
|
||||||
INN |
VARCHAR2 |
( |
1 2 |
) |
NOT |
NULL, |
|
|
|
|||||
JUR IDA L _ADD RESS VARCHAR2 |
( |
2 5 6 |
) |
NOT |
N U LL, |
|||||||||
POST_ADDRESS |
VARCHAR2 |
( |
2 5 6 |
) , |
|
|
|
|||||||
PHONE_NUMBER VARCHAR2 |
( |
3 2 |
) , |
|
|
|
||||||||
FAX_NUMBER |
VARCHAR2 |
( |
3 2 |
) , |
|
|
|
|
||||||
CONTACT_PERSON |
VARCHAR2 |
( |
6 4 |
) |
NOT N U LL, |
|||||||||
E_M AIL VARCHAR2 |
( |
6 4 |
) , |
|
|
|
|
|
|
|||||
NOTE |
VARCHAR2 |
( |
1 2 8 |
) , |
|
|
|
|
|
|
|
|||
CONSTRAINT |
PK_CONTRACTOR |
PRIMARY |
KEY |
( I D ) , |
||||||||||
CONSTRAINT |
TC_CONTRACTOR_NAME |
UNIQUE |
(NAME) |
|||||||||||
) |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/ |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
CREATE |
TABLE |
S T A T E _ L IS T |
( |
|
|
|
|
|
|
|||||
I D NUMBER |
( |
1 0 |
) |
NOT |
NULL, |
|
|
|
|
|
||||
NAME VARCHAR2 |
( |
3 2 |
) |
NOT |
NULL, |
|
|
|
||||||
CONSTRAINT |
T C _ST A T E _ L IST _ N A M E |
UNIQUE |
(N A M E ), |
|||||||||||
CONSTRAINT |
P K _ S T A T E _ L IS T |
PRIMARY |
KEY |
( I D ) |
)
/
ALTER TABLE DEPARTMENT ADD ( CONSTRAINT FK_DEPARTMENT2 FOREIGN KEY (COMPANY_ID, O F F I C E _ I D ) REFERENCES O F F IC E
( COMPANY_ID, I D ) )
/
ALTER |
TABLE |
DOCUMENT_STATE ADD ( |
CONSTRAINT |
|
||||||||||||
FK_DOCUMENT_ID FOREIGN KEY (DOCUMENT_ID) REFERENCES |
||||||||||||||||
PROD_ORDER ( I D ) ) |
|
|
|
|
|
|
|
|
|
|
|
|
|
|||
/ |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
ALTER |
TABLE |
DOCUMENT_STATE |
ADD |
( |
CONSTRAINT |
|
||||||||||
F K _ S T A T E _ L I S T _ ID |
FOREIGN |
KEY |
(S T A T E _ ID ) |
REFERENCES |
||||||||||||
S T A T E _ L IS T ( I D ) ) |
|
|
|
|
|
|
|
|
|
|
|
|
|
|||
/ |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
ALTER |
TABLE |
PROD_ORDER |
ADD |
( |
CONSTRAINT |
FK_CUSTOMER_ID |
||||||||||
FOREIGN KEY |
(C U ST O M E R _ID ) |
|
REFERENCES |
CONTRACTOR |
( I D ) ) |
|||||||||||
/ |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
ALTER |
TABLE |
O R D E R _ P O S IT IO N |
ADD |
( |
CONSTRAINT |
|
||||||||||
F K _ O R D E R _ P O S IT IO N 10 FOREIGN |
KEY |
(PR O D U C T _ID ) |
REFERENCES |
|||||||||||||
PRODUCT |
( I D ) ) |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/ |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
ALTER |
TABLE |
O R D E R _ P O S IT IO N |
ADD |
( |
CONSTRAINT |
|
||||||||||
FK_ORDER_MU_ID |
FOREIGN |
KEY |
(M E A S U R E _ U N IT _ ID ) |
REFERENCES |
||||||||||||
MEASURE_UNIT |
( I D ) ) |
|
|
|
|
|
|
|
|
|
|
|
|
|||
/ |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
ALTER |
TABLE |
O R D E R _ P O S IT IO N |
ADD |
( |
CONSTRAINT FK _ORDER _ID |
|||||||||||
FOREIGN KEY |
(O R D E R _ ID ) |
REFERENCES |
PROD_ORDER |
( I D ) ) |
||||||||||||
/ |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
ALTER |
TABLE |
O F F IC E |
ADD |
( |
CONSTRAINT |
FK _ O F FIC E |
FOREIGN |
|||||||||
KEY (COM PANY _ID) |
REFERENCES |
COMPANY |
( I D ) ) |
|
|
|
||||||||||
/ |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
ALTER |
TABLE |
WAREHOUSE |
|
ADD |
( |
CONSTRAINT |
FK_WAREHOUSE3 |
|||||||||
FOREIGN KEY |
(CO M PAN Y _ID) |
REFERENCES |
COMPANY |
( I D ) ) |
|
|||||||||||
/ |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
CREATE TRIGGER C A L C _ V A L U E S _ B U I BEFORE |
UPDATE |
OF |
||||||||||||||
M E A SU R E _ U N IT _ ID , |
PR O D U C T _ ID |
OR |
IN SE R T |
ON |
O R D E R _PO SIT IO N |
|||||||||||
FOR EACH |
ROW |
|
|
|
|
|
|
|
|
|
|
|
|
|
||
DECLARE |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
V _DATE |
DATE; |
|
|
|
|
|
|
|
|
|
|
|
|
|
||
B e g i n |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/ * О п р е д е л и м д а т у з а к а з а * / |
|
|
|
|
|
|
|
|
||||||||
SELECT |
ORDER _DATE |
|
|
|
|
|
|
|
|
|
|
|
|
|||
INTO |
V _D ATE |
|
|
|
|
|
|
|
|
|
|
|
|
|||
|
FROM |
PROD_ORDER |
|
|
|
|
|
|
|
|
|
|
|
|||
|
|
WHERE I D = |
: NEW. O R D E R _ ID ; |
|
|
|
|
/ * П о л у ч и м д е й с т в у ю щ у ю ц е н у б е з н а л о г о в н а п е р е д а н н ы й п р о д у к т * /
: N E W .P R IC E : = F _G E T _ C U R R E N T _ P R IC E ( :N E W .PR O D U C T _ID , : N E W .M E A SU R E _ U N IT _ ID , V _ D A T E , 0 ) ;
/ * Р а с с ч и т а е м с у м м у б е з н а л о г о в * /