Програма "Софтуерни технологии в интернет" на тема уеб система за проверка на кредитоискатели Дипломант: Георги Желев Калчев

Системата пряко използва две база данни и косвено чрез сървисите, които вика – повече от 20. Системата основно ползва базата с име „Customer22_QA” (поради което това е базата на която ще обърна внимание в дипломната работа), където е реализирана сигурността и запис на транзакциите от извиканите сървиси. Това е базата на която ще обърна внимание в дипломната работа.

Тази база данни е правена на Ms SQL, като тя се състои от 16 таблици, като 14 са свързани и 1 самостоятелна. Тази база се използва от системата за записване на транзакциите от съответните извикани сървиси, за да може в последствие да се изведе отчет с активността на съответните потребители и съответно да се формира един вид история на това което се е случвало в системата.

Може би тук е мястото да накратко споменем начина на определяне на правата на потребителите в системата, както и нейната организация. Както се вижда от фиг.3.1 всеки “User” има различни роли, които от своя страна включват различни права. Това са правата показващи вида на потребителя, а не до кой страници има достъп – например потребител с право администратор за дадена компания може да менажира потребителите на тази компания, да достъпва предоставяните услуги както през „уеб системата”, така и директно чрез извикване на сървисите, докато потребител с права само за „уеб достъп” може само да достигне и разглежда „уеб системата” и не може нито да менажира потребителите нито да стартира директно сървисите. От друга страна всеки потребител принадлежи към дадена компания или съответно има собствен „договор”. Като съответно всяка компания си е платила до достъп на точно определени „страници” и съответно определени „артикули” в тях. Условието тук е, че ако потребителя принадлежи към дадена компания, неговите лични договори не могат да надвишават определените „страници” и съответно определени „артикули” договорени от техните компании. Това правило важи и при йерархията на компаниите, т.е. ако си дъщерна компания на друга регистрирана в системата, не можеш да имаш достъп до повече артикул и страници от родителската такава. Ето сторнатата процедура, как се взимат тези страници:

-- Author: Jinx Web

-- Create date: 11/07/2007

-- Description: Return list of avaible Pages by Company

-- =============================================

ALTER PROCEDURE [dbo].[spw_CompanyPagesByCompany]

--,@ContractID uniqueidentifier

BEGIN

-- interfering with SELECT statements.

SET NOCOUNT ON;

SELECT DISTINCT

[Pages].[PageID]

,[Pages].[PageName]

,[Pages].[IsCustom]

,[CompanyPages].[OrderNumber]

,CASE WHEN [CompanyPages].[CompanyID] is null THEN 0 ELSE 1 END as IsSelected

FROM [dbo].[Pages]

LEFT JOIN [dbo].[CompanyPages] ON ([Pages].[PageID] = [CompanyPages].[PageID]) And ([CompanyPages].[CompanyID] = @CompanyID)

WHERE

--And

ORDER BY [Pages].[PageName]--IsSelected DESC,[CompanyPages].[OrderNumber]

Това е накратко как се използва тази база. За по-подробно обяснение на таблиците в следващите етапи са изброени таблиците и следва по-подробното описание на всяка една от тях.

• 
  Companies
  
• 
  CompanyContracts
  
• 
  CompanyHierarchy
  
• 
  CompanyPages
  
• 
  Contracts
  
• 
  ContractServices
  
• 
  Items
  
• 
  PageItems
  
• 
  Pages
  
• 
  Rights
  
• 
  RoleRights
  
• 
  Roles
  
• 
  TransactionHistory
  
• 
  UserContracts
  
• 
  UserRoles
  
• 
  Users
  

1. 
   Companies – в тази таблица се пазят данните за компаниите в системата. Полетата в таблицата са:
   

• 
  CompanyID – уникален идентификатор за таблицата
  
• 
  CompanyName – име на компанията
  
• 
  LogoFile – път до логото на фирмата
  
• 
  ParentID – външен ключ към същата таблица. Определя на коя компания е дъщерна текущата компания.
  
