Разработка информационной системы для лизинговой компании (стр. 9 из 16)

- тип сделки (сотрудники компании сами присваивают сделки конкретный тип: лизинг, сублизинг, возвратный лизинг);

- статус (здесь фиксируется на каком этапе находится исполнение сделки);

- общая сумма (сумма, на которую заключается сделка);

- стоимость имущества (стоимость необходимого клиенту имущества);

- примечание (вносятся необходимые по сделке комментарии);

- номер заявки (номер заявки, в которой содержалось прошение клиента на предоставление указанного в сделке имущества; невидимая пользователю информация, необходимая для связи с сущностью "Заявка").

Сущность "Связующая таблица". Данная сущность используется как связующая таблица между сущностями "Контрагент" и "Личность" и избавляет от нежелательной связи многие ко многим. С помощью этих данных можно в любой момент определить связь конкретного человека с конкретной фирмой и наоборот. Поскольку в одном контрагенте может быть задействовано более одного человека и одна личность может состоять в различных контрагентах, данная сущность имеет очень большое значение в системе. Сущность "Связующая таблица" обладает следующими атрибутами:

- номер пенсионного свидетельства (невидимая пользователю информация, необходимая для связи с сущностью "Личность");

- ИНН контрагента (невидимая пользователю информация, необходимая для связи с сущностью "Контрагент");

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

Сущность "Пользователь". Здесь хранится информация о данных доступа конкретного пользователя (логин и пароль), а также настройки доступа – права, которыми обладает сотрудник при работе с данной системой. Эта сущность является очень важной, так как с ее помощью происходит разграничение прав доступа.

3.2.2 Определение связей между сущностями базы данных

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

- связь "один к одному";

- связь "один ко многим";

- связь "многие к одному";

- связь "многие ко многим".

В данной инфологической модели не применяется связь "многие ко многим", которая несет в себе сложности ее реализации на программном уровне, поэтому и была введена дополнительная сущность "Связующая таблица". Рассмотрим имеющиеся связи в данной модели с помощью таблицы 2:

Таблица 2 – Связи инфологической модели

Сущность1	Наименование связи	Сущность 2	Тип связи
Договор	заключается	Контрагент	М-1
Договор	заключается	Сделка	М-1
Договор	заключается	Акт	М-1
Личность	состоит в должности	Связующая таблица	1-М
Контрагент	подает	Заявка	1-М
Контрагент	Предоставляет	Связующая таблица	1-М
Заявка	заключается	Сделка	1-1

Сущность "Договор" имеет следующие связи:

- с сущностью "Контрагент" она связана тем, договор заключается с конкретным контрагентом, причем конкретная фирма может заключать несколько договоров;

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

- с сущностью "Акт" связана тем, что на основании исполнения двух взаимосвязанных договоров заключается акт

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

Сущность "Контрагент" имеет несколько связей:

- с сущностью "Заявка" она связана тем, что один контрагент может подать несколько заявок в лизинговую компанию;

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

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

3.3 Даталогический этап проектирования автоматизированной информационной системы

Для реализации системы будет использоваться реляционная модель представления данных, которая является на данный момент одной из наиболее популярных и наиболее часто используемых (рисунок 7).

Рисунок 7 - Даталогическая модель данных

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

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

Для уменьшения избыточности информации и исключения аномалий выполняется процедура нормализации.

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

Всякая нормализованная таблица автоматически считается таблицей в первой нормальной форме, сокращенно 1НФ. Таким образом, строго говоря, "нормализованная" и "находящаяся в 1НФ" означают одно и то же. Однако на практике термин "нормализованная" часто используется в более узком смысле - "полностью нормализованная", который означает, что в проекте не нарушаются никакие принципы нормализации.

Теперь в дополнение к 1НФ можно определить дальнейшие уровни нормализации - вторую нормальную форму (2НФ), третью нормальную форму (3НФ) и т.д. По существу, таблица находится в 2НФ, если она находится в 1НФ и удовлетворяет, кроме того, некоторому дополнительному условию, суть которого будет рассмотрена ниже. Таблица находится в 3НФ, если она находится в 2НФ и, помимо этого, удовлетворяет еще другому дополнительному условию и т.д.

Таким образом, каждая нормальная форма является в некотором смысле более ограниченной, но и более желательной, чем предшествующая. Это связано с тем, что "(N+1)-я нормальная форма" не обладает некоторыми непривлекательными особенностями, свойственным "N-й нормальной форме". Общий смысл дополнительного условия, налагаемого на (N+1)-ю нормальную форму по отношению к N-й нормальной форме, состоит в исключении этих непривлекательных особенностей.

Таблица находится в первой нормальной форме (1НФ) тогда и только тогда, когда ни одна из ее строк не содержит в любом своем поле более одного значения и ни одно из ее ключевых полей не пусто

Таблица находится во второй нормальной форме (2НФ), если она удовлетворяет определению 1НФ и все ее поля, не входящие в первичный ключ, связаны полной функциональной зависимостью с первичным ключом.

Таблица находится в третьей нормальной форме (3НФ), если она удовлетворяет определению 2НФ и не одно из ее неключевых полей не зависит функционально от любого другого неключевого поля.

4. Программная реализация автоматизированной информационной системы

4.1 Выбор СУБД

При рассмотрении различных существующих систем управления базами данных мой выбор остановился на СУБД Visual FoxPro 9.0 (VFP 9.0). Данный продукт выполняет все требования, поставленные при разработке автоматизированной информационной системы.

Visual FoxPro – это объектно-ориентированный, визуально программируемый язык, управляемый по событиям, который в полной мере соответствует новым требованиям, предъявляемым к современным средствам проектирования и реализации программного обеспечения [26].

Обладая собственным внутренним механизмом управления реляционной БД, тесной взаимосвязью между языком и данными, полноценными возможностями объектно-ориентированного программирования и широким спектром функций VFP 9.0 позволяет создавать производительные, масштабируемые БД-ориентированные решения (настольные, клиент-серверные и Web) с поддержкой баз данных с таблицами объемом до 2 Гб. При этом VFP 9.0 выгодно отличается от других инструментов Microsoft умеренными системными требованиями (Windows 2000, любой Pentium II, 128 Мб ОЗУ) и высокой эффективностью разрабатываемых приложений (производительность, размеры БД и программного кода).

VFP пока избежал участи перевода в среду .NET, он сам и создаваемые с его помощью приложения предназначены для работы в традиционной Windows. Он не использует принцип управляемого кода, при этом язык FoxPro сохраняет высокую эффективность - на нем написаны многие компоненты самого инструмента. В то же время улучшение интеграции с .NET-приложениями - одно из главных направлений развития VFP. С помощью VFP 9.0 можно создавать Web-сервисы, при этом существенно упростилось их взаимодействие с .NET-приложениями.