Розробка інформаційно-пошукової системи "Клієнт-банк" на мові програмування Delphi

Размещено на http://www.allbest.ru/

Міністерство освіти і науки України

Державний ВНЗ «Національний гірничий університет»

Дипломний проект

Розробка інформаційно-пошукової системи «Клієнт-банк» на мові програмування Delphi

Реферат

Пояснительная записка: 85 стр., 19 рис., 1 табл., 4 приложения, 27 источников.

Объект разработки: информационно-поисковая система «Клиент-банк».

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

Во введении приведено описание понятия автоматизированых информационных систем, поколения информационных систем , их класификация, рассмотрено понятие информационных систем и понятие системы управления базами данных.

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

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

В разделе «Экономика» рассчитаны трудоемкость разработки программного обеспечения, расходы на создание ПО и длительность его разработки.

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

Список ключевых слов: ИНФОРМАЦИОННАЯ СИСТЕМА, СТАТИСТИКА, ТУР, АНАЛИЗ, ПРОЕКТИРОВАНИЕ СИСТЕМЫ, ДОГОВОР.

Реферат

Пояснювальна записка: 81 стор., 21 рис., 4 табл., 4 додатки, 27 джерел.

Об'єкт розробки: інформаційна система обслуговування клієнтів туристичної фірми.

Мета дипломного проекту: проектування та розробка програмного забезпечення інформаційної системи туристичної фірми, що служить для автоматизації роботи агентства.

У вступі приведено опис поняття "туризм", опис поглядів на туризм, суб'єктів туристичної діяльності, розглянуто поняття "туризм" у вузькому і широкому сенсі, описана мета, актуальність дипломного проекту та основні завдання дослідження.

У першому розділі йдеться мова про аналіз предметної області і постановки завдання, описані недоліки існуючої системи обробки інформації, обґрунтовано необхідність розробки інформаційної системи і описаний вибір і обґрунтування проектних рішень.

У другому розділі приведено опис аналізу методів проектування інформаційної системи, описано функціональне й інфологічне проектування системи, описані запити, екранні форми бази даних і розробка алгоритмів.

У розділі «Економіка» розраховані трудомісткість розробки програмного забезпечення, витрати на створення ПЗ і тривалість його розробки. програмний туристичний автоматизація запит

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

Список ключових слів: ІНФОРМАЦІЙНА СИСТЕМА, СТАТИСТИКА, КЛІЄНТ, БАНК, АДМІНІСТРАТОР, ПАСПОРТ.

Abstract

Explanatory note: Page 81, Figure 21, Table 4, 4 of the annex, 27 sources.

Property development: information system customer service travel company.

Purpose of diploma project: the design and development of software information system of a travel company, serving for automation of the agency.

The introduction describes the concept of "tourism", the description of views on tourism, subjects of tourist activity, consider the concept of "tourism" in the narrow and broad sense, to describe the purpose, the diploma project and the relevance of the main objectives of the study.

The first section deals with the analysis of the subject area and the formulation of the problem, described the shortcomings of the existing system of information processing, the necessity of the development of the information system and describes the selection and study design decisions.

The second section is set out a description of analysis methods of designing information system, described Infological functional and system design are described requests, screen forms database and algorithm development.

In the "Economy" calculated the complexity of software development, the creation of software and the duration of its development costs.

The practical significance of the project is determined by the development of an information system that serves to automate the travel company to reduce the time and money to perform standard routine operations.

Keyword List: information systems, statistics, TOUR, ANALYSIS, DESIGN SYSTEMS, CONTRACT.

Зміст

Введення

Розділ 1. Аналіз предметної області і постановка задачі

1.1 Характеристика системи "Клієнт-банк"

1.2 Технологія функціонування системи "Клієнт-банк"

Розділ 2. Проектування і розробка інформаційно-пошукової системи

2.1 Постановка і опис задачі

2.2 Створення інфологічної моделі

2.3 Створення датологічної моделі

2.4 Система програмування Delphi

2.5 Застосування мови UML до проектування інформаційної системи

Раздел 3. Економіка

3.1 Визначення трудомісткості розробки програмного забезпечення

3.2 Витрати на створення програмного забезпечення

Висновки

Перелік використаних джерел

Додаток

Введення

Автоматизовані інформаційні системи (АІС) - це інформаційне забезпечення користувача тобто надання йому необхідних даних із визначеної предметної області(ПО). Вона охоплює сукупність засобів та методів, що дозволяють користувачу збирати, зберігати, передавати і обробляти відібрану інформацію. Інформаційні системи існують з моменту появи суспільства, оскільки на кожній стадії його розвитку існує потреба в управлінні. В розвитку АІС відокремлюють 2 покоління:

- інформаційні системи (ІС) - системи з простою архітектурою та обмеженим набором можливостей. Вони складаються із набору автономних файлів і комплексу прикладних програм, що призначені для обробки цих файлів і видачі документів. Недоліки: висока надлишковість даних, складність введення і спільної обробки файлів, залежність програм від даних;

- банки даних (БнД) - системи з високим ступенем інтеграції даних і автоматизації керування ними. Вони орієнтовані на колективне використання. Банки даних позбавлені недоліків I покоління.

АІС класифікуються:

- за призначенням (фактографічні, документальні,змішані);

- за мовами (замкнуті системи, системи з базовою мовою та змішані);

- за локалізацією (локальні та розподілені);

- за схемою додаткової обробки (пост обробка та попередня обробка);

- за структурами даних (ієрархічні, мережевого типу, реляційні).

Інформаційна система - це сукупність організаційних і технічних засобів для збереження та обробки інформації з метою забезпечення інформаційних потреб користувача.

За сферою застосування можна виділити такі класи ІС:

- наукові дослідження;

- автоматизоване проектування;

- організаційне керування;

- керування технологічними процесами.

ІС автоматизованого проектування призначені для автоматизації праці інженерів - проектувальників і розроблювачів нової техніки. Такі ІС допомагають здійснювати:

- розробку нових виробів і технологій їхнього виробництва;

- різноманітні інженерні розрахунки;

- створення графічної документації;

- моделювання проектованих об'єктів;

- створення керуючих програм для верстатів.

Інформаційні системи включають в себе: технічні засоби обробки даних, програмне забезпечення і відповідний персонал. Чотири складові частини утворюють внутрішню інформаційну основу:

- засоби фіксації і збору інформації;

- засоби передачі відповідних даних та повідомлень;

- засоби збереження інформації;

- засоби аналізу, обробки і представлення інформації.