• 
  CreatedDate – дата когато компанията е създадена в базата.
  
• 
  UpdatedDate – последно обновяване на данните за компанията
  
• 
  GeoRadius – идентификационен номер на компанията по който може да се проследи къде се намира точно
  
• 
  Status – последен статус на компанията
  

2. 
   CompanyContracts – тази таблица e връзка между компанията и нейните контракти. Тук се пазят данните за контрактите на компаниите в системата. Полетата в таблицата са:
   

• 
  CompanyID – уникален идентификатор за таблицата
  
• 
  ContractID– идентификатор на контракта принадлежащ на дадената компания
  

3. 
   CompanyHierarchy – тази таблица е не задължителна. Единствената причина да се създаде подобна таблица е за да може да се определят нивата на йерархията на таблиците, т.е. на кое ниво е примерно дадената таблица. Полетата в таблицата са:
   

• 
  CompanyID – уникален идентификатор за таблицата
  
• 
  ParentID – уникален идентификатор за таблицата. Определя на коя компания е дъщерна текущата компания.
  
• 
  TreeLevel – На кое ниво в йерархия спрямо главната компания е текущата.
  

4. 
   CompanyPages – в тази таблица се пазят данните за страниците до които има достъп дадена компания в системата. Полетата в таблицата са:
   

• 
  CompanyID – уникален идентификатор за таблицата
  
• 
  PageID – уникален идентификатор
  
• 
  OrderNumber – във какъв ред да излизат табовете на страницата
  

5. 
   Contracts – в тази таблица се пазят възможните договори които дадена компания или човек може да сключи. Полетата в таблицата са:
   

• 
  ContractID – уникален идентификатор за таблицата
  
• 
  Name – име на договора
  
• 
  ContractCode – вътрешен код на договора
  
• 
  Status – статус на договора.
  
• 
  QuizzerQuestionCount – колко въпроса да генерира уеб сървиса „Quizzer” според текущия контракт. Има такъв отдел в системата който е разгледан в следващата глава.
  
• 
  QuizzerMinToPass – минимално на колко въпроса трябва да е отговорил потребителя правилно за да се приеме, че е той а не друга личност.
  

6. 
   ContractServices – в тази таблица се определя даден контракт до кои „артикули”(продукти) има достъп Като на дадена страница или подсекция даден потребител няма достъп да дадените продукти, той няма да вижда страницата дори и да има достъп до нея или ще вижда само продуктите които ги има в тази таблица за дадения контракт. Полетата в таблицата са:
   

• 
  csID – уникален идентификатор за таблицата
  
• 
  ContractID – име на компанията
  
• 
  itemID –
  
• 
  ProductID – идентификатор за връзка с таблици от други бази.
  
• 
  ProductCategory – определя от къде може да бъде извикан дадения продукт – например от уеб, от даден интерфейс или директно от уеб сървиса.
  

7. 
   Items – в тази таблица се пазят данните за всичките „артикули” (продукти) в системата. Полетата в таблицата са:
   

• 
  itemID – уникален идентификатор за таблицата
  
• 
  Item – име на артикула което се показва и за име на секцията в системата
  
• 
  Description – описание на продукта
  
• 
  BillingCode – код по който се извършват отчитанията за кой продукт е извикван и се определят плащанията.
  

8. 
   PageItems – в тази таблица се пазят данните за компаниите в системата. Полетата в таблицата са:
   

• 
  PageID – уникален идентификатор за таблицата
  
• 
  ItemID – външен ключ към таблица “Items”
  
• 
  OrderNo – Ред във който да се подреждат продуктите на страницата
  
• 
  Active – определя дали дадения продукт е активен за тази страница. Ако не е то той няма да се показва на нея. По този начин се избягва изтриването на продуктите, като просто се деактивират.
  

9. 
   Pages – в тази таблица се пазят данните за всички страници в системата. Полетата в таблицата са:
   

• 
  PageID – уникален идентификатор за таблицата
  
• 
  PageName – име на страницата, което се погазва в менюто на системата
  
• 
  IsCustom – определя дали страницата е от тип специфична страница за дадена компания.
  
• 
  Active – определя дали дадената страница е активна. Ако не е то тя няма да се показва По този начин се избягва изтриването на временно ненужни страници, като просто се деактивират.
  

10. 
    Rights – в тази таблица се пазят възможните права в системата. Полетата в таблицата са:
    

• 
  RightID– уникален идентификатор за таблицата
  
• 
  RightName– име на даденото право.
  
• 
  Active– дали е активно даденото право.
  

11. 
    RoleRights – в тази таблица е връзката между ролите и правата. Полетата в таблицата са:
    

• 
  RoleID– външен ключ за таблицата
  
• 
  RightID– външен ключ за таблицата
  

12. 
    Roles – в тази таблица се пазят ролите в системата. Всяка роля обединява множество права. Полетата в таблицата са:
    

• 
  RoleID – уникален идентификатор за таблицата
  
• 
  RoleName – име на компанията
  
• 
  Active – определя дали ролята е активна и може ли да се използва в даден момент.
  

13. 
    TransactionHistory – в тази таблица се пазят данните за всички направени транзакции в системата. По нея се определя кои сървиси са викани и съответно се определят сметките на клиентите използващи системата. Полетата в таблицата са:
    

• 
  TransactionID – уникален идентификатор за таблицата
  
• 
  ContractCode – кода на договора на компанията.
  
• 
  UserAccount – потребителя който е използвал услугите на системата.
  
• 
  ItemID – кой сървис или продукт е използван.
  
• 
  StatusCode – статуса на транзакцията – дали е била успешна или не.
  
• 
  StatusMessage – ако има грешка тук се изписва цялостния текст
  
• 
  Criteria – Какви данни са били въведени за търсенето.
  
• 
  Memo – Допълнителна информация (свободен текст)
  
• 
  DTStamp– момент на извършването на транзакцията
  

14. 
    UserContracts – в тази таблица се опива даден потребител към кои договори е включен. Полетата в таблицата са:
    

• 
  UserID– за кой потребител се отнасят договорите
  
• 
  ContractID– договорите прикачени към този потребител
  
• 
  Active– дали е активен дадения договор към този потребител за дадения момент
  
• 
  DTStamp– точния момент в който договорите на дадения потребител са променяни.
  

15. 
    UserRoles – в тази таблица се пазят ролите които даден потребител притежава. Полетата в таблицата са:
    

• 
  UserID– за кой потребител се отнася
  
• 
  RoleID– ролята която е прикачена за потребителя с посочения идентификатор
  

16. 
    Users – в тази таблица се пазят данните за потребителите в системата. Полетата в таблицата са:
    

• 
  UserID – уникален идентификатор за таблицата
  
• 
  CompanyID – към коя компания принадлежи потребителя
  
• 
  UserAccount – потребителско име
  
• 
  Email – адреса на електронната поща на потребителя.
  
• 
  Password– парола на потребителя.
  
• 
  CreatedDate – дата когато потребителя е регистриран в базата.
  
• 
  UpdatedDate – последно обновяване на данните на потребителя
  
• 
  LastLoginDate– последно влизане в системата
  
• 
  LoginCount– колко пъти потребителя е влизал в системата
  
• 
  LoginFailCount– колко пъти потребителя е въвеждал грешни данни при опит за влизане в системата
  
• 
  Status– последен статус на потребителя
  
• 
  LastName– Фамилия на потребителя
  
• 
  FirstName– Първо име на потребителя
  
• 
  Telephone– Телефон на потребителя
  

Статичните части в системата, надявам се това да е точния превод, представляват части от страницата които са еднакви в голям брой от страниците на системата. Тази роля в ASP.NET се изпълнява от така наречените “основни страници (master pages)”, които са основата на така наречените „страници със съдържанието (content pages)”. В главната страница влиза менюто обвивката на входните данни, тъй като по този начин се избягва повторение както на програмния код, така и на скрипта за скриване на входните данни. Самите полета на входните данни обаче са част от „страниците със съдържанието” тъй като са различни за различните страници. Фигура 3.2 е как изглежда статичната част.

Това е страницата която потребителя въвежда на първо място и е единственото място през което може да се добие достъп до системата. Тук потребителя въвежда данните си за идентификация и в зависимост от правата му е допуснат или не в системата. Страницата е изчистена от излишни елементи – фиг.3.3.

Тази страница (фиг. 3.4) се появява само ако потребителя има повече от един възможен договор. Ако потребителя е администратор на дадена компания и компанията има дъщерни компании той може да избере договорите на коя компания да вижда и с кой от тях да влезе. Ако няма права минава към първата от страниците които са му разрешени.

Тази страница изкарва данни(фиг.3.6) за кредитоискателя в зависимост от въведените данни(фиг.3.5) според избраната опция за търсене от радио бутоните Това е обобщена секция за търсене на кредитоискател по дадени непълни данни. Често се използват повече от една от опциите, тъй като е възможно съвпадение на имена, непълни адреси и т.н.

• 
  Address Lookup – това е търсене по адреса на кредитоискателя и извежда данни кои хора са живели на въведения адрес.
  
• 
  Phone Lookup – това е търсене по стационарен телефон и извеждане на лист с всички известни хора, на чието име е бил регистриран този номер.
  
• 
  Cellular/Unlisted – това е търсене по клетъчен или друг вид телефон и извеждане на лист с всички известни хора, на чието име е бил регистриран този номер.
  
• 
  Billing Name And Address – търсене по адреса на кредитоискателя и неговото име, както се е регистрирал да плаща сметките си.
  
• 
  Skip Search – този вид търсене позволява въвеждането на всички входни полета, като от полетата с отметка разположени в дясната страна се избира кои резултати само да се покажат и кои да се пропуснат
  
• 
  SureLoc – този вид търсене обединява по-горните опции за търсене, като в при използването на този вид търсене не се губи информация и в същото време излиза с много по-ниска цена от това да извикаш горните търсения.
  
• 
  Data Authentication – това търсене сравнява това което е въведено от кредитоискателя и това което стои в публичната база за дадената личност. По този начин се проверява за разлики между въведената информация и тази в базата, като разликите се показват като резултат. При резултата разликите с най-висок ранг се показват най-отгоре.
  
• 
  Wildcard Search – това е търсене което търси по въведените данни в няколко различни бази, като при наличие на попълнения към полетата резултата примерно на първото търсене се добавят и резултатите от следващото търсене. При липса на даден резултат в първото търсене този резултат се изтрива. Това помага за изкарването на по-малко резултати, но по-пълна информация, т.е. голяма част от излишната информация се изчиства.
  
• 
  Address Correction – този вид търсене е безплатно. Ако въведения адрес е непълен този търсенето връща като резултат възможните допълнения до пълния адрес. Вида на резултата върнат от този вид търсене е на фигура 3.7.
  

Двете страници съм ги обединил тъй като представляват абсолютно еднаква функционалност с единствената разлика в определянето на цената и въпросите които се задават. В случая и двете страници се презентират в системата и се оставя на клиента да избере кой от двата продукта ще използва.

Това е страницата където се качват файлове с различни видове запитвания (фиг.3.9). В тези файлове(batches) се намира входящата информация на хиляди търсения, както и кога да бъда стартирано търсенето - ако не е спешно търсенето минават първо тези които са по-спешните. С цел да се избегне преписването на информацията и правенето на търсения едно по едно, тази страница позволява качването на тези файлове регистрирането им в базата данни, от където друг компонент - windows сървис, извършва работата със събирането на информацията. През цялото време може да се провери статуса на тези файлове и при завършването им резултатите могат да бъдат свалени в желания формат.