Разработка автоматизированного рабочего места секретаря профсоюзной организации

 

3. Рабочие станции

Рабочие станции поставляет отдел закупок Владимирского государственного университета в особой комплектации. Фирма рабочих станций Kraftway.

 

В качестве операционной системы для серверов выбрана серверная операционная система Windows Server 2008. На рабочих станциях принято решение по установке операционной системы Windows 7.

В качестве системы управления базами данных была выбрана MS SQL Server 2010. Она полностью отвечает требованиям разрабатываемой системы и является разрешенным программным продуктом для установки в банке.

 

МФУ необходимы для вывода информации из системы – печать отчетов, справок. Доступ ко всем МФУ будет организован через сеть.

Рис.4 «Схема рабочей сети»

 

 

 

 

 

 

 

 

 

2. Проектирование баз данных

 

База Данных (БД) — структурированный организованный набор данных, описывающих характеристики каких-либо физических или виртуальных систем.

2.1 Проектирование инфологической  модели сущность-связь (концептуальное  проектирование)

Первый этап проектирования БД – это инфологическое проектирование. На этом этапе создается частично формализованное описание объектов предметной области.

Модель «сущность-связь» - это формальная модель предметной области, которая используется на этапе инфологического проектирования БД.

Цель построения состоит в обеспечении разработчика схемой БД в форме одной модели или нескольких локальных моделей, которые относительно легко могут быть отображены в любую систему БД.

Проектирование инфологической модели было начато с определения сущностей и отношений между ними. В результате анализа предметной области были созданы 5 сущностей: Студент, приказ, Сотрудник, санаторий-профилакторий, мероприятие.

Все сущности связаны отношениями между собой. Графически отношения между двумя сущностями представлены в виде соединяющего их отрезка, добавленного ромбом. У каждого отношения были определены две важные характеристики связей: степень и кардинальность.

Степень – это число элементов одной сущности, связанных с одним элементом другой сущности.

Кардинальность – признак, определяющий обязательность принадлежности отношений.

После определения связей между сущностями были определены атрибуты сущностей. Например, атрибутами сущности Сотрудник (Worker) будут являться: ид (Oid), ФИО (fio), должность (Dolgnost) и телефон (phone).

Заключительным этапом построения инфологической модели «сущность-связь» являлось определение ключей.

Ключ - это минимальный набор атрибутов, по значениям которых можно однозначно найти требуемый экземпляр сущности.  Были определены первичные и внешние ключи. На диаграмме первичный ключ каждой сущности подчеркнут одинарной сплошной линией

Рис. 5 Инфологическая модель БД

 

 

2.2 Обоснование выбора СУБД

 

СУБД - это    комплекс    языковых     и     программных     средств, предназначенных для ведения, создания и совместного использования БД многими пользователями. Рассматриваемая база данных создана в серверной СУБД в MSSQL Server 2000, которая дает возможность реализовать все требования данного приложения.

Одним из главных преимуществ MSSQL Server 2000 является его тесная интеграция с современными средствами разработки приложений: C# .NET, VB .NET, Delphi.

СУБД MSSQL предоставляет все необходимые для выполнения работы возможности, реализует все необходимые механизмы поддержки целостности базы данных (внешние ключи, ограничение на значения атрибутов,  хранимые процедуры). Кроме того, MSSQL Server имеет следующие возможности: многопользовательский режим работы, надежные системы архивации данных, удобный графический интерфейс для работы с базой данных, что упрощает доступ к данным, их редактирование.

К недостаткам MSSQL Server следует отнести его платность. Тем не менее, инструменты, предоставляемые им, упрощают разработку приложений, тем самым, удешевляя её, что, в конечном счете, компенсирует стоимость СУБД, а в дальнейшем упрощает поддержку приложений.

 

2.3. Даталогическое проектирование

 Даталогическое проектирование реляционной БД осуществляется на основе модели сущность-связь. Целью данного вида проектирования является описание схемы реляционной БД в терминах выбранной СУБД.  При этом необходимо обеспечить:

1. Возможность хранения в БД всех необходимых данных;
2. Исключение избыточности данных;
3. Нормализацию таблиц для упрощения решения проблем, связанных с обновлением и удалением данных.

Существует 2 подхода к проектированию схемы БД:

1. классическое проектирование, которое заключается в том, что реляционная схема БД создается, минуя этап концептуального проектирования.
2. метод, основанный на построении концептуальной модели данных, которая на этапе  даталогического проектирования преобразуется в реляционную модель.

В  курсовой работе был использован именно второй метод.

Суть преобразования концептуальной модели в реляционную  заключается в том, что каждой сущности ставится в соответствие реляционная таблица, атрибутами которой становятся атрибуты сущности.

Преобразование отношений осуществляется одним из трех способов в зависимости от мощности и кардинальности связи. В концептуальной модели были использованы только связи со степенью 1:М и М:М.

Связь 1:М

Для преобразования такой связи используются 2 правила. Фактором, определяющим выбор одного из этих правил является кардинальность n- связанной сущности.

Правила преобразования:

1. Если мощность связи 1:М и кардинальность n-связанной сущности является обязательной, то достаточно двух таблиц (по одной на каждую сущность).

При этом ключ односвязной сущности должен быть добавлен как атрибут в таблицу, отводимую n-связанной сущности.

2. Если мощность связи 1:М и кардинальности n-связанной сущности является необязательной, то необходимо создать три таблицы: по одной на каждую сущность и таблицу связи.

Среди своих атрибутов таблица связи должна иметь по одному ключу от каждой сущности.

Связь М:М

Для преобразования такой связи используется одно правило в независимости от кардинальности сущностей. Оно звучит так: если мощность связи М:М, то необходимо использование трех таблиц: по одной на каждую сущность и одну таблицу связи. Таблица связи должна использовать ключи обеих сущностей.

После завершения преобразований всех конструкций полученную реляционную модель необходимо пересмотреть на предмет избавления от избыточности. Избыточные таблицы – это таблицы, информация которых полностью содержится в других таблицах схемы.

студент (ИД_студента, фамилия, имя, отчество, Институт, факультет, группа, приказ о зачислении, членство профсоюза, дата вступления в профсоюз, уплата взносов, примечание).

материальная помощь (номер приказа, фамилия имя отчество группа факультет, выделено денег)

санаторий-профилакторий (порядковый номер. дата смены, ид-студента, фамилия имя отчество факультет, забрал путёвку).

сотрудники профкома (ИД_сотрудника, фио должность телефон)

мероприятие (ИД_мероприятия, дата мероприятия, название мероприятия, ответственный, выделено денег, вернули в соответствии со сметой.)

сотрудники (ИД_сотрудника, фамилия. имя, отчество. Факультет (институт), дата приёма на работу, членство профсоюза, дата вступления в профсоюз, уплата взносов, льгота (примечание).

 

2.4 Определение типов атрибутов

Для реализации реляционной модели в выбранной СУБД нам необходимо было сначала определить характеристики атрибутов каждой таблицы, включая выделение ключей и правил поддержки целостности данных.

Наименование таблицы	Атрибуты	Тип атрибутов	Комментарии
Studenti	ID_student	int
	familiya	nvarchar(50)
	Imya	nvarchar(50)
	otchestvo	nvarchar(50)
	institut	nvarchar(50)
	fakultet	nvarchar(50)
	gruppa	nchar(10)
	[prikaz o zachislenii]	nchar(10)	номер приказа о зачислении студента в университет
	chlenstvo	nchar(10)	Членство в профсоюзе (+или-)
	[data vstupleniya]	datetime	Дата вступления в профсоюз
	[uplacheno vznosov]	nvarchar(50)	Количество уплаченных взносов по семестрам.
	primechanie	nvarchar(50)	Льготы, наличие детей и прочее.
Sotrudniki	ID_sotrudnik	int
	familiya	nvarchar(50)
	imya	nvarchar(50)
	otchestvo	nvarchar(50)
	[institut(fakultet)]	nvarchar(50)
	[data priema na rabotu]	datetime
	chlenstvo	nvarchar(50)	Членство в профсоюзе
	[data vstupleniya]	nvarchar(50)
	[yplata vznosov]	nchar(10)
	primechanie	nvarchar(50)	Наличие детей, льгот и т.д.
sotrudniki_profkoma	ident_nomer	int
	Familiya	nvarchar(50)
	Imya	nvarchar(50)
	Otchestvo	nvarchar(50)
	Dolghnost	nvarchar(50)
	Phone	nvarchar(50)	Контактный телефон
	Login	nvarchar(50)	Логин для входа в приложение
	parol	nvarchar(50)	пароль
sanatorii	por_nomer	int	Порядковый номер смены
	data_smenu
	Familiya	nvarchar(50)
	Imya	nvarchar(50)
	otchestvo	nvarchar(50)
	Fakultet	nvarchar(50)
	Gruppa	nvarchar(50)
	Zabral	nchar(10)	Забрал студент путёвкуили нет (+\-)
	ID_student	int
mat_pomosh	nomer_prikaza	int	Номер приказа о назначении студентам материальной помощи
	Familiya	nvarchar(50)
	imya	nvarchar(50)
	otchestvo	nvarchar(50)
	Fakultet	nvarchar(50)
	gruppa	nvarchar(50)
	ID_student	Int
	ID_sotrudnik	Int
	vydeleno	nchar(10)	Сколько выделено денег
	ident_nomer	Int	Идентификационный номер сотрудника профкома, проверившего приказ.
meropriyatie	ID_meropriyatiya	int	ИД мероприятия.
	data	datetime
	nazvanie	nvarchar(50)
	ident_nomer	int
	vydeleno	nchar(10)	Выделено денег на проведение мероприятия
	ostatok	nchar(10)	Остаток денег по смете.

 

 

 

2.5. поддержка целостности БД

Целостность БД - свойство базы данных, означающее, что БД содержит полную и непротиворечивую информацию, адекватно отображающую предметную область.

Различают физическую и логическую целостность. Физическая целостность означает наличие физического доступа к данным. Логическая целостность означает отсутствие логических ошибок в базе данных, к которым относится нарушение структуры базы данных или её объектов, удаление или изменение устаревших связей между объектами, неправильный ввод данных.

Принято выделять следующие ограничения:

- категорная  целостность;

- целостность  на уровне ссылок;

- функциональные  зависимости.

 

2.5.1. Категорная целостность и целостность  на уровне ссылок

 

Правило категорной целостности. Никакой ключевой атрибут строки не может быть пустым.

Правило целостности на уровне ссылок. При построении реляционных таблиц для связывания строк одной таблицы со строками другой таблицы используются внешний ключи. Значение непустого внешнего ключа должно быть равно одному из текущих значений ключа другой таблицы.

Функциональные зависимости определяют не текущее состояние БД, а все возможные её состояния, то есть они отражают те связи между атрибутами, которые присущи реальному объекту, моделируемому с помощью БД. Нужно следить за полнотой функциональных зависимостей и избегать избыточности.

 

Категорная целостность в нашей базе данных достигается путём создания ключевого атрибута во всех таблицах и установлению значения true для его атрибута «Спецификация идентифицирующего столбца». Таким образом, СУБД всегда автоматически присваивает ключевому полю всегда уникальное, не пустое значение.

Целостность на уровне ссылок достигается за счёт механизма внешних ключей. Для всех ссылающихся на другие таблицы столбцов создан внешний ключ, который не позволит удаление записей из родительской таблицы.

рис. 6 Свойства таблицы «студенты»

 

 

 

 

2.6 Создание и разработка базы  данных

Было создано 6 таблиц, заданы первичные и внешние ключи.

рис.7 таб. Студенты

 

рис. 8 таб. Сотрудники профкома

 

рис.9 таб. Сотрудники

 рис. 10 таб. Санаторий-профилакторий

рис.11 таб. Мероприятие

рис. 12 таб. Материальная помощь

 

На некоторые из атрибутов были наложены условия на значения столбцов.