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

Процес проектування даних, логічне моделювання і фізичне проектування. Діаграма "сутність-зв'язок" (Entity-Relationship). DDL-скрипт для створення бази даних. Логічна модель та опис, типи ключів. Фізична модель та спосіб розміщення даних на носіях.

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

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

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

Размещено на 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


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

  • Опис предметної області. Визначення проблеми та постановка задачі. Проектування бази даних. Концептуальна модель. Логічна модель. Фізична модель. Розробка програмних модулів.

    курсовая работа [136,3 K], добавлен 14.07.2007

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

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

  • Специфікація вимог для кожного з двох користувачів. Концептуальне та логічне проектування баз даних. Історія досліджень баз даних (програмного забезпечення). Система упрваління базами даних. Фази проектування баз даних: концептуальна, логічна, фізична.

    дипломная работа [105,8 K], добавлен 20.02.2010

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

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

  • Побудова інформаційної системи "Магазин товарів для настільного тенісу" з автоматизації роботи магазину. Концептуальне моделювання бази даних. Обґрунтування вибору СУБД. Логічне проектування бази даних. Схема бази даних. Створення таблиць в конструкторі.

    курсовая работа [8,8 M], добавлен 16.12.2015

  • Концептуальна модель бази даних, визначення зв’язків між ними, атрибутів сутностей їх доменів. Створення ORM source model та Database model diagram для бази даних "Автотранспортне підприємство". Генерування ddl-скрипта для роботи в СУБД SQL-Server.

    курсовая работа [47,3 K], добавлен 17.10.2013

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

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

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

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

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

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

  • Поняття та переваги реляційної бази, автоматизація аналізу даних. Опис основних компонентів сховища даних AS/400. Процес перетворення оперативних даних в інформаційні. Багатовимірні бази даних (MDD). Опис даних і створення файлів в інтеграційних базах.

    реферат [36,8 K], добавлен 14.01.2012

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