Система керування базами даних (СКБД) - це комп'ютерна програма чи комплекс програм, що забезпечує можливість користувачам створення, збереження, оновлення, пошук інформації та контролю доступу в базу даних.

Основні характеристики СКБД:

- контроль над надлишковістю даних;

- несуперечливість даних;

- підтримка цілісності бази даних;

- цілісність записується за допомогою обмежень;

- незалежність прикладних програм від даних;

- спільне використання даних;

- підвищений рівень безпеки.

Розділ 1. Аналіз предметної області і постановка задачі

1.1 Характеристика системи "Клієнт-банк"

Система "Клієнт-банк" призначена для роботи клієнта з банківською установою і передбачає передачу платіжних документів клієнта до банку, а також отримання різноманітних документів з банку каналами зв'язку.

Для з'ясування суті функціонування системи коротко розглянемо характеристику предметної області, на яку розповсюджується дія системи "Клієнт-банк".

Згідно з діючим законодавством України будь-яке підприємство чи організація повинні тримати власні грошові кошти на розрахункових рахунках в банківських установах. Розрахунки готівкою дуже обмежені як сумами, так і кількістю. В основному всі розрахунки підприємств і організацій між собою, з державним бюджетом та позабюджетними фондами проводяться в безготівковій формі через розрахунковий рахунок в банківських установах.

Технологія взаєморозрахунків підприємств та організацій звичайно здійснюється за такою схемою.

Підприємство-платник отримує рахунок чи рахунок-фактуру на потрібний товар чи послугу, в якому вказані банківські реквізити продавця. Далі за цим документом формується платіжне доручення.

Платіжне доручення -- це розпорядження підприємства-платника банку здійснити переведення зазначеної суми з власного розрахункового рахунку на розрахунковий рахунок підприємства-покупця. Платіжне доручення має містити такі реквізити:

· номер платіжного доручення;

· дата;

· код за ЄДРПОУ підприємства-платника;

· назва підприємства-платника;

· банківські реквізити платника;

· код за ЄДРПОУ підприємства-одержувача;

· назва підприємства-одержувача;

· банківські реквізити платника;

· сума платежу;

· призначення платежу.

Платіжне доручення має бути надруковане в двох примірниках (іноді потрібно 3), на кожному з яких повинен стояти надпис "1 примірник", "2 примірник". Перший примірник завіряється підписами директора підприємства (організації) - платника та головного бухгалтера чи уповноваженими на це особами, а також печаткою підприємства-платника. Перший примірник залишається в банківській установі, а другий після здійснення платежу та штампування банком повертається підприємству як підтвердження здійснення оплати. Штамп банку містить назву банку, його МФО та дату, коли був здійснений платіж.

Платіжні доручення доставляються в банківську установу касиром підприємства в час, установлений банком для обслуговування клієнтів, віддаються операціоністу, який їх вводить в систему ОДБ. Крім проштампованих платіжних доручень, банк кожний день формує та віддає підприємству-клієнту виписку з розрахункового рахунку, яка містить інформацію про поточний стан розрахункового рахунку та про обіг коштів на ньому.

Виписка містить такі реквізити:

· дата формування виписки;

· час формування виписки;

· дата здійснення виписки;

· дата здійснення останньої (попередньої) операції по рахунку;

· назва та МФО банківської установи;

· назва клієнта;

· номер розрахункового рахунку клієнта;

· вхідний залишок;

· № документа, по якому здійснена операція;

· код документа;

· дані про кореспондента платежу (МФО, розрахунковий рахунок, назва);

· призначення платежу;

· ознака операції (кредитова чи дебетова);

· сума транзакції в грн.;

· сума кредитового та дебетового обороту за день;

· вихідний залишок на розрахунковому рахунку.

Слід зазначити, що цей перелік може відрізнятися в різних банківських установах, але в основному він залишається незмінним. Так, у виписку може не включатися назва кореспондента та призначення платежу. Це залежить від версії ОДБ, яка функціонує в банку. Наведений перелік є найбільш прийнятним і зручним для клієнта.

Виписка з розрахункового рахунку -- це один з найважливіших документів підприємства. На основі даних, які він містить, приймаються важливі рішення щодо діяльності підприємства та будь-які перевірки податкових органів. Слід сказати, що щоденна виписка -- це важливий показник фінансового стану підприємства. Тому дуже важливо отримувати її швидко і в зручній для користувача формі.

Тим клієнтам, що мають великі обсяги платіжних документів, для спрощення та оперативності їх оплати банк встановлює систему "Клієнт-банк". Крім платіжних доручень, за допомогою системи "Клієнт-банк" можна передавати будь-які платіжні документи: меморіальні ордери, касові документи, заяви на акредитив, відмови від акцепту та ін.

При застосуванні системи "Клієнт-банк" технологія безготівкових розрахунків змінюється.

Система дає змогу:

· перейти до безпаперової технології обробки інформації;

· оперативно управляти власним розрахунковим рахунком із свого офісу;

· уникнути подвійного введення інформації в банківській установі, зменшити допущення кількості помилок при введенні і підготовці документів, а також запобігти типових банківських ризиків (помилкові направлення платежів, загублення документів, їх фальсифікація та спотворення тощо);

· розширити час отримання послуг до повного банківського дня;

· забезпечити споживацькі якості ІС (функціональну повноту та своєчасність, адаптивну надійність, економічну ефективність).

Система "Клієнт-банк" має виконувати такі функції:

1. Підтримувати ведення баз даних нормативно-довідкової інформації.

2. Формувати та друкувати платіжні документи підприємства, а також документи, отримані з банку.

3. Формувати пачки документів у вигляді файлів для передачі їх в банк.

4. Приймати сформовані банком документи:

· квитанції по документах;

· виписки з розрахункових рахунків;

· файли змін, сформовані в банку для підприємства.

5. Забезпечувати зв'язок віддаленого робочого місця операціоніста на підприємстві з банком.

6. Забезпечувати комплексний захист інформації, що циркулює у мережах передачі даних, від несанкціонованого доступу за допомогою аутентифікації та криптографічного захисту.

7. В процесі прийому та передачі інформації формувати протокол, у якому фіксується інформація про отримані (підготовлені до передачі) файли, про результати перевірки ключів захисту інформації, про прийняті та передані повідомлення.

1.2 Технологія функціонування системи "Клієнт-банк"

Система "Клієнт-банк" складається з двох складових: банківського та клієнтського робочого місця.

