Разработка полнофункционального клиент-серверного приложения, реализующего прототип информационной системы
Дипломная работа - Компьютеры, программирование
Другие дипломы по предмету Компьютеры, программирование
рументы: реляционная модель данных и язык SQL.
При разработке базы данных обычно выделяется несколько уровней моделирования, при помощи которых происходит переход от предметной области к реализации базы данных средствами конкретной СУБД:
сама предметная область;
модель предметной области;
логическая модель данных;
физическая модель данных;
собственно база данных и приложения.
Предметная область - это часть реального мира, данные о которой необходимо отразить в базе данных.
Модель предметной области - это наши знания о предметной области. Более информативными при разработке баз данных являются описания предметной области, выполненные при помощи специализированных графических нотаций.
Модель предметной области описывает процессы, происходящие в предметной области, и данные, используемые этими процессами [4]. От того, насколько правильно смоделирована предметная область, зависит успех дальнейшей разработки приложений.
2.1 Логическая модель данных
Различают три уровня логической модели, отличающихся по глубине представления информации о данных:
диаграмма сущность-связь (Entity Relationship Diagram, ERD);
модель данных, основанная на ключах (Key Based model, KB);
полная атрибутивная модель (Fully Attributed model, FA).
Диаграмма сущность-связь представляет собой модель данных верхнего уровня, отражающую основные бизнес-правила предметной области. Такая диаграмма не слишком детализирована, в нее включаются основные сущности и связи между ними, которые удовлетворяют основным требованиям, предъявляемым к БД.
Модель данных, основанная на ключах, - это более подробное представление данных. Она включает описание всех сущностей и их первичных ключей, а также всех взаимосвязей между сущностями.
Рис. 2 - Диаграмма в нотации ERWIN в графическом виде для логического представления модели
2.2 Физическая модель данных
Физическая модель данных описывается на рисунке 3. Она описывает данные средствами конкретной реляционной СУБД.
Рис. 3 - Диаграмма в нотации ERWIN в графическом виде для физического представления модели
3. Диаграмма функциональных зависимостей
Первая нормальная форма (1НФ) - имеет место, когда каждый из атрибутов отношения является атомарным (неделимым, скалярным) и не содержит повторяющихся групп.
Вторая нормальная форма (2НФ) имеет место, когда отношение находится в 1НФ, и все неключевые атрибуты отношения функционально зависят от ключа отношения.
Отношение находится в третьей нормальной форме (3НФ) тогда и только тогда, когда оно находится во 2НФ и все не ключевые атрибуты взаимно независимы, т. е. если ни один из них не является функционально зависимым от другого.
Полная атрибутивная модель является наиболее детальным представлением структуры данных. Она представляет данные в третьей нормальной форме и включает все сущности, атрибуты и связи, это видно на основе рисунка 4.
Рис. 4 - Диаграмма функциональных зависимостей
4. Спецификация на разработку интерфейса
Рис. 5 - Form 1
На рис. 5:
в comboBox1происходит выбор судна благодаря выполнению хранимой процедуры:
PROCEDURE pStPr_11water_craft_idwater_craft
в comboBox2 происходит выбор груза благодаря выполнению хранимой процедуры:
ALTER procedure pStPr_2(@M int)tv.tovar_nazvanie from tovar tvjoin water_craft wt on.tip_id=wt.tip_idwt.water_craft_id=@M
в listBox1 - заносятся результаты выполнения запроса, выдаются данные о том, сколько груза указанного типа подлежит разгрузке в нашем порту для данного судна:
ALTER procedure pStPr_1(@N int, @M varchar(50))t.tip_nazvanie as sudno, c.kolichestvo, tv.Ediniza_izmer, p.[name] as kol from cargo cjoin water_craft wt on.water_craft_id=wt.water_craft_idjoin tip t on.tip_id=t.tip_idjoin tovar tv on.tovar_id=tv.tovar_idjoin polychatel p on.polychatel_id=c.polychatel_idwt.water_craft_id=@N and tv.tovar_nazvanie=@M
Рис. 6 - Form 2
На рисунке 6:
в textBox1 заносятся данные о номере судна, которое пришло в порт раньше остальных с помощью хранимой процедуры:
procedure pStPr_3water_craft_id from water_craftdate_pributiya=(select min(date_pributiya) from water_craft)
в textBox2 заносятся данные о типе судна, которое пришло в порт раньше остальных с помощью хранимой процедуры:procedure pStPr_4(@M int)t.Tip_nazvanie from tip tjoin water_craft wt on.Tip_ID=wt.Tip_IDwt.water_craft_ID=@M
в comboBox1 происходит выбор груза благодаря выполнению хранимой процедуры:
ALTER procedure pStPr_2(@M int)tv.tovar_nazvanie from tovar tvjoin water_craft wt on.tip_id=wt.tip_idwt.water_craft_id=@M
в listBox1 заносятся результаты выполнения запроса, выдается информация о том, сколько груза указанного вида подлежит разгрузке для каждого получателя с судна, которое пришло в порт раньше других:procedure pStPr_5(@M int, @N varchar(50))p.[Name], c.Kolichestvo from cargo cjoin polychatel p on.Polychatel_ID=p.Polychatel_IDjoin water_craft wt on.water_craft_id=wt.water_craft_idjoin tovar t on.tovar_id=t.tovar_id(wt.water_craft_id=@M and t.tovar_nazvanie=@N)
Рис. 7 - Form 3
На рисунке 7:
в comboBox1 происходит выбор получателя благодаря выполнению хранимой процедуры:
procedure pStPr_6[Name] from Polychatel
в listBox1 заносятся результаты выполнения запроса, выдается информация о том, сколько груза всех видов подлежит разгрузке для выбранного получателя со всех судов, упорядочив их по названию груза:
ALTER procedure pStPr_7(@N varchar(50))tv.Tovar_nazvanie, c.Kolichestvo, wt.water_craft_ID, t.Tip_nazvaniecargo cjoin water_craft wt on c.water_craft_ID=wt.water_craft_IDjoin tip t on wt.tip_id=t.tip_idjoin tovar tv on c.Tovar_ID=tv.Tovar_IDjoin polychatel p on c.Polychatel_ID=p.Polychatel_IDp.[Name]=@Nby tv.Tovar_nazvanie asc
Рис. 8 - Form 4
На рисунке 8:
в comboBox1 происходит выбор груза благодаря выполнению хранимой процедуры:procedure pStPr_8tovar_nazvanie from tovarby tovar_nazvanie
в listBox1 заносятся результаты выполнения запроса, выдается информация о полу