Реферати українською » Информатика, программирование » Розробка багатокористувацької інформаційної системи ведення документації по оренді


Реферат Розробка багатокористувацької інформаційної системи ведення документації по оренді

Страница 1 из 2 | Следующая страница

>КУРСОВОЙ ПРОЕКТ

Тема: «Розробкамногопользовательской інформаційної системи ведення документації за оренду »


Зміст

Запровадження

1. Технічне завдання.

1.1 Аналіз предметної області.

1.2 Постановка завдання.

2. Технічний проект.

2.1 Функціональна модель

2.1.1Контекстная діаграма і діаграми деталізації процесів.

2.1.2 Діаграма дерева вузлів.

2.2 Інформаційна модель.

2.2.1 Ідентифікація сутностей і зв'язків.ER-диаграмма логічного рівня.

2.2.2 Нормалізація схеми даних. Дозвіл неспецифічних відносин. Уточнення типів даних для атрибутів схем відносин. Реалізаціяссилочной цілісності. Проектування індексів.ER-диаграмма фізичного рівня.

2.3 Емпірична перевірка логічного моделі системи.

3 Реалізація системи.

3.1 Опис програмного забезпечення, розробленого в архітектурі «клієнт - сервер».

3.2SQL-определения регламентованих запитів і уявлень.

4 Дослідження операційних характеристикИСС.

4.1 Опис бази даних контрольного прикладу.

4.2 Аналіз результатів тестуванняИСС.

5 Перелік графічного матеріалу

5.1Функциональние діаграми першого і другого рівнів.

5.2ER-диаграмма схеми бази даних фізичного рівня.

5.3 Діаграма дерева вузлів функціональної моделі.

Укладання

Список використаних літературних джерел


Запровадження

Проблема накопичення, зберігання, отримання швидкого доступу і автоматизації опрацювання великих обсягів інформації виникла досить давно. З метою її у час вже створені і отримали стала вельми поширеною різні системи управління базами даних (>СУБД). У тому числі виділяютьсяParadox,dBase,FoxPro, Oracle іAccess.

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

Як системи управлінняреляционними базами даних, за завданням на курсової проект, заданийAccess 2000, якCASE-средств концептуального проектування баз даних -ERwin 4.0 і функціонального моделювання –BPwin 4.0.

 


1. Технічне завдання

1.1 Аналіз предметної області

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

>Ведением даної документації займається економічний й цілком юридичне відділи.

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

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

1.2 Постановка завдання

Завданням даного курсового проекту є реалізація інформаційної системи.

>Моделируемая інформаційна система коштує варта ведення документації за оренду, саме покликана вирішувати такі практичні завдання:

введення і збереження відомостей про орендарях, приміщеннях, ув'язнених договорах;

складання розрахункової калькуляції;

складання звіту про прибутку;

контроль своєчасної оплатою оренди;

складання списку укладених угод, відповідних орендарів і приміщень;


2. Технічний проект

2.1 Функціональна модель

Для проведення аналізу та функціонального проектування інформаційної системи використовується CASE – засібBpwin.Bpwin підтримує три методології:IDEF0,DFD іIDEF3, дозволяють аналізувати організаційну систему.

Інформаційна система функціонує так.

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

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

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

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

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


2.1.1Контекстная діаграма і діаграми деталізації процесів

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

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

малюнок 1 –Контекстная діаграма.

Функціональна модель (діаграми першого і другого рівнів) аналізованої інформаційної системи зображено при застосуванні 5.1.

2.1.2 Діаграма дерева вузлів

Діаграма дерева вузлівмоделируемой інформаційної системи зображено при застосуванні 5.2. Тут представлені ієрархічні залежностімоделируемих процесів.


2.2 Інформаційна модель

 

2.2.1 Ідентифікація сутностей і зв'язків.ER-диаграмма логічного рівня

Для відображення інформаційної моделі аналізованого процесу було використано такі сутності:

Орендар

(>УНН орендаря,Наименование_арендатора,Адрес_арендатора, Телефон орендаря)

Договір

(Номер договору, >УНН орендаря,Дата_заключения,Адрес_помещения,Ставка_арендной_плати)

Приміщення

(>Адрес_помещения,Тип_помещения,Площадь_помещения,Коеффициент_комфортабельности,Коеффициент_расположения)

Орендну плату

(Номер договору, >УНН орендаря, Дата оплати, Сума, ПДВ)

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

Розглянемо якого типу ставляться зв'язок між сутностями в проектованої базі даних.

1) зв'язок між Орендар і Договір, Частини і Машини - один до багатьох;

2) зв'язок між Договір і Орендну плату - одне одного;

3) зв'язок між Договір і Приміщення – багато до багатьох, необов'язкова;

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

Усі відносини перебувають у нормальної форміБКНФ оскільки задовольняють наступним умовам:

Усі атрибути відносин –атомарни;

Усі атрибути кожної сутності функціонально повно залежить від первинного ключа;

У кожній сутності не все ключові атрибути нетранзитивно залежить від первинного ключа;

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

Малюнок 2ER-диаграмма логічного рівня.


2.2.2 Нормалізація схеми даних. Дозвіл неспецифічних відносин. Уточнення типів даних для атрибутів схем відносин. Реалізаціяссилочной цілісності. Проектування індексів.ER-диаграмма фізичного рівня

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

>Определим первинні ключі в описаних раніше сутність.

По суті «Орендар» первинний ключ - це атрибут: «>УНН орендаря». По суті «Приміщення» первинний ключ - це атрибут: «>Адрес_помещения».

По суті «Орендну плату» - це мігруючі атрибути «>УНН орендаря» і «Номер договору» і атрибут «Дата оплати». По суті «Договір» - це мігруючий атрибут «>УНН орендаря» і атрибут «Номер договору».

Далі визначаються фізичні властивості атрибутів.

По суті «Орендар» атрибути «>УНН орендаря» і «Телефон орендаря» - числового (>целочисленного) типу, й інші атрибути «Найменування орендаря» і «Адреса орендаря» - текстові поля.

По суті «Договір» атрибути «Номер договору» і «>УНН орендаря» - числового (>целочисленного) типу. «Дата укладання» - полі типудата-время. «Адреса приміщення» - текстове полі. «Ставка орендної плати» полі числового (речовинного) типу.

По суті «Приміщення» атрибути «Адреса приміщення» і «Тип приміщення» - текстові поля, атрибути «Площа приміщення», «Коефіцієнт комфортабельності», «>Коеффициент_расположения» - поля числового (речовинного) типу.

По суті «Орендну плату» атрибути «Номер договору», «>УНН орендаря», «Сума», «ПДВ» - числового (>целочисленного) типу, атрибут «Дата оплати» - полі типудата-время.

Вочевидь, що у всіх сутність ключові атрибути мусять мати значень.

Забезпечення цілісності бази даних.

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

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

- видаленні записів батьківської таблиці;

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

Проектування індексів.

У базах даних з прискорення пошуку інформацією таблицях застосовуються індекси. Те передбачає аналіз записів відповідно до зростанням (>убиванием) значень полів, у тому числі сформований індекс таблиці. Індекси можуть бути із будь-якої числа полів таблиці у різних їх поєднаннях. Деякі індекси створюються автоматично. Такі індекси формуються щодо первинних ключів і сукупностей полів з ознаками унікальності. При генеруванні схеми з урахуванням моделі даних,ERwin автоматично створює індекс для первинного ключа (РК) окрема індекс кожному за альтернативного ключа (АК), зовнішнього ключа (>FK),InversionEntry (IE). Якщо в сутності був призначено альтернативних ключів іInversionEntry, тоERwin створює індекси лише первинного ключа і зовнішніх ключів.

>ER-диаграмма схеми бази даних фізичного рівня представленій у додатку 5.2


2.3 Емпірична перевірка логічного моделі системи

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

Результат зв'язування об'єктів моделі процесів:

>ActivityName

>ArrowName

>EntityName

>AttributeName

Введення даних

по орендарям

Дані

орендарям

Орендар Адреса

Найменування

орендаря

Телефон
>УНН орендаря
Орендну плату Дата оплати
ПДВ
Номер договору
Сума
Договір Адреса приміщення
Дата укладання
Номер договору
Ставка
>УНН орендаря
Приміщення Адреса приміщення
Коефіцієнт
комфортабельності

Коефіцієнт

 розташування

Площа
Тип приміщення
Орендну плату

за приміщення

 на місяць

Орендар

Найменування

орендаря

>УНН орендаря
Орендну плату Дата оплати
ПДВ
Номер договору
Сума
Договір Номер договору
Ставка
Приміщення Адреса приміщення

Розрахунок орендної

 і щодо оплати місяць

Дані

 по приміщенням

Орендар Адреса

Найменування

орендаря

Телефон
>УНН орендаря
Орендну плату Дата оплати
ПДВ
Номер договору
Сума
Договір Адреса приміщення
Дата укладання
Номер договору
Ставка
>УНН орендаря
Приміщення Адреса приміщення
Коефіцієнт
комфортабельності

Коефіцієнт

розташування

Площа
Тип приміщення

>ActivityName

>ArrowName

Страница 1 из 2 | Следующая страница

Схожі реферати:

Навігація