2.Аннотация

АНОТАЦІЯ

В даній дипломній роботі розроблено базу даних АРМ «Будівельна фірма». При розробці було використано структурний підхід проектування програмного забезпечення, у результаті було отримано ескізний, технічний та робочий проекти. Програмне забезпечення реалізоване за допомогою бази даних Microsoft Access .

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

АННОТАЦИЯ

В данной дипломной работе разработана база данных АРМ «Строительная фирма». При разработке были использованы структурный подход проектирования программного обеспечения, в результате было получено эскизный, технический и рабочий проекты. Программное обеспечение реализовано с помощью базы данных Microsoft Access.

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

Annotation

In dannoy dyplomnoy slave Designed database ARM "Stroitelnaya firm." If Creative were published yspolzovanы strukturnыy approach of design of software, as a result of áûëî polucheno эskyznыy, Technical and worker projects. Prohrammnoe Securing realyzovano s pomoshchju Databases of Microsoft Access.

Poyasnytelnaya note executed on Ukrainian language and consists settles of __ Sheet soderzhyt __ drawings, __ tables and list yspolzovannыh sources, sostoyaschyy of __ naymenovanyy.

3.Описання предметної області

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

Якщо ви любите порядок, то, швидше за все, електронні таблиці або ярлики до них у вас згруповані за допомогою каталогів і підкаталогів. При виконанні такого упорядкування ви самі є диспетчером бази даних. Але що робити, коли доводиться працювати з величезними обсягами? Як можна збирати відомості про всіх клієнтів і зроблених ними замовленнях, якщо дані зберігаються в кількох документах або файлах? Як забезпечити зв'язок між файлами при введенні нової інформації? Як перевірити достовірність введення даних? Як бути, якщо необхідно забезпечити спільний доступ до інформації, але запобігти одночасне оновлення даних двома різними співробітниками? Як забезпечити розмноження даних, якщо відсутня можливість одночасного доступу до даних? Наявність подібного роду проблем говорить про необхідність використовувати систему управління базою даних, СУБД (database management system, DBMS).

Зміст

1.Зміст

2.Анотація

3.Опис предметної області

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

5.ЄР 0діаграма

6.ЄР 1 діаграми ( декілька )

7.Логічна модель та опис

8.Фізична модель

9.Висновок

5.ЄР Діаграми

Нульова ЕР діаграма

6.ЕР діаграма №1

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

В цьому самостійному завдані приставлені ЄР діаграми. Предметною областю створення являється створення ЄР діаграм. Описані ЄР діаграми.

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

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

Моделювання даних

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

Базові поняття ERD

Сутність (Entity) - безліч екземплярів реальних або абстрактних об'єктів (людей, подій, станів, ідей, предметів та ін), що володіють загальними атрибутами або характеристиками. Будь-який об'єкт системи може бути представлений тільки однією сутністю, яка повинна бути унікально ідентифікована. При цьому ім'я сутності повинно відображати тип або клас об'єкта, а не його конкретний екземпляр (наприклад, АЕРОПОРТ, а не ВНУКОВО).

Сутність можна визначити як об'єкт, подію чи концепцію, інформація про яких повинна зберігатися. сутності повинні мати найменування з чітким смисловим значенням, іменуватися іменником в однині, не носити "технічних" найменувань і бути досить важливими для того, щоб їх моделювати. Іменування сутності в однині полегшує надалі читання моделі. Фактично ім'я сутності дається по імені її екземпляра. Прикладом може бути сутністю Замовник (але не Замовники!) З атрибутами Номер замовника, Прізвище замовника і Адреса замовника. На рівні фізичної моделі їй може відповідати таблиця Customer з колонками Customer_number, Customer_name і Customer_address. Кожна сутність повинна бути повністю визначена за допомогою текстового опису.