Інформаційно-комп’ютерна система для агентства нерухомості

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

Рубрика Программирование, компьютеры и кибернетика
Вид курсовая работа
Язык украинский
Дата добавления 27.06.2016
Размер файла 241,6 K

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

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

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

Вступ

запит інформаційний нерухомість

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

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

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

- ручні - всі операції виконуються людиною;

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

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

За сферою призначення:

- економічна;

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

- навчальна, тощо.

За місцем діяльності ІС:

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

- ІС автоматизованого керування - призначені для автоматизації праці інженерів-проектувальників і розроблювачів нової техніки (технології);

- IC організаційного керування - призначена для автоматизації функції адміністративного (управлінського) персоналу. До цього класу відносяться ІС керування як промисловими, так і непромисловими об'єктами і окремими офісами;

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

За функціональним призначенням:

- керуючі ІС;

- проектуючі ІС;

- ІС наукового пошуку;

- діагностичні;

- системи підготовки прийняття рішень.

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

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

В ході виконання дипломного проекту розроблена інформаційно-комп'ютерна система для продажу різних видів нерухомості

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

1.1 Поняття торгівлі на споживчому ринку

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

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

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

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

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

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

Місія торгівлі (призначення):

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

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

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

- організація ринкового ціноутворення.

1.2 Завдання проектування бази даних

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

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

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

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

- на підставі існуючих відомостей про предметну область в широкому або вузькому сенсі, тобто в масштабах, в яких вона повинна бути представлена в утворювальній БД і працюючих з нею додатках;

- виходячи з цілей проектування програмної системи;

- на підставі подання про те, яке місце БД і працюючі з нею додатки займуть в структурі експлуатуючій її організації;

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

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

1.3 Формування концептуальної моделі

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

Формування концептуальної моделі бази даних включає в себе:

- ідентифікацію функціональної діяльності предметної області;

- ідентифікацію об'єктів (сутностей), які здійснюють цю функціональну діяльність, і формування з їх операцій послідовності подій, які допоможуть ідентифікувати всі сутності і взаємозв'язки між ними;

- ідентифікацію характеристик цих сутностей;

- ідентифікацію взаємозв'язків між сутностями;

- функціональну діяльність і формування з їх операцій.

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

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

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

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

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

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

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

Другою складовою частиною заявки є облікова картка об'єкта нерухомості.

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

Після того як оператор зареєстрував клієнта в базі даних агентства, він (оператор) здійснює пошук найбільш відповідного варіанту для цього клієнта.

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

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

1.4 Інформаційна модель системи обробки постачання замовлень

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

Рисунок 1.1. Склад і структура інформаційної моделі

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

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

2. Постановка задачі

2.1 Функціональне призначення ІС

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

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

Крім вище сказаного виділити ще ряд аналітичних звітів, які можна отримати при використанні автоматизованої інформаційної системи.

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

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

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

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

- забезпечення впливу кожних новопосталих пропозицій на ринку нерухомості на старі заявки клієнтів;

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

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

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

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

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

2.2 Технічні вимоги

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

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

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

Надійність. Система повинна бути в працездатному стані 24 години на добу 7 днів на тиждень, час простою - не більше 10%.

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

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

2.3 Аналіз вхідних та вихідних документів

До вхідних документів інформаційної системи належать:

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

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

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

- відомості про майновий фонд.

До вихідних документів інформаційної системи належать:

- звіт про клієнтів та їх відомостях;

- звіт про договір;

- звіт обороти співробітників.

- звіт про виручку по кожному співробітнику.

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

3. Математична модель

3.1 Поняття математичної моделі

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

Етапи комп'ютерного математичного моделювання зображені на рисунку 3.1.

Рисунок 3.1. Етапи комп'ютерного математичного моделювання

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

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

3.2 Опис зв'язків між сутностями

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

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

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

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

Дана нотація була введена Ченом (Chen) і отримала подальший розвиток у роботах Баркера (Barker). Нотація Чена надає багатий набір засобів моделювання даних, включаючи власне ERD, а також діаграми атрибутів і діаграми декомпозиції. Ці діаграмні техніки використовуються насамперед для проектування реляційних баз даних (хоча також можуть з успіхом застосовуватися і для моделювання як ієрархічних, так і мережевих баз даних). Під час проектування баз даних відбувається перетворення ER-моделі в конкретну схему бази даних на основі обраної моделі даних (реляційної, об'єктної, мережевої або ін.).

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

- забезпечення зберігання інформації в єдиному місці (навіть, якщо вона використовується в різних комбінаціях);

- використання цієї інформації різними додатками.

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

Кожний взаємозв'язок представлений в РСУБД за рахунок спільного використання однієї або декількох колонок двома таблицями.

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

3.3 Поняття нормалізації та ER - діаграм

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

Надлишковість даних в БД є небажаним явищем, оскільки призводить до збільшення об'єму пам'яті, уповільнює роботу БД. Надлишковість даних є результатом в першу чергу дублювання даних.

У реальному проектуванні структури бази даних застосовується метод - семантичне моделювання. Семантичне моделювання є моделювання структури даних, спираючись на зміст цих даних. Як інструмент семантичного моделювання використовуються діаграми сутність-зв'язок (ER - Entity-Relationship).

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

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

Примірник сутності - це конкретний представник даної сутності. Наприклад, представником сутності «Співробітник» може бути «Співробітник Іванов». Примірники сутностей повинні бути помітні, тобто сутності повинні мати деякі властивості, унікальні для кожного екземпляра цієї сутності.

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

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

Необмежене (обов'язкове) відношення являє собою безумовне відношення, тобто відношення, що існує доти, доки існують сутності, між якими воно встановлене.

Обмежене (необов'язкове) відношення являє собою умовне відношення між сутностями.

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

Для кожного об'єкта визначається ступінь зв'язку атрибутів даної сутності:

1. один-до-одного (1:1);

2. один-до-багатьох (1:?);

3. багато-до-багатьох (?:?).

Правила нормалізації діаграм сутність-зв'язок:

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

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

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

4. Якщо ступіть бінарного зв'язку 1:? та клас приналежності багатозв'язної сутності є обов'язковим, то достатнім є використання двох відношень по одному на кожну сутність при умові, що ключ сутності служить в якості первинного ключа відповідного відношення. Додатково ключ однозв'язної сутності повинен бути доданий в якості атрибута для відношення, які відводяться під багатозв'язну сутність.

5. Якщо ступіть бінарного зв'язку 1:? та клас приналежності багатозв'язної сутності є необов'язковим, то необхідно побудувати три відношення по одному для кожної сутності та одне для зв'язку. Зв'язок серед атрибутів повинен мати ключі обох сутностей.

6. Якщо ступіть бінарного зв'язку ?:?, то необхідно будувати три відношення. Ключ кожної сутності використовується в якості атрибутів зв'язку.

7. У випадку тристороннього зв'язку необхідно використовувати чотири попередніх відношення по одному для сутностей та одне для зв'язку.

3.4 Нормалізація відносин

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

Рисунок 3.2. Діаграма сутність-зв'язок

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

Після побудови діаграми сутність-зв'язок (рисунок 3.2) треба провести нормалізацію за правилами. У всіх відношеннях ступіть бінарного зв'язку 1:? та клас приналежності багатозв'язної сутності є обов'язковим, тому слід будувати за 4 правилом.

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

Рисунок 3.3. Концептуальна (логічна) схема інформаційної системи

4. Обґрунтування вибору середовища розробки

4.1 СУБД Microsoft Access

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

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

Access - потужний додаток до Windows; продуктивність СУБД органічно поєднується з тими зручностями, які існують в розпорядженні користувачів Microsoft Windows. Оскільки обидва ці продукти компанії Microsoft, вони прекрасно взаємодіють між собою. Система Access працює під управлінням Windows, так що при роботі з нею користувачу доступні всі переваги Windows. Можливо вирізати, копіювати і вставляти данні з будь-якого додатку Windows в Access і навпаки; можливо створювати проект форми в Access та зберігати його як звіт.

В Access в повному розмірі реалізовано управління реляційними базами даних. Система підтримує первинні та зовнішні ключі і забезпечує цілісність даних на рівні ядра (що запобігає несумісні операції оновлення або видалення даних). Крім цього, таблиці в Access забезпеченні засобами перевірки допустимості даних, запобігаючи некоректний ввід, незалежно від того, як він реалізовується, а кожне поле таблиці має свій формат и стандартні описи, що суттєво полегшує ввід даних. Access підтримує всі необхідні типи полів, в том числі текстовий, числовий, лічильник, грошовий, дата/час, МЕМО, логічний, гіперпосилання и поля об'єктові OLE. Якщо в процесі спеціальної обробки в полях не виявляється ніяких значень, система забезпечує повну підтримку пустих значень.

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

При цьому Access - не просто СУБД. Як реляційна СУБД Access забезпечує доступ до всіх типів даних та дозволяє використовувати одночасно декілька таблиць бази даних. При цьому можливо суттєво спростити структуру даних, полегшуючи тим самим виконання поставлених задач. Таблицю Access можливо зв'язати с даними, зберігаюшихся на великій ЕОМ або на сервері.

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

Потужність та доступність Access роблять цю систему кращою СУБД з представлених сьогодні ринку.

4.2 Visual Fox Pro

Visual FoxPro (VFP) - візуальне середовище розробки систем управління базами даних, що випускається в даний час корпорацією Майкрософт. Використовує мову програмування FoxPro.

Завдяки вбудованому механізму обробки курсора БД, тісного зв'язку між мовою і даними і іншим потужним функціям, пакет Visual FoxPro 9.0 служить чудовим інструментом для створення рішень будь-якого масштабу на основі баз даних. Зосереджений на роботі з даними, об'єктно-орієнтована мова, використовуваний в цьому пакеті, пропонує розробникам гнучкий інструментарій для створення додатків на основі БД для індивідуального використання, для роботи в клієнт-серверних середовищах, а також в Інтернеті.

Visual FoxPro 9.0 забезпечений потужним набором майстрів, які дозволяють новачкові досить швидко створити потужний працездатний додаток, однак при створенні раціонального додатку, майстри використовують бібліотеки підтримки і нераціонально використовують пам'ять. Програми створені за допомогою майстрів дуже громіздкі.

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

В Visual FoxPro не відбувається оголошення типу змінних, це позбавляє можливості контролювати правильність звернення до змінної і, головне, під змінну відводиться максимальна кількість пам'яті, тому програми написані на Visual FoxPro дуже ресурсомісткі.

В Visual FoxPro занадто слабкі можливості по роботі з візуальними компонентами.

4.3 СУБД Paradox

Пакет Paradox, розроблений фірмою ANSA, а зараз випускається фірмою Borland, домігся великого успіху. Цей продукт відрізняється дуже «легким» інтерфейсом і займає лідируюче положення по простоті використання.

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

Як тільки вводиться запит, записи відповідають критеріям вибору, «випадають» в нижню частину екрану, утворюючи тимчасову таблицю під назву «answer» (відповідь). Цю таблицю можна зберегти.

У Paradox використовується власна версія мови запитів Qbe. У шпальтах таблиці можна вводити умовні оператори для завдання критеріїв вибору. Записи, що задовольняють запиту, з'являються в таблиці під запитом.

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

Незважаючи на відносно невисоку загальну оцінку користувацьких властивостей Paradox 7.0, засоби допомоги в цьому пакеті реалізовані на досить хорошому рівні. Нові Експерти суттєво полегшують створення баз даних. Експерт по базах даних (Database Expert) генерує весь додаток, включаючи таблиці, форми і звіти. Якщо не потрібно створювати закінчене реляційний додаток або необхідно встановити власні зв'язки між таблицями, можна скористатися Експертом за таблицями (Table Expert), що пропонують великий набір шаблонів для використання в ділових та особистих цілях. У числі інших нових корисних засобів - Експер діаграм (Chart Expert), Експерт поштових відправлень (Mail Merge Expert), що працює з редакторами Word і WordPerfect, і Експерт імпортування текстових файлів (Text Import Expert).

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

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

5. Реалізація проекту ІС

5.1 Опис об'єктів, які плануються для використання

База даних буде реалізована за допомогою СУБД Microsoft Access 2010, що входить до складу пакета Microsoft Office 2010. Центральними об'єктами у в MS Access є таблиці, що складаються з полів різних типів. Ціллю таблиць є збереження інформації. Ціллю всіх інших об'єктів бази даних є взаємодія тим чи іншим способом з однією, або декількома таблицями. В базі даних Access можуть міститися сотні таблиць, а кількість записів в кожній з таблиць обмежено в першу чергу місцем, доступним на жорсткому диску.

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

У програмі Access 2010 доступні такі типи даних: Число, Дата й час, логічний, Текст, грошова одиниця та ін. У поданій нижче таблиці вказані формати, доступні для кожного типу даних, і описані ефекти використання параметрів форматування.

Таблиця 5.1 - Типи полів MS Access

Назва типу

Призначення

Лічильник

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

Текст

Короткі алфавітно-цифрові значення, наприклад прізвище або адреса.

Число

Числові значення різного типу, окрім грошових одиниць. У числові поля можна внести тільки цифрові значення. Існує декілька форматів числових полів, зокрема - процентний формат, ціле число тощо.

Грошова одиниця

Грошові значення.

Логічний

Значення «Так» і «Ні» та поля, які містять лише одне із двох значень.

Дата й час

Використовується для збереження дати або часу в одному з визначених форматів. Можна вносити як комбіновану дату/час (17:51:32 14.12.2014) так і окремо дату або час.

Форматований текст

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

Обчислюване поле

Результати обчислення. В обчисленні повинні використовуватись інші поля тієї самої таблиці. Для створення обчислення використовується побудовник виразів.

Гіперпосилання

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

Примітка

Довгі фрагменти тексту. Поле типу «Примітка» часто використовується для зберігання докладного опису продукту.

Підстановка

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

5.2 Техніка побудови запитів до одиночної таблиці

Засобами запиту можна зробити наступне:

– вибрати записи, що задовольняють умовам відбору;

– включити до результуючу таблицю запиту потрібні поля;

– призвести обчислення в кожній з отриманих записів;

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

– провести оновлення полів у вибраному підмножині записів;

– створити нову таблицю бази даних, використовуючи дані з існуючих таблиць;

– видалити відмічене підмножина записів в іншу таблицю;

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

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

Види запитів:

- на вибірку. Вибирає дані з взаємозв'язаних таблиць і інших запитів. У результаті з'являється таблиця, яка існує до закриття запиту. У запиті на вибірку можуть використовуватись не тільки таблиці бази даних, але й раніше створені запити (таблиці, що є результатом їх виконання);

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

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

- створити нову таблицю бази даних, використовуючи дані з існуючих таблиць;

- видалити відмічене підмножина записів в іншу таблицю;

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

5.3 Опис об'єктів розроблюваної інформаційної системи

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

Таблиця 5.2. Опис полів таблиці «Договора»

Поле

Тип даних

Примітка

Номер договора

Числовий

Код недвижимости

Числовий

Первинний ключ

Код клиента

Числовий

Код сотрудника

Числовий

Цена

Грошовий

Дата заключения

Дата й час

Таблиця 5.3. Опис полів таблиці «Недвижимость»

Поле

Тип даних

Примітка

Код недвижимости

Числовий

Первинний ключ

Вид недвижимости

Текстовий

Местонахождение

Текстовий

Площадь (кв/м)

Текстовий

Количество комнат

Числовий

Адрес

Текстовий

Дополнительные условия

Текстовий

Стоимость

Грошовий

Таблиця 5.4. Опис полів таблиці «Клиенты»

Поле

Тип даних

Примітка

Код клиента

Числовий

Первинний ключ

Ф.И.О. клиента

Текстовий

Телефон

Числовий

Номер договора

Числовий

Статус

Текстовий

Таблиця 5.5. Опис полів таблиці «Сотрудники»

Поле

Тип даних

Примітка

Табельный номер

Числовий

Первинний ключ

Номер договора

Текстовий

Ф.И.О. сотрудника

Текстовий

Телефон

Числовий

Дата рождения

Дата й час

5.4 Опис інтерфейсу користувача

Крім таблиць, що реалізують математичну модель інформаційної системи, необхідно розробити інтерфейс користувача - сукупність екранних форм, звітів та запитів, необхідних для зручної та ефективної роботи із системою. Нижче приведені таблиці, у яких перераховано запити, їх типи та призначення (табл. 5.6), форми, їх призначення (табл. 5.7), звіти (табл. 5.8).

Таблиця 5.6. Запити

Назва запиту

Тип

Призначення

Договора агентства

Вибірка

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

Возраст сотрудников

Вибірка

Обчислювальний запит для з'ясування віку співробітників агентства

Зарплата (вычисляемый)

Вибірка

Розраховує заробітну плату співробітників та загальну суму продажу чи оренди різних видів нерухомості

Итоговый доход сотрудников

Вибірка

Обчислює загальний прибуток по кожному співробітнику агентства

Комнаты

Вибірка

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

Поиск районов

Вибірка

Параметричний запит, що дозволяє проводити пошук нерухомості по районам

Поиск сотрудников

Вибірка

Параметричний запит, що дозволяє проводити пошук співробітників агентства

Сокращение пенсионеров

На видалення

Автоматично видаляє з бази даних всіх спів робітників, що досягли пенсійного віку

Перекрестный

Перехресний

Відображає роботу кожного працівника по різним видам його діяльності

Таблиця 5.7. Форми

Назва

Примітки

Договора

Форма для відображення повної інформації про договір на нерухомість

Данные агентства

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

Клиенты

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

Главная форма

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

Комнаты

Форма перегляду інформації про нерухомість агентства згідно умов відбору (кількість кімнат)

Отчеты

Форма, що дає можливість переглянути всі звіти інформаційної системи

Поиск районов

Форма перегляду інформації про нерухомість агентства згідно умов відбору (по районам)

Поиск сотрудников

Форма для пошуку співробітників за прізвищем та ініціалами

Сотрудники

Містить повну інформацію по співробітникам агентства

Об авторе

Форма для перегляду повної інформації про співробітників агентства

Таблиця 5.8. Звіти

Назва

Примітка

Договора

Містить інформацію для відображення даних про договори агентства на нерухомість

Доход сотрудников

Відображає кількість сумарно проданої нерухомості разом з орендою по кожному співробітнику

Отчет о сделках

Містить повну інформацію про всі види нерухомості, їх вартість та співробітників які з нею працюють

5.5 Використані технічні засоби

В ході проектування цієї бази даних було використано ЕОМ наступної комплектації:

1. Процесор AMD DualCore A4-3300 з максимальною частотою 3,1 ГГц;

2. Системна плата ASRock A55M-DGS;

3. Модуль пам'яті Team Group DDR3-1600 4 ГБ;

4. Відеоадаптер NVIDIA GeForce 9600 GT (512 МБ відеопам'яті);

5. Блок живлення Chieftec 500W;

6. Монітор AOC 2243W (22» LCD);

7. Дисковий накопичувач Western Digital (500 ГБ, SATA-II);

8. Флеш-пам'ять Silicon-Power16G (16 ГБ);

9. Клавіатура PLEOMAX KM-C20;

10. Миша A4Tech G10-690F;

11. USB-адаптер бездротових мереж Edimax nLite WirelessUSB.

Окрім апаратних засобів було використано таке програмне забезпечення:

1. Операційна система Windows 7 Home Premium;

2. Інтернет-браузер Google Chrome ver. 38.0.2125.111 m;

3. Система управління базами даних MS Access 2010;

4. Табличний процесор MS Excel 2010;

5. Текстовий процесор MS Word 2010;

6. Графічний редактор Paint.

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

...

Подобные документы

  • Форми вихідних документів. Перелік запитів до бази даних. Побудова інфологічної моделі, її структурні компоненти: сутності, зв’язки та відносини. Перелік таблиць, опис запитів. Загальна характеристика та головний зміст форм розроблюваної бази даних.

    курсовая работа [414,5 K], добавлен 31.01.2014

  • Модель – це прообраз, опис або зображення якогось об'єкту. Класифікація моделей за способом зображення. Математична модель. Інформаційна модель. Комп'ютерна модель. Етапи створення комп'ютерної моделі.

    доклад [11,7 K], добавлен 25.09.2007

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

    курсовая работа [2,5 M], добавлен 02.01.2014

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

    дипломная работа [797,2 K], добавлен 18.09.2016

  • Можливості застосування середовища MySQL для роботи з базами даних. Завдання системи SQL Server. Розробка концептуальної моделі бази даних "Сервісний центр". Створення таблиць phpmyadmin, заповнення їх даними. Створення запитів і зв’язків у phpmyadmin.

    курсовая работа [2,3 M], добавлен 27.05.2015

  • Розробка бази даних в середовищі Microsoft SQL Server 2008 для обліку послуг фітнес-клубу. Таблиці для баз даних, їх властивості. Аналіз сукупності вхідних і вихідних параметрів, опис інформаційної бази, розробка логічної і фізичної моделі даних в ІС.

    курсовая работа [449,9 K], добавлен 09.05.2016

  • Проектування бази даних предметної області "Магазин будівельних матеріалів". Аналіз сукупності вхідних і вихідних даних, шляхи удосконалення інформаційної системи обліку товару. Організація інформаційної бази, розробка логічної і фізичної моделі.

    курсовая работа [559,2 K], добавлен 09.05.2016

  • Основні підходи до проектування баз даних. Опис сайту Інтернет-магазину, характеристика його підсистем для обробки анкет і запитів користувачів. Розробка концептуальної, інфологічної, даталогічної, фізичної моделей даних. Побудова ER-моделі в CASE-засоби.

    курсовая работа [2,3 M], добавлен 01.02.2013

  • Конкурентоспроможність страхового продукту та ринку. Фазифікація та дефазифікація. Етапи моделювання комплексної оцінки конкурентоспроможності компанії. Комп’ютерна реалізація моделі. Графіки функцій належності гаусівського типу вхідних змінних системи.

    курсовая работа [1,7 M], добавлен 14.06.2014

  • Аналіз предметної галузі, постановка задачі, проектування бази даних. UML-моделювання, побудова ER-діаграми, схеми реляційної бази даних у третій нормальній формі. Призначення і логічна структура. Опис фізичної моделі бази даних, програмної реалізації.

    курсовая работа [3,5 M], добавлен 28.11.2011

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

    презентация [352,2 K], добавлен 04.12.2014

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

    курсовая работа [1,5 M], добавлен 11.12.2011

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

    курсовая работа [1,4 M], добавлен 24.10.2010

  • Аналіз сучасних методів тестування та практичних особливостей проведення тестового контролю. Основи побудови інформаційно-математичної моделі. Алгоритм запису інформації в таблицю бази даних. Характеристика та шляхи розробки інтерфейсу редактора тестів.

    курсовая работа [1,7 M], добавлен 08.10.2010

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

    курсовая работа [5,3 M], добавлен 12.05.2015

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

    отчет по практике [748,5 K], добавлен 26.03.2015

  • Аналіз відомих підходів до проектування баз даних. Моделі "сутність-зв'язок". Ієрархічна, мережева та реляційна моделі представлення даних. Організація обмежень посилальної цілісності. Нормалізація відносин. Властивості колонок таблиць фізичної моделі.

    курсовая работа [417,6 K], добавлен 01.02.2013

  • Розробка автоматизованої інформаційно-довідкової системи "Шовкова фея". Область використання системи, визначення функцій, вибір програмних засобів для розв’язання задачі, її комп’ютерна реалізація. Вимоги до ПЗ. Аналіз вихідних даних засобами MS Excel.

    презентация [980,4 K], добавлен 09.09.2010

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

    курсовая работа [55,1 K], добавлен 15.03.2015

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

    курсовая работа [83,9 K], добавлен 13.01.2017

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.