База даних АРМ "Будівельна фірма"

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

Вступ

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

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

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

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

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

ЄР Діаграми

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

Мал. 1

Мал. 2

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

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

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

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

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

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

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

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

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

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

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

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

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

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

база дані носій ключ

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

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

До питань організації даних належать:

Вибір типу запису - одиниці обміну в операціях вводу-виводу;

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

Вибір способу адресації і методу доступу до записів.

Стадія фізичного проектування БД в загальному випадку включає:

Вибір способу організації БД;

Розробку специфікації внутрішньої схеми;

Опис відображення концептуальної схеми у внутрішню.

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

Вибір схеми розміщення даних (поділ по файлам або тип RAID-масиву);

Визначення числа і типу індексів (наприклад, кластеризований або некластеризованний в разі MS SQL Server).

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

Размещено на Allbest.ru