На клієнтському робочому місці вводяться платіжні документи, формуються в пачки і записуються в базу даних АРМ клієнта в файл "Платіжних документів" (PD). Введеним та записаним в БД документам спочатку присвоюється статус, який дає змогу їх переглядати, переміщувати в інші пачки, друкувати, редагувати та вилучати. Для передачі платіжні документи підписуються електронним цифровим підписом (ЕЦП) головного бухгалтера.

Головний бухгалтер також має змогу до того, як поставив свій підпис, редагувати дані файлу PD. Перед тим, як підписати, бухгалтер позначає потрібні документи, вставляє дискету чи картку зі своїм індивідуальним ключем, який є закритим, і викликає відповідну функцію, яка ставить ЕЦП. Після успішного завершення функції підпису документа змінюється його статус, а також файл PD доповнюється певними символами, які ідентифікують підпис бухгалтера.

На другому етапі документи підписуються директором. З меню системи викликається відповідна функція, вставляється дискета чи картка з ключем директора і на екран видаються ті документи, які завірені підписом бухгалтера. Директор, переглядаючи платіжні документи, у разі необхідності має змогу вилучити деякі з них, а документи, готові до передачі, підписує. Після підпису директором файл доповнюється символами, які ідентифікують підпис директора. Далі файл шифрується і готується до передачі.

Підписані й зашифровані платіжні документи формуються в пакет і передаються з клієнтського робочого місця в банк засобами електронної пошти у вигляді текстового файлу типу R.

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

Після здійснення сеансу зв'язку з банком банківська частина системи, що знаходиться в банку, має сформувати транспортні квитанції (файл типу T) на платіжні документи й надіслати їх клієнту. Якщо при прийомі документів було виявлено помилки, файл типу Т містить коди помилок та інформацію тих платіжних документів, у яких вони виявлені. Якщо при передачі чи заповненні платіжних документів були допущені помилки, то банк до обробки їх не приймає. Клієнт повинен виправити помилки й ще раз зв'язатися з банком для відправки виправлених платіжних документів.

Якщо файл типу R не має помилок, про що свідчать нульові коди помилок у файлі типу Т, то він приймається банком до обробки. Кожний прийнятий банком до обробки платіжний документ аналізується, і йому присвоюється відповідний статус, який свідчить про те, на якій стадії банківської обробки перебуває той чи інший документ. Статус документа присвоює відповідальний працівник банку, за яким закріплені особові рахунки даного клієнта.

Відповідальний працівник має можливість: оплатити документ; у разі відсутності достатніх коштів розмістити документ в картотеці; відхилити документ від оплати й передати його на розгляд кредитному інспектору, головному бухгалтеру чи керуючому і т. п. Кожне рішення, яке може прийматись по платіжному документу, має відповідне кодове позначення, що зберігається в довіднику статусів платіжних документів.

На прийняті до обробки платіжні документи формується й передається клієнту файл-квитанція типу С про рух та оплату документів в банку. Цей файл містить дані кожного платіжного документа та дані про його статус, якщо ж документ був оплачений, то відповідно -- дані про вид акцепту, вид платежу. Разом з файлом типу С банк передає клієнту файли типу I та V, які є виписками з особових рахунків клієнта. Виписка I є поточною, а виписка V -- підсумковою.

У виписці I банк надає клієнту поточні дані щодо списання й зарахування коштів на особовий рахунок та залишок коштів на момент формування виписки. Крім того, поточна виписка включає всі документи, які були передані клієнтом в банк і надійшли на адресу клієнта. Поточна виписка має інформативний характер. Періодичність її формування оговорюється в договорі, який підписує клієнт з банком, і залежить від інформаційних потреб клієнта.

Підсумкова виписка дається щоденно по завершенні банківського дня і містить дані про обіг коштів за день та залишки коштів на рахунках на кінець дня.

При такій технології обміну платіжними документами в електронному вигляді банк потребує раз на тиждень подавати їх в паперовому вигляді, завіреними підписами директора і головного бухгалтера та печаткою підприємства.

Разом з паперовими документами клієнт повинен подавати в банк у роздрукованому вигляді щоденні реєстри переданих в банк та оплачених банком платіжних документів за допомогою системи "Клієнт-банк". Також раз на тиждень касир повинен доставляти в банк другі примірники вже оплачених платіжних документів, на яких у його присутності ставляться штампи банку, й забирати проштамповані виписки з рахунків клієнта. Ці виписки мають правову силу, оскільки вони завірені печаткою банку, а виписки, що їх можна отримати за допомогою системи "Клієнт-банк", мають лише інформативний характер. Вони хоч і містять достовірну інформацію, але правової сили не мають.

Усі файли, що були сформовані чи прийняті системою "Клієнт-банк", архівуються і зберігаються в архіві.

Крім обміну платіжними документами, квитанціями та виписками, за допомогою системи "Клієнт-банк" клієнт може отримати файли внесення змін до бази даних нормативно-довідкової інформації, а також по запиту допоміжні файли довідково-інформативного характеру, що містять дані про курси валют, котировки цінних паперів на фондовій біржі тощо.

Розділ 2. Проектування і розробка інформаційно-пошукової системи

2.1 Перегляд і аналіз методів проектування ІС

Постановка і опис задачі

Постановка задачі є одним з ключових етапів при розробці будь-якого програмного продукту . Це етап на якому велику роль приділяють визначенню кінцевої мети, а також глибокому і чіткому аналізу об'єктів предметної області.

Темою моєї дипломної роботи є інформаційно-пошукова система «Клієнти банку». Проаналізувавши дану тему, можна виділити основні функції майбутньої інформаційної системи, що буде використовуватись операціоністом для ведення даних про клієнтів, а саме анкетні дані , рахунки та їх стан. Також необхідно передбачити зручний та інтуїтивно зрозумілий інтерфейс програми для операціоніста. Проектування БД починається з аналізу предметної області і виявлення вимог до неї. Дана АІС повинна забезпечувати:

- організацію зручного діалогу з операціоністом;

- ведення складу користувачів;

- ведення даних користувачів.

Необхідно щоб АІС містила основну інформацію, завдяки якій можна отримати всю необхідну інформацію про клієнта, а саме: особисту інформацію, документ, адресу проживання, сімейний стан, освіту, володіння майном, працевлаштування. Всі накопичені дані програми зберігаються в файлі «БД Клієнти банку.gdb». База даних створена по загальній інформації клієнтів банку , які внесені в таблиці між якими встановлений зв'язок по ключових стовпцях. Структура файлу представляє собою масив записів з наступними таблицями і полями до цих таблиць.

Таблиця «Особиста» має 20 полів:

- код клієнта;

- прізвище;

- ім'я ;

- по батькові;

- дата народження;

- ІНН;

- дівоче прізвище;

- область;

- місто;

- вулиця;

- будинок;

- корпус;

- квартира;

- мобільний телефон;

- робочий телефон;

- E-mail;

- Skype;

- код освіти;

- код майна.

Таблиця «Паспорт» має 5 полів:

- серія;

- номер;

- ким виданий;

- дата видачі.

Таблиця «Проживання» має 7полів:

- код клієнта;

- область;

- місто;

- вулиця;

- будинок;

- квартира.

Таблиця «Сімейний стан» має 9 полів:

- код клієнта;

- не був(ла);

- розлуче-ний(на);

- вдовець\вдова;

- ПІБ жінки\чоловіка;

- дата народження;

- працевлаштування.

Таблиця «Працевлаштування» має 11 полів:

- код клієнта;

- код статусу;

- назва команії;

- посада;

- код форми власності;

- код індустрії;

- код службового стану;

- заробітна плата основна;

- заробітна плата додаткова;

- інший банк.

Таблиця «Освіта» має 2 поля:

- код освіти;

- тип.

Таблиця «Майно» має 2 поля:

- код майна;

- тип.

Таблиця «Соціальний статус» має 2 поля:

- код статусу;

- назва.

Таблиця «Форма власності» має 2 поля:

- код форми;

- назва .

Таблиця «Індустрія праці» має 2 поля:

- код індустрії;

- назва.

Таблиця «Службовий стан» має 2 поля:

- код службового стану;

- назва .

Таблиця «Додатковий дохід» має 2 поля:

- код доходу;

- назва .

Таблиця «Тип карти» має 2 поля:

- код типу;

- назва .

Вхідна інформація - інформація, що вводиться до оброблення;

Вихідною інформацією буде сформована база даних, що буде містити інформацію, яка дозволить операціоністу бути повністю ознайомленим з інформацією про клієнтів. Вихідною інформацією будуть всі накопичені дані, що міститимуться в створеній БД "Клієнти банку".

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

2.2 Створення інфологічної моделі

Після аналізу предметної області створюють узагальнений неформальний опис утворювальної БД, цей опис який виконується з використанням математичних формул, таблиць, графіків, природної мови і називають інфологічною моделлю даних. Інфологічний рівень являє собою інформаційно-логічну модель (ІЛМ) предметної області, в якій виключена надмірність даних і відображені інформаційні особливості об'єкту управління, без урахування особливостей і специфіки конкретної СКБД.

Мета інфологічного проектування -- створити структуровану інформаційну модель предметної області , для якої розроблятиметься БД. Під час проектування на інфологічному рівні створюється інформаційно-логічна модель, яка має відповідати таким вимогам:

- коректність схеми БД, тобто адекватне відображення модельованої ПО;

- простота і зручність використання на наступних етапах проектування, тобто ІЛМ має легко відображатися в моделі БД, що підтримується відомими СКБД (сіткові, ієрархічні, реляційні);

- ІЛМ має бути описана мовою, зрозумілою проектувальникам БД, програмістам, адміністратору і майбутнім користувачам АБ.

Основною складовою інфологічної моделі є атрибути, які потрібно проаналізувати і деяким чином згрупувати для подальшого зберігання в БД.

Для побудови інфологічної моделі даних перш за все необхідно нормалізувати створені відношення. Нормалізовані відношення мають вид:

Таблиця «Особиста інформація» має 20 полів:

КЛІЄНТ(Код, Прізвище, Ім'я, По_батькові, Дата_народження, ІНН, Дівоче_прізвище,Область,Місто,Вулиця,Будинок,Корпус,Квартира,Мобільний_телефон,Домашній_телефон,Робочий_телефон,Email,Skype,Код_освіти,Код_майн

ПАСПОРТ(Код, Серія, Номер, Ким_виданий, Дата_видачі)

ПРОЖИВАННЯ(Код, Область, Місто, Вулиця, Будинок, Квартира)

СІМЕЙНИЙ СТАН(Код_клієнта,Не був,Розлуче-ний(на),Вдовець\вдова, Кількість_дітей, ПІБ жінки\чоловіка, Дата_народження,Телефон, Працевлаштування )

ПРАЦЕВЛАШТУВАННЯ(Код_клієнта,Код_статусу,Назва_команії,Посада,Код_форми_власності,Код_індустрії,Код_службового_стану,Заробітна_плата_основна,Заробітна_плата_додаткова,Інший_банк)

ОСВІТА(Код_освіти,Тип)

МАЙНО(Код_майна,Тип)

СОЦІАЛЬНИЙ СТАТУС(Код_статусу,Назва)

ФОРМА ВЛАСНОСТІ(Код_форми,Назва)

ІНДУСТРІЯ ПРАЦІ(Код_індустрії,Назва)

СЛУЖБОВИЙ СТАН(Код_службового_стану,Назва)

ДОДАТКОВИЙ ДОХІД(Код_доходу,Назва)

ТИП КАРТИ(Код_типу,Назва)

Основними елементами інфологічного моделювання є сутності, зв'язки між ними і їх властивості, тобто атрибути:

Сутність - це будь-який об'єкт, який ми можемо відрізнити від іншого, інформацію по який необхідно зберігати.

Зв'язок - це асоціювання двох, або більше сутностей.

Атрибут - поіменована характеристика сутності.

Домен - стовбець таблиці.

Для даного курсового проекту сутностями є ОСОБИСТА, ПАСПОРТ, ПРОЖИВАННЯ, СІМЕЙНИЙ СТАН, ПРАЦЕВЛАШТУВАННЯ, ОСВІТА, МАЙНО, СОЦІАЛЬНИЙ СТАТУС, ФОРМА ВЛАСНОСТІ, ІНДУСТРІЯ ПРАЦІ,СЛУЖБОВИЙ СТАН, ДОДАТКОВИЙ ДОХІД,ТИП КАРТИ.

Характерною сутністю є «Особиста інформація».

2.3 Створення датологічної моделі

На етапі даталогічного проектування здійснюється перехід від інфологічної моделі ПО до логічної (даталогічної) моделі, яка підтримується засобами конкретної бази даних(БД). Процес переходу від інфологічної до даталогічної моделі називається відображенням. Даталогічна модель являє собою базу даних, структуровану на логічному рівні й орієнтовану на конкретну БД. Кожна конкретна БД накладає ряд обмежень на побудову логічної моделі даних, тому насамперед необхідно вивчити специфіку і особливості БД, виявити всі фактори, які можуть вплинути на логічну модель БД.

Рисунок 2.3.1 Датологічна модель задачі»Клієнти Банку»

2.4 Система програмування Delphi

Інтегроване середовище Delphi складається з чотирьох основних елементів:головне вікно, вікно інспектора об'єктів, вікно форми та вікно модуля.

Головне вікно має заголовок Delphi- Project1. Це вікно містить головне меню, панель кнопок швидкого доступу і палітру компонент. Головне меню - стандартне меню в стилі Windows. Це меню дозволяє керувати всіма аспектами роботи в Delphi. Рядок меню можна налаштувати за власним бажанням, наприклад додати власні елементи до пункту меню інструментів Tools.

Кнопки і гарячі клавіші.

Кнопки використовуються для швидкого доступу до найнеобхідніших пунктів меню. Вони розташовані в лівій частині екрану на панелі швидкого доступу. Серед них є кнопки для компіляції і запуску програм, для перегляду вихідного коду рядок за рядком тощо.

Палітра компонент - це каталог візуальних і не візуальних об'єктів , які можна включати до власних форм та програм.

Вікно форми.

Вікно, яке ми бачимо в центрі, називається формою. У цьому вікні проходить основна частина роботи по проектуванню програми. Деякі елементи у вікні форми(лінії сітки, не візуальні компоненти) не будуть видимими під час виконання програми. Але, оскільки Delphi - це середовище програмування типу WYSIWYG(що бачите, те й отримаєте), то більша частина того, що ми бачимо під час проектування є тим, що ми побачимо під час виконання програми.

Вікно коду.

На малюнку це вікно перекрито вікном форми. Це вікно працює аналітично до простого текстового редактора. Можна використовувати Pg Up і Pg Dn , клавіші курсору, мишу можна виділити, скопіювати, вставити текст за допомогою меню EDIT і відповідних гарячих клавіш.

Інспектор об'єктів.

Інспектор об'єктів або Object Inspector як правило знаходиться в лівій частині екрану і містить інформацію про виділений об'єкт. Інспектор об'єктів складається з таких елементів: комбінованої панелі (ComboBox) вибору об'єкту;сторінки властивостей (PropertiesPage) та сторінки подій (EventsPage) вибраного об'єкту. У інспекторі об'єктів описані всі властивості об'єкту і його використовують для зміни їхніх властивостей. Крім того за допомогою інспектора об'єктів можна переглядати та змінити всі події, що пов'язані з виділеним об'єктом.

Управління файлами проекту Delphi.

Проект - це сукупність вихідних файлів для всієї програми в цілому. Основні дії з проектом (відкрити,зберегти,створити) доступні через пункт меню File. Виконати програму можна через меню Run за допомогою клавіші F9 чи відповідної кнопки на панелі швидкого доступу.

Пересування по Delphi.

У середовищі програмування Delphi не передбачено пункт меню Window. Тому для активації потрібного вікна можна використати:

- меню View\Object Inspector - перехід у вікно інспектора об'єктів;

- меню View\Window List - список всіх вікон, з якого можна вибрати потрібне;

- кнопку Toggle Form\Unit на панелі швидкого доступу - активізація форм і вихідних модулів поточного проекту;

- кнопки Select Unit from List і Select Form from List, якщо в проекті існує кілька форм і модулів, дозволяють продивитися списки цих форм та модулів.

У Delphi багато можливостей налаштування середовища. Можна конфігурувати палітру компонент, меню панель кнопок швидкого доступу, галерею, редактор коду, різні опції проекту, інструмент перегляду (Browser). Більшість опцій налаштування доступна через пункт меню Options.

Для розв'язку цієї задачі використовувалася операційна система Windows XP.

Windows XP (кодова назва при розробці -- Whistler; внутрішня версія Windows NT 5.1) -- операційна система сімейства Windows NT від компанії Microsoft.

Вона була випущена 25 жовтня 2001 року і є розвитком Windows 2000 Professional. Назва XP походить від англ. experience (досвід, враження, від прикметника професійний). Назва увійшла до практики використання, як професійна версія.

На відміну від попередньої системи Windows 2000, яка поставлялася як в серверному, так і в клієнтському варіантах, Windows XP є виключно клієнтською системою. Її серверним варіантом є випущена пізніше система Windows Server 2003. Windows XP і Windows Server 2003 побудовані на основі одного і того ж ядра операційної системи, в результаті їхній розвиток і оновлення йде більш-менш паралельно.

Інтерфейс командного рядка (CLI)

Windows XP також має інтерфейс командного рядка (CLI, «консоль»), cmd.exe, для управління системою командами з консолі або запуску сценаріїв, званих «командними файлами» (з розширеннями cmd), заснованими на «пакетних» (batch) файлах MS-DOS.

2.5 Застосування мови UML до проектування інформаційної системи

Уніфікована мова моделювання UML (Unified Modeling Language) є мовою для визначення, подання, проектування і документування програмних систем, організаційно-економічних систем, технічних систем та інших систем різної природи. UML містить стандартний набір діаграм і нотацій найрізноманітніших видів.

UML є мовою широкого профілю, це відкритий стандарт який використовує графічні позначення для створення абстрактної моделі системи яка називається UML моделлю. Мова UML була створена для визначення, візуалізації, проектування та документування в основному програмних систем. UML не є мовою програмування, але в засобах виконання UML моделей які інтерпретуються коду можлива кодогенерація. UML це мова яка допомагає створити модель яка відображає проблему що вирішується всіми учасниками задіяними в реалізації проекту на різних етапах, а саме замовнику, експерту, аналітику, проектувальнику, автору документації, програмісту та інше. Мова UML використовується для візуального моделювання.

Візуальне моделювання - це спосіб представлення ідеї і проблеми реального світу за допомогою моделей. Моделювання забезпечує більш точну оцінку необхідних ресурсів, чітке опрацювання планів і ефективне функціонування створюємих систем. Використання UML не обмежується моделюванням ПЗ. Його також використовують для моделювання бізнес проектів, системного проектування і відображення організаційних структур. Основою мови UML є діаграма.

Діаграма - це проста графічна проекція елементів, які утворюють систему. При моделювання реальних систем в візуальному моделюванні UML використовуються наступні види діаграм. Всі вони поділяються на дві основні групи: структурні та поведінки. До структурних належать:

- діаграма класів;

- діаграма об'єктів;

- діаграма компонентів;

- діаграма розгортання;

- діаграма кооперації;

- діаграма пакетів;

- діаграма профілю.

До діаграм поведінки:

- діаграма діяльності;

- діаграма станів;

- діаграма прецедентів;

- діаграма взаємодії, в свою чергу поділяється на:

- діаграма комунікації;

- діаграма кооперації;

- діаграма огляду взаємодії;

- діаграма послідовності;

- діаграма синхронізації.

Діаграма класів описує структуру системи, вона демонструє класи системи, їхні атрибути, методи і залежності між класами. Діаграма складеної структури (композитивна) демонструє внутрішню структуру класів і по можливості взаємодію внутрішніх частин класу. Діаграма об'єктів демонструє повний або частковий знімок моделюємої системи в заданий момент часу. На діаграмі об'єктів відображаються екземпляри класів якими є об'єкти, системи із вказанням поточних значень іх атрибутів і зв'язків між об'єктами. Діаграми пакетів містять пакети і відносини між ними . Ці діаграми служать в першу чергу для організації елементів у групи по якій не будь ознаці з метою спрощення структури і організацією роботи моделі системи. Діаграма компонентів показує розбиття програмної системи на структурні компоненти та зв'язки між компонентами, як фізичні компонентами можуть виступати файли, модулі, бібліотеки,як виконавчі - це пакети, файли і тд.( Рисунок 2.5.1)

Рисунок 2.5.1 Діаграма компонентів інформаційної системи «Клієнти банку»

Діаграма прецедентів -- в UML, діаграма, на якій зображено відношення між акторами та прецедентами в системі. Також, перекладається як діаграма варіантів використання.

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



Рисунок 2.5.2 Діаграма прецедентів інформаційної системи «Клієнти банку»

Діаграма розгортання служить для моделювання працюючих вузлів і артефактів розгорнутих даних.

Рисунок 2.5.3 Діаграма розгортання інформаційної системи «Клієнти банку»

Розділ 3. Економіка

1) Передбачуване число операторів - 1646.

2) Коефіцієнт складності програми - 1,5.

3) Коефіцієнт корекції програми в ході її розробки - 0,7.

4) Коефіцієнт збільшення витрат праці внаслідок недостатнього опису задачі - 1,3.

5) Коефіцієнт кваліфікації програміста - 0,8.

6) Середня годинна заробітна плата програміста - 89,29 грн/год.

7) Вартість машино-годин ЕОМ - 5,28 грн/год.

3.1. Визначення трудомісткості розробки програмного забезпечення

Трудомісткість розробки ПЗ можна розрахувати за формулою:

людино-годин

де t_о - витрати праці на підготовку й опис поставленої задачі (приймається 50);

t_и - витрати праці на дослідження алгоритму рішення задачі;

t_а - витрати праці на розробку блок-схеми алгоритму;

t_п - витрати праці на програмування по готовій блок-схемі;

t_отл - витрати праці на налагодження програми на ЕОМ;

t_д - витрати праці на підготовку документації.

t = 50 + 87,44 + 228,11 + 228,11 + 1192,41 + 540,1 = 2326,17 людино-годин

Складові витрати праці визначаються через умовне число операторів у ПЗ, яке розробляється.

Умовне число операторів (підпрограм):

Q = q • C • (1+p),

де q - передбачуване число операторів;

C - коефіцієнт складності програми (в інтервалі від 1.25 до 2.0);

p - коефіцієнт корекції програми в ході її розробки (в інтервалі від 0.05 до 1).

Q = 1646 • 1,5 (1+0,7) = 4197,3

Витрати праці на вивчення опису задачі t_и визначається з урахуванням уточнення опису і кваліфікації програміста:

людино-годин,

де B - коефіцієнт збільшення витрат праці внаслідок недостатнього опису задачі (в інтервалі від 1.2 до 1.5);

k - коефіцієнт кваліфікації програміста, обумовлений від стажу роботи з даної спеціальності.

Таблиця 3.1 - Значення коефіцієнта кваліфікації програміста

Стаж програміста	Значення коефіцієнта k
до 2-х років	0,8
від 2 до 3 років	1,0
від 3 до 5 років	1,1 … 1,2
від 5 до 10 років	1,2 … 1,3
понад 10 років	1,3 … 1,5

людино-годин

Витрати праці на розробку алгоритму рішення задачі:

людино-годин

людино-годин

Витрати на складання програми по готовій блок-схемі:

людино-годин

людино-годин

Витрати праці на налагодження програми на ЕОМ:

– за умови автономного налагодження одного завдання:

людино-годин

людино-годин

– за умови комплексного налагодження завдання:

людино-годин

людино-годин

Витрати праці на підготовку документації:

людино-годин

людино-годин,

де t_{др -} трудомісткість підготовки матеріалів і рукопису.

людино-годин

людино-годин,

t_до - трудомісткість редагування, печатки й оформлення документації

людино-годин

людино-годин

3.2 Витрати на створення програмного забезпечення

Витрати на створення ПЗ К_по включать витрати на заробітну плату виконавця програми З_ЗП і витрат машинного часу, необхідного на налагодження програми на ЕОМ.

грн.

грн.

Заробітна плата виконавців визначається за формулою:

грн.

де t - загальна трудомісткість, людино-годин;

С_пр - середня годинна заробітна плата програміста, грн/година

грн.

Вартість машинного часу, необхідного для налагодження програми на ЕОМ:

грн.,

де t_отл - трудомісткість налагодження програми на ЕОМ, год.

С_мч - вартість машино-годин ЕОМ, грн/год.

грн.

Визначені в такий спосіб витрати на створення програмного забезпечення є частиною одноразових капітальних витрат на створення АСУП.

Очікуваний період створення ПЗ:

міс.,

де B_k - число виконавців;

F_p - місячний фонд робочого часу (при 40-годинному робочому тижні F_p=176 годин).

міс.

Висновок: при розробці програмного забезпечення для моделювання інформаційно-пошукової системи «Клієнт-банк» витрати на його створення склали 100638,37 грн. та очікуваний період створення - 13,2 місяців.

Висновки

В результаті виконання даного дипломного проекту було створено автоматизовану інформаційну систему «Клієнти банку». Було розроблено програмний продукт, який може накопичувати, та обробляти дані про клієнтів банку. Програма має доступний, інтуїтивно зрозумілий та водночас офіціальний інтерфейс. Було розроблено продукт який має два режими користування (адміністратора та користувача), передбачено можливість зручної навігації по програмі.

ІС «Клієнт-банк» забезпечує виконання наступних функцій:

1) фільтрація даних;

2) пошук та друк інформції;

3) формування статистики:

визначення освіти клієнтів;

визначення адреси проживання клієнтів.

Обов'язковим елементом є реалізація можливості додання та видалення записів з таблиць.

Поставлені цілі на початку проектування виконані в повній мірі. Розроблений програмний продукт цілком відповідає критеріям ефективності і зручності використання програмних засобів для керування базами даних, а значить може бути віднесений до класу автоматизованих інформаційних систем.

Перелік використаних джерел

1. Когаловский М.Р. Энциклопедия технологий баз данных. - М.: Финансы и статистика, 2012.

2. Сорокин А.А., Романова Е. В. CASE - технология проектирования информационных систем. М.: МЭСИ, 2009

3. Вейскас Д. Эффективная работа с Microsoft Access 2003. - СПб: Питер Ком, 2005. - 976 с.

4. Вендров А.М. CASEтехнологии. Современные методы и средства проектирования информационных систем. М.: Финансы и статистика, 2005

5. Мишенин, А.И. Теория экономических информационных систем: Учеб. для вузов / А.И. Мишенин.- 4-е изд., доп. и перераб. -М. : Финансы и статистика, 2008. - 240 с. : ил.

6. Гурвиц Г. Разработка реального приложения в среде клиент-сервер. - «ДВГУПС», 2005. - 120 с.

7. Дейт К. Введение в системы баз данных/Пер. с англ. М.:Наука, 2008. 463 с.

8. Домарев В.В. Защита информации и безопасность компьютерных систем. - К.: «ДиаСофт», 2009. - 480 с.

9. Ирвин М., Праг К. Access 2000. Библия пользователя. - М.: «Диалектика», 2000. - 1040 с.

10. Майнази М. Windows XP Professional. - М.: «Лори», 2003. - 766 с.

11. Липаев В.В Управление разработкой программных средств. Методы, стандарты, технология. - М.: Финансы и статистика, 2003.

12. Оскерко В.С., Пунчик З.В. Практикум по технологиям баз данных. - Мн.: «БГЭУ», 2009. - 170 с.

13. Паронжанов С. Объектно-ориентированные средства анализа и проектирования информационных систем. - М.: Учебные материалы конференции «Индустрия программирования 96». 1996 г. с.117-123.

14. Фуфаев Д.Э., Фуфаев Э.В. Базы данных. - М.: «Академия», 2005. - 320 с.

15. Немет Э., Снайдер Г., Сибасс С., Хейн Т. Р., // Н50 UNIX: Руководство системного администратора. / Пер. с англ. - СПб.: Питер; К.:Издательская група BHV, 2002. - 928 c.: ил.

16. Армстронг (мл.), Джеймс // А83 СекретыUNIX: 2-е изд.: Пер. с англ. - М.: Издательскийдом «Вильямс», 2001. - 1072 с.: ил. - Парал. тит. англ.

17. Автор: Грег Риккарди - Системы баз данных. Издательство: Вильямс Год: 2001.

18. Автор: А. Наумов - Системы управления базами данных и знаний Издательство: Финансы и статистика Год: 1991.

19. Автор: С. В. Глушаков, Д. В. Ломотько - Базы данных Издательство: АСТ Год: 2002.

20. Вендров А.М. CASEтехнологии. Современные методы и средства проектирования информационных систем. М.: ФиС, 2000

21. Вендров А.М. Проектирование программного обеспечения экономических информационных систем. М.: ФиС, 2000. 350 с.

22. Гарнаев А.Ю. Excel, VBA в экономике и финансах. СПб.: БХВ-Петербург, 2002. 816с.

23. Леоненков А.В. Самоучитель UML. М.: «Метатехнология», 2001 Запольскис А. Самоучитель MS Access 2000.

24. Бойко В.В. Экономика предприятий Украины. Основной курс: Учебник для вузов. - Д.: Пороги, 1997. - 312 с.

25. Бусыгин А.В. Предпринимательство. Основной курс: Учебник для вузов. - М.: ИНФРА-М, 1997. - 608 с.

26. Котлер Ф. Основы маркетинга: Пер. с англ. / Общ. Ред. и вступ. ст. Е.М. Пеньковой - М.: Прогресс, 1990. - 636с.

27. Мескон М.Х., Альберт М., Хедоури Ф. Основы менеджмента. - М.: Дело, 1992. - 702 с.

Додаток А

Код програми і запитів

Програмний модуль форми «Банк»

unit Unit1;

interface

uses

Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,

Dialogs, Menus, XPMan, StdCtrls, Buttons, Mask, jpeg, ExtCtrls;

type

TForm1 = class(TForm)

MainMenu1: TMainMenu;

XPManifest1: TXPManifest;

GroupBox1: TGroupBox;

Label1: TLabel;

Label2: TLabel;

ComboBox1: TComboBox;

MaskEdit1: TMaskEdit;

BitBtn1: TBitBtn;

GroupBox2: TGroupBox;

BitBtn2: TBitBtn;

BitBtn3: TBitBtn;

BitBtn4: TBitBtn;

BitBtn5: TBitBtn;

GroupBox3: TGroupBox;

BitBtn6: TBitBtn;

BitBtn7: TBitBtn;

N1: TMenuItem;

Image1: TImage;

procedure N3Click(Sender: TObject);

procedure N1Click(Sender: TObject);

procedure pfgbn1Click(Sender: TObject);

procedure N4Click(Sender: TObject);

procedure BitBtn2Click(Sender: TObject);

procedure BitBtn3Click(Sender: TObject);

procedure BitBtn4Click(Sender: TObject);

procedure BitBtn5Click(Sender: TObject);

procedure BitBtn1Click(Sender: TObject);

procedure FormCreate(Sender: TObject);

procedure BitBtn6Click(Sender: TObject);

procedure BitBtn7Click(Sender: TObject);

private

{ Private declarations }

public

{ Public declarations }

end;

var

Form1: TForm1;

implementation

uses unit3,unit9,unit10,unit11;

{$R *.dfm}

procedure TForm1.N3Click(Sender: TObject);

begin

form3.Show;

end;

procedure TForm1.N1Click(Sender: TObject);

begin

GroupBox1.Visible:=true;

GroupBox2.Visible:=false;

GroupBox3.Visible:=false;

end;

procedure TForm1.pfgbn1Click(Sender: TObject);

begin

form10.show;

end;

procedure TForm1.N4Click(Sender: TObject);

begin

form11.Show;

end;

procedure TForm1.BitBtn2Click(Sender: TObject);

begin

form3.Show;

end;

procedure TForm1.BitBtn3Click(Sender: TObject);

begin

Form11.Show;

end;

procedure TForm1.BitBtn4Click(Sender: TObject);

begin

Form10.Show;

end;

procedure TForm1.BitBtn5Click(Sender: TObject);

begin

form9.Show;

end;

procedure TForm1.BitBtn1Click(Sender: TObject);

begin

if (combobox1.Text = 'Адміністратор') and (maskedit1.Text = '123654') then

begin

GroupBox1.Visible:=false;

GroupBox2.Visible:=true;

GroupBox3.Visible:=false;

end;

if (combobox1.Text = 'Користувач') and (maskedit1.Text = '123') then

begin

GroupBox1.Visible:=false;

GroupBox2.Visible:=false;

GroupBox3.Visible:=true;

end;

end;

procedure TForm1.FormCreate(Sender: TObject);

begin

GroupBox2.Visible:=false;

GroupBox3.Visible:=false;

maskedit1.Text :='';

end;

procedure TForm1.BitBtn6Click(Sender: TObject);

begin

form3.Show;

end;

procedure TForm1.BitBtn7Click(Sender: TObject);

begin

form10.Show;

end;

end.

Програмний модуль форми «DM»

unit Unit2;

interface

uses

SysUtils, Classes, DB, ADODB;

type

TDM = class(TDataModule)

Privat: TADOConnection;

ADOinform: TADOTable;

DSinform: TDataSource;

ADOpasport: TADOTable;

DSpasport: TDataSource;

ADOlive: TADOTable;

DSlive: TDataSource;

ADOwork: TADOTable;

DSwork: TDataSource;

ADOfamily: TADOTable;

DSfamily: TDataSource;

ADOwish: TADOTable;

DSwish: TDataSource;

ADOstudy: TADOTable;

DSstudy: TDataSource;

ADOmayno: TADOTable;

DSmayno: TDataSource;

DScard: TDataSource;

DSsocial: TDataSource;

DSforma: TDataSource;

DSindustr: TDataSource;

DSsluzbStan: TDataSource;

DSdodDoxid: TDataSource;

ADOcard: TADOTable;

ADOforma: TADOTable;

ADOindustr: TADOTable;

ADOsluzbStan: TADOTable;

ADOdodDoxid: TADOTable;

ADOsocial: TADOTable;

ADOsocialDSDesigner: TWideStringField;

ADOsocial__: TAutoIncField;

sql_all_info: TADOQuery;

DSsql_all_info: TDataSource;

sql_work: TADOQuery;

DSsql_work: TDataSource;

sql_wish: TADOQuery;

DSsql_wish: TDataSource;

ADOwork_: TIntegerField;

ADOwork_2: TIntegerField;

ADOwork_3: TWideStringField;

ADOworkDSDesigner: TWideStringField;

ADOwork__: TIntegerField;

ADOwork__2: TIntegerField;

ADOwork__3: TIntegerField;

ADOwork__4: TDateTimeField;

ADOwork__5: TBCDField;

ADOwork__6: TIntegerField;

ADOwork_4: TBooleanField;

sql_all_info_: TAutoIncField;

sql_all_infoDSDesigner: TWideStringField;

sql_all_infoDSDesigner2: TWideStringField;

sql_all_info_2: TWideStringField;

sql_all_info_3: TDateTimeField;

sql_all_infoDSDesigner3: TFloatField;

sql_all_infoDSDesigner4: TWideStringField;

sql_all_infoDSDesigner5: TWideStringField;

sql_all_infoDSDesigner6: TWideStringField;

sql_all_infoDSDesigner7: TIntegerField;

sql_all_infoDSDesigner8: TWideStringField;

sql_all_infoDSDesigner9: TIntegerField;

sql_all_info_4: TFloatField;

ADOinform_: TAutoIncField;

ADOinformDSDesigner: TWideStringField;

ADOinformDSDesigner2: TWideStringField;

ADOinform_2: TWideStringField;

ADOinform_3: TDateTimeField;

ADOinformDSDesigner3: TFloatField;

ADOinform_4: TWideStringField;

ADOinformDSDesigner4: TWideStringField;

ADOinformDSDesigner5: TWideStringField;

ADOinformDSDesigner6: TWideStringField;

ADOinformDSDesigner7: TIntegerField;

ADOinformDSDesigner8: TWideStringField;

ADOinformDSDesigner9: TIntegerField;

ADOinform_5: TFloatField;

ADOinform_6: TFloatField;

ADOinform_7: TFloatField;

ADOinformEmail: TWideStringField;

ADOinformSkype: TWideStringField;

ADOinform_8: TIntegerField;

ADOinform_9: TIntegerField;

ADOinformField: TStringField;

ADOinformField2: TStringField;

sql_wish_: TIntegerField;

sql_wishDSDesigner: TWideStringField;

sql_wishDSDesigner2: TWideStringField;

sql_wish__150_: TBooleanField;

sql_wish_2: TDateTimeField;

ADOworkField: TStringField;

ADOworkField2: TStringField;

ADOworkField3: TStringField;

ADOworkField4: TStringField;

ADOworkField5: TStringField;

ADOwish_: TIntegerField;

ADOwish_2: TIntegerField;

ADOwishDSDesigner: TWideStringField;

ADOwish__150_: TBooleanField;

ADOwish_3: TDateTimeField;

ADOwishField: TStringField;

sql_delete: TADOQuery;

private

{ Private declarations }

public

{ Public declarations }

end;

var

DM: TDM;

implementation

{$R *.dfm}

end.

Програмний модуль форми «Особова інформація»

unit Unit3;

interface

uses

Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,

Dialogs, StdCtrls, DBCtrls, ComCtrls, Mask, Buttons;

type

TForm3 = class(TForm)

BitBtn1: TBitBtn;

BitBtn2: TBitBtn;

GroupBox1: TGroupBox;

DBEdit1: TDBEdit;

DBEdit2: TDBEdit;

DBEdit3: TDBEdit;

DateTimePicker1: TDateTimePicker;

DBEdit4: TDBEdit;

DBEdit5: TDBEdit;

DBEdit6: TDBEdit;

DBEdit7: TDBEdit;

DBEdit8: TDBEdit;

DBEdit9: TDBEdit;

DBEdit10: TDBEdit;

DBEdit11: TDBEdit;

DBEdit12: TDBEdit;

DBEdit13: TDBEdit;

DBEdit14: TDBEdit;

DBEdit15: TDBEdit;

DBEdit16: TDBEdit;

DBLookupComboBox1: TDBLookupComboBox;

...