Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
Задача
Некие поставщики снабжают товарами клиентов. Асортимент товаров велик. Спроектируйте приложение для сопровождения баз данных, которая бы позволяла анализировать следующее:
Создание DFD диаграммы
На этом построение диаграммы нулевого уровня заканчивается и начинается построение диаграммы первого уровня.
1) Вызываем контекстное меню и выбираем пункт «Редактировать процесс». В появившемся окне снимаем флажок Lowest level.
2) В дереве DFD Navigator выбираем процесс «Сделать заказ». Связываем существующие потоки с новыми процессами. Новые процессы «Получение информации о товарах» и «Оформление заказа», связываем их потоками с другими элементами диаграммы, как это было описано ранее.
3) Добавляем 2 хранилища данных на диаграмму. Называем их «Поставщики» и «Товары», добавляем потоки данных «Запрос 2»(связывает процесс «Получение информации о товарах» с хранилищем данных «Поставщики»), «Запрос 1»(связывает процесс «Получение информации о товарах» с хранилищем данных «Товар»), «Информация о товарах»(связывает хранилище данных «Товар» с процессом «Оформление заказа»), «Контроль товаров»( связывает процесс «Оформление заказа» с хранилищем данных «Товар»). В дереве DFD Navigator процессы нижних уровней представлены темными кружочками.
Семантика 0-уровня
Администрация оптового склада товаров заказала разработку модуля информационной системы для отдела продаж. Система предназначена для автоматизации процесса осуществления и хранения заказов. Во время предпроектного исследования составлено следующее описание событий, происходящих во время оформления заказа товаров:
Семантика 1-уровня
Администрация оптового склада товаров заказала разработку модуля информационной системы для отдела продаж. Система предназначена для автоматизации процесса осуществления и хранения заказов. Во время предпроектного исследования составлено следующее описание событий, происходящих во время оформления заказа товаров:
Создание ER-диаграммы
1. Запустим среду построения ER-диаграмм.
2. Начнем создавать модель, используя команду меню File / New Model.
3. В появившемся окне "Target database selection" выберем формат базы данных Firebird.
4. Добавляем сущности. Для этого щелкаем на иконку «Entity» и потом щелкаем на область построения. Дважды щелкаем на сущности или щелкаем правой кнопкой мыши и выбираем пункт контекстного меню «Правка». Определяем логическое и физическое имя сущности (в нашем случае это «Товар») и добавляем ее атрибуты: Код товара, Наименование, Цена и Код поставщика. При этом первичным ключом делаем Код товара. Можно добавлять атрибуты, индексы, ключи также свойства, настройки, определения и т.д.
5. Существует два способа добавить новые атрибуты к сущности. Нажимая на большую кнопку «Add», сохраняем все атрибуты, введя в появившемся окне все типы данных и свойства, которые будут использованы в атрибуте или нажимая на маленькую кнопку «Add», сохраняем новое имя атрибута с параметрами по умолчанию, таким способом мы можем сохранить новое имя атрибута быстрее.
6. Мы можем выбрать какие элементы будут показаны при помощи выпадающего списка на панели. Для маленьких диаграмм оптимальным вариантом является показывать все атрибуты. Для больших диаграмм можно выбрать сущности, первичные ключи или ключи. Выбрав «Attributes», мы видим все атрибуты.
8. Добавляем еще одну сущность с тремя атрибутами. Выбираем пункт меню «Правка», в открывшемся окне вводим имя сущности «Поставщики», нажимаем большую кнопку «Add», потом маленькую, в появившемся окне вводим имя атрибута «Код поставщика», его тип, ставим флажок «Ключ» и можно нажать кнопку «Ok+Add», чтобы добавить новые атрибуты, не закрывая окно. Таким же образом добавляем еще 2 атрибута: «Название», «Адрес».
9. Добавляем связи. Щелкаем мышью на иконку идентифицирующей связи и добавляем 2 связи: щелкаем на родительской сущности и удерживая левую клавишу мыши тянем до дочерней сущности. Можно использовать такие виды связей: идентифицирующая, неидентифицирующая, «многие-ко-многим», самосвязь, информационные.
10. Чтобы править связь нужно дважды на ней щелкнуть или щелкнуть правой кнопкой мыши на ней. Можно изменить имя связи, элемент соединения, отношение и т.д. Можно использовать такие методы соединения: первичный ключ, уникальная связь и альтернативный ключ.
12. На вкладке «Referential Integrity» можно определить правила целостности отношений: запрещающий механизм, каскадное удаление, нажимаем «Ok», чтобы править связь.
14. Мы работаем с физической моделью, хотя можно выбрать как физическую, так и логическую.
15. Щелкаем правой кнопкой мыши на рабочей области и меняем вид модели. Можно сделать тени, выровнять колонки и т.д.
16. Щелкаем на иконке «Model Verification» и проверяем диаграмму. В появившемся окне нажимаем клавишу «Run».
17. Щелкая на иконке «Generate Script Icon», чтобы сгенерировать SQL код.
18. В появившемся диалоговом окне выбираем пункты, которые нужно сгенерировать, на вкладке «How To Generate» определяем правила и свойства. На вкладке «Entity List» можно выбрать главную модель или другую подмодель.
19. Нажимаем клавишу «Generate», чтобы сгенерировать SQL код, когда код сгенерирован, нажимаем «View button». Эта опция помогает с легкостью создать SQL код, не тратя при этом много времени.
Преобразуем ER-диаграмму (рис. 1) в отношения: .
Рисунок 1 - Диаграмма базы данных в нотации IDEF1X
Zakazy (NomZk, Kol-vo, Customer, CodeTov), Tovar(CodeTov, Naim, Price, CodePost), Postavschiki(CodePost, Name. Address).
Определим ФЗ, которые соответствуют отношениям. Отношению Zakazy соответствует полная ФЗ NomZk à Kol-vo, Customer,CodeTov, отношению Tovar — полная ФЗ CodeTov à Naim, Price, CodePost, отношению Postavschiki — CodePost à Name, Address.
Как видно из диаграммы каждое из полученных отношений содержит только одну полную ФЗ, следовательно отношения нормализованы, то есть приведены к третьей нормальной форме.
|
Сущность |
Атрибут |
Столбец |
Мотивация |
Тип данных |
Примечание |
|
Zakazy |
NomZk |
NomZk |
Номер заказа |
Integer |
Primary Key |
|
Zakazy |
Kol-vo |
Kol-vo |
Количество товара |
Integer |
|
|
Zakazy |
Customer |
Customer |
Имя покупателя |
Char(20) |
|
|
Zakazy |
CodeTov |
CodeTov |
Код товара |
Integer |
Foreign Key |
|
Postavschiki |
CodePost |
CodePost |
Код Поставщика |
Integer |
Primary Key |
|
Postavschiki |
Name |
Name |
Название организации поставщика |
Char(20) |
|
|
Postavschiki |
Address |
Address |
Адрес поставщика |
Char(20) |
|
|
Tovar |
CodeTov |
CodeTov |
Код товара |
Integer |
Primary Key |
|
Tovar |
Naim |
Naim |
Наименование товара |
Char(20) |
|
|
Tovar |
Price |
Price |
Цена товара |
Integer |
|
|
Tovar |
CodePost |
Price |
Код поставщика |
Integer |
Foreign Key |
Сущности Zakazy и Tovar связаны при помощи неидентифицирующей связи «один-ко-многим», причем она «Optional-Mandatory», то есть каждый заказ должен содержать один или несколько товаров, но каждый товар может содержаться в 0 или несколько заказов.
Сущности Tovar и Postavschiki связаны при помощи неидентифицирующей связи «один-ко многим», причем она «Mandatory-Mandatory», то есть у каждого товара должен быть свой поставщик и каждый поставщик должен поставлять 1 или несколько товаров.
SQL-код
/*
Created 19.09.2007
Modified 01.01.2000
Project
Model
Company
Author
Version
Database Firebird
*/
Create Table "Tovar" (
"CodeTov" Integer NOT NULL,
"Name" Char(20) NOT NULL UNIQUE,
"Price" Integer NOT NULL,
"CodePost" Integer NOT NULL,
Constraint "pk_Tovar" Primary Key ("CodeTov")
);
Create Table "Postavschiki" (
"CodePost" Integer NOT NULL,
"Name" Char(20) UNIQUE,
"Address" Char(20) NOT NULL UNIQUE,
Constraint "pk_Postavschiki" Primary Key ("CodePost")
);
Create Table "Zakazy" (
"NomZk" Char(20) NOT NULL,
"Kol_vo" Integer NOT NULL,
"Customer" Char(20) NOT NULL,
"CodeTov" Integer NOT NULL,
Constraint "pk_Zakazy" Primary Key ("NomZk")
);
Alter Table "Zakazy" add Constraint "Zapros1" Foreign Key ("CodeTov") references "Tovar" ("CodeTov") on delete no action ;
Alter Table "Tovar" add Constraint "Zapros2" Foreign Key ("CodePost") references "Postavschiki" ("CodePost") on delete no action ;
Create Exception "except_del_p" 'Children still exist in child table. Cannot delete parent.';
Create Exception "except_ins_ch" 'Parent does not exist. Cannot create child.';
Create Exception "except_upd_ch" 'Parent does not exist. Cannot update child.';
Create Exception "except_upd_p" 'Children still exist in child table. Cannot update parent.';
Create Exception "except_ins_ch_card" 'Maximum cardinality exceeded. Cannot insert into child.';
Create Exception "except_upd_ch_card" 'Maximum cardinality exceeded. Cannot update child.';
set term ^;
/* Update trigger for Tovar */
Create Trigger "tu_Tovar"
for "Tovar" before update as
declare variable numrows integer;
begin
/* Restrict child Zakazy, when parent Tovar changed */
if (old."CodeTov" != new."CodeTov") then
begin
select count(*)
from "Zakazy"
where "Zakazy"."CodeTov" = old."CodeTov"
into :numrows;
if (numrows > 0) then
exception "except_upd_p";
end
end
^
/* Update trigger for Postavschiki */
Create Trigger "tu_Postavschiki"
for "Postavschiki" before update as
declare variable numrows integer;
begin
/* Restrict child Tovar, when parent Postavschiki changed */
if (old."CodePost" != new."CodePost") then
begin
select count(*)
from "Tovar"
where "Tovar"."CodePost" = old."CodePost"
into :numrows;
if (numrows > 0) then
exception "except_upd_p";
end
end
^
set term ;^