Методи й засоби проектування баз даних

Вступ

Кожне підприємство, яке має доступ до інформаційних технологій, працює з базами даних. З їх допомогою можна зберігати найрізноманітнішу інформацію. Наприклад: відомості про працівників, рахунки, договори та інша інформація.
Перевагою баз даних є можливість зберігати й обробляти велику кількість інформації з мінімальними витратами часу і ресурсів. Системи управління базами даних призначені для управління даними у вигляді таблиць, тобто створення нових таблиць, видалення непотрібних, вставки в таблиці нових записів, зміни записів і, звичайно ж, обробки запитів, а також деяких інших, менш часто використовуваних функцій. Бази даних призначені для того, щоб швидко видавати інформацію, причому в певному порядку.
Зараз найбільш поширеною є реляційна модель баз даних. Широке поширення ця модель отримала відносно недавно. У той час, як основні теоретичні результати в цій області були отримані ще в 70-х (співробітником інституту фірми ІБМ в Сан-Хосе Е.Ф. Коддом), і тоді ж з'явилися перші прототипи реляційних СУБД, довгий час вважалося неможливим досягти ефективної реалізації таких систем. Однак поступове накопичення методів і алгоритмів організації реляційних баз даних і управління ними призвели до того, що вже в середині 80-х років реляційні системи практично витіснили зі світового ринку ранні СУБД ієрархічного і мережевого типу. В реляційній базі даних дані зберігаються не все разом, а в окремих таблицях, завдяки чому досягається виграш у швидкості та гнучкості. Таблиці зв'язуються між собою за допомогою відносин, завдяки чому забезпечується можливість поєднувати при виконанні запиту дані з декількох таблиць. Реляційна модель описує, які дані можуть зберігатися в реляційних базах даних, а також способи маніпулювання такими даними. У спрощеному вигляді основна ідея реляційної моделі полягає в тому, що дані повинні зберігатися в таблицях і тільки в таблицях. В даний момент існуємо багато різних систем обробки даних, що оперують поняттям "таблиця", наприклад, всім відомі, електронні таблиці, таблиці текстового редактора MS Word, і т.п. Осередки електронної таблиці можуть зберігати різнотипні дані, наприклад, числа, рядки тексту, формули, що посилаються на інші клітинки. Власне, на одному аркуші електронної таблиці можна розмістити кілька абсолютно незалежних таблиць, якщо під таблицею розуміти прямокутну область, розкреслену на клітинки та заповнену даними. Таблиці текстових редакторів взагалі можуть мати абсолютно довільну структуру. У даній роботі виконується проектування та розробка бази даних реєстру повітряних суден.

 

Методи й засоби проектування баз даних

Опис основних етапів проектування баз даних

Проектування бази даних - процес розробки структури бази даних відповідно до вимог користувачів.

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

Фаза проектування:
- Розробка стратегії;
- Системний аналіз;
- Концептуальне моделювання;
- Логічне і фізичне проектування.

Фаза реалізації:
- Реалізація;
- Документування;
- Дослідне впровадження;
- Промислова експлуатація.

 

Опис методології проектування

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

 

Компоненти методології проектування БД: процес проектування, що складається з послідовності фаз і етапів, на кожному з яких необхідно приймати альтернативні рішення.
Методики виконання необхідних в процесі проектування розрахунків і критерії оцінки альтернативних рішень на кожному етапі. Інформаційні вимоги в якості вихідних даних для процесу проектування, як в цілому, так і на кожному етапі. Засоби опису вихідних даних і представлення результатів кожного етапу проектування.

Короткий опис мови моделювання, що використовується

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

Основні поняття ERD

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

 

Кожен зв’язок може мати один з типів зв’язку: один-до-одного (), один-до-багатьох () и багато-до-багатьох ().

 

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

 

Кожен зв’язок може мати одну з двох модальностей зв’язку: «може» () і «повинен» ().

 

Може	Екземпляр однієї сутності може бути пов'язаний з одним або кількома екземплярами іншої сутності, а може бути і не пов'язаний ні з одним екземпляром
Повинен	Екземпляр однієї сутності зобов'язаний бути пов'язаний не менш ніж з одним екземпляром іншої сутності

 

Описаний графічний синтаксис дозволяє однозначно читати діаграми, користуючись наступною схемою побудови фраз: <Кожен екземпляр СУТНОСТІ 1> <МОДАЛЬНІСТЬ ЗВ'ЯЗКУ> <НАЙМЕНУВАННЯ ЗВ'ЯЗКУ> <ТИП ЗВ'ЯЗКУ> <екземпляр СУТНОСТІ 2>.

3. Стратегія автоматизації

Логічний проект бази даних

Висновки

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

Ціллю даної курсової роботи було створення бази даних реєстрації повітряних суден України.

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

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

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

Логічне та фізичне проектування БД складалося з конвертації концептуальної моделі ПО у реляційну модель даних. При цьому був використаний алгоритм конвертування схеми ПО у мові ER в схему реляційної бази даних. Після цього реляційна база даних була представлена у вигляді команд створення таблиць бази даних у мові SQL ORACLE. Крім того, у мові SQL описані деякі інформаційно-пошукові запити.

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

Вступ

Кожне підприємство, яке має доступ до інформаційних технологій, працює з базами даних. З їх допомогою можна зберігати найрізноманітнішу інформацію. Наприклад: відомості про працівників, рахунки, договори та інша інформація.
Перевагою баз даних є можливість зберігати й обробляти велику кількість інформації з мінімальними витратами часу і ресурсів. Системи управління базами даних призначені для управління даними у вигляді таблиць, тобто створення нових таблиць, видалення непотрібних, вставки в таблиці нових записів, зміни записів і, звичайно ж, обробки запитів, а також деяких інших, менш часто використовуваних функцій. Бази даних призначені для того, щоб швидко видавати інформацію, причому в певному порядку.
Зараз найбільш поширеною є реляційна модель баз даних. Широке поширення ця модель отримала відносно недавно. У той час, як основні теоретичні результати в цій області були отримані ще в 70-х (співробітником інституту фірми ІБМ в Сан-Хосе Е.Ф. Коддом), і тоді ж з'явилися перші прототипи реляційних СУБД, довгий час вважалося неможливим досягти ефективної реалізації таких систем. Однак поступове накопичення методів і алгоритмів організації реляційних баз даних і управління ними призвели до того, що вже в середині 80-х років реляційні системи практично витіснили зі світового ринку ранні СУБД ієрархічного і мережевого типу. В реляційній базі даних дані зберігаються не все разом, а в окремих таблицях, завдяки чому досягається виграш у швидкості та гнучкості. Таблиці зв'язуються між собою за допомогою відносин, завдяки чому забезпечується можливість поєднувати при виконанні запиту дані з декількох таблиць. Реляційна модель описує, які дані можуть зберігатися в реляційних базах даних, а також способи маніпулювання такими даними. У спрощеному вигляді основна ідея реляційної моделі полягає в тому, що дані повинні зберігатися в таблицях і тільки в таблицях. В даний момент існуємо багато різних систем обробки даних, що оперують поняттям "таблиця", наприклад, всім відомі, електронні таблиці, таблиці текстового редактора MS Word, і т.п. Осередки електронної таблиці можуть зберігати різнотипні дані, наприклад, числа, рядки тексту, формули, що посилаються на інші клітинки. Власне, на одному аркуші електронної таблиці можна розмістити кілька абсолютно незалежних таблиць, якщо під таблицею розуміти прямокутну область, розкреслену на клітинки та заповнену даними. Таблиці текстових редакторів взагалі можуть мати абсолютно довільну структуру. У даній роботі виконується проектування та розробка бази даних реєстру повітряних суден.

 

Методи й засоби проектування баз даних