Ім'я файлу: магіст-Данещук-фініш-АПДЕЙТ.docx
Розширення: docx
Розмір: 1908кб.
Дата: 18.11.2021
скачати
Пов'язані файли:
2 diplom - гаврилов.doc
Розширення: docx
Розмір: 1908кб.
Дата: 18.11.2021
скачати
Пов'язані файли:
2 diplom - гаврилов.doc
2.3 Система управління базою даних
Звичайно ж жодна система управління не обійдеться без бази даних. Розглянемо поняття реляційних баз даних.
Реляційні бази даних використовуються вже дуже давно. Вони стали популярними завдяки успішним реалізацій реляційних моделей в системах управління, які опинилися вельми зручними для роботи з даними. Давайте порівняємо три найпопулярніші реляційні системи управління базами даних (РСУБД): SQLite, MySQL і PostgreSQL.
Бази даних - це логічно змодельовані сховища будь-якого типу даних. Кожна база даних, яка не є без схеми, слідує моделі, яка визначає конкретну структуру для обробки даних. СУБД - це програми (або бібліотеки), які управляють базами даних різної форми, розміру та типу.
Реляційні системи реалізують реляційну модель даних, яка визначає всю збережену інформацію як набір пов’язаних записів та атрибутів у таблиці. СУБД цього типу використовують структури (таблиці) для зберігання та роботи з даними. Кожен стовпець (атрибут) містить свій тип інформації. Кожен запис у базі даних з унікальним ключем передається в рядок таблиці, а його атрибути відображаються в стовпцях таблиці.
Іншими словами база даних - це сукупність даних із такими властивостями:
• дані логічно пов’язані між собою і несуть відповідну інформацію;
• структура баз даних зазвичай відповідає конкретному набору даних, який вона містить;
• Бази даних відображають лише певні аспекти реального світу, що дає можливість визначити їх як "мікросвіт".
Система управління базами даних (СУБД) поєднує інформацію з різних джерел в єдиній реляційній базі даних. Форми, запити та звіти, які ви створюєте, дозволяють швидко та ефективно оновлювати дані, отримувати відповіді на запитання, шукати потрібні дані, аналізувати дані та друкувати звіти, діаграми та наклейки. Системи управління даними першого покоління СУБД першого покоління характеризуються тим, що кожна група користувачів розробила своє власне програмне забезпечення для управління даними. Наслідком цього розділення стало надмірне дублювання програмних кодів та даних. Системи управління даними другого покоління Пов'язані файли даних об'єднуються в бази даних. СУБД створені для досвідчених користувачів, таких як програмісти. Системи управління даними третього покоління Можливості СУБД розширилися. Створені вдосконалені інтерфейси, що забезпечують інтерактивний доступ звичайним користувачам.
Переваги СУБД:
• Зменшення надлишку даних;
• Без баз даних неможливо уникнути зберігання зайвих даних;
• Якщо бази даних центрального контролю можуть бути ліквідовані;
• Надлишкові дані неможливо повністю усунути, оскільки питання часу та надійності відіграє важливу роль у СУБД.
У світі існує багато СУБД. Незважаючи на те, що вони можуть по-різному працювати з різними об'єктами та надавати користувачеві різні функції та інструменти, більшість СУБД покладаються на єдиний добре встановлений набір базових концепцій. Це дає нам можливість розглянути одну систему та узагальнити її концепції, прийоми та методи для всього класу СУБД. Як такий навчальний об’єкт розглянемо СУБД Microsoft Access, що входить до пакета Microsoft Office.
Найпоширенішими СУБД є:
Microsoft Access.
SQLite: дуже потужна вбудована СУБД.
MySQL: найпопулярніша і часто використовувана система управління базами даних.
PostgreSQL: найдосконаліша та найгнучкіша система управління базами даних.
Зупинимося детальніше на проектування БД та їх властивостях.
Дизайн бази даних
Перш ніж створювати таблиці, форми та інші об'єкти, потрібно визначити структуру бази даних. Хороша структура бази даних є основою для створення адекватної, ефективної бази даних. Сам процес проектування бази даних - це складний процес проектування відображення опису предметної області у схему внутрішньої моделі даних. Потік цього процесу є послідовністю більш простих процесів проектування для менш складних відбиттів. Ця послідовність у процесі проектування постійно вдосконалюється, вдосконалюється таким чином, що визначаються об’єкти, їх властивості та зв’язки, які будуть потрібні майбутнім користувачам системи.
Ми пропонуємо майбутнім користувачам систем управління базами даних два підходи, два варіанти проектування баз даних.
Перший варіант широко відомий, оскільки він був запропонований Microsoft. Друга версія відображає практичний досвід проектування, і за основу взята версія, опублікована в "ComputerWorld" за 1996 рік.
Етапи проектування баз даних
Нижче наведені основні етапи проектування бази даних:
1. Визначення мети створення бази даних.
2. Визначення таблиць, які повинна містити база даних.
3. Визначення обов’язкових полів у таблиці.
4. Завдання окремих значень для кожного поля.
5. Визначення взаємозв’язків між таблицями.
6. Відновлення структури бази даних.
7. Додавання даних та створення запитів, форм, звітів та інших об'єкти бази даних.
8. Використання інструментів аналізу в Microsoft Access.
Давайте детальніше розглянемо ці етапи.
1. Визначення мети створення бази даних. Першим кроком у проектуванні бази даних є визначення мети створення бази даних, її основних функцій та інформації, яку вона повинна містити. Тобто потрібно визначити основні теми таблиць бази даних та інформації, містити поля таблиць. База даних повинна відповідати вимогам тих, хто безпосередньо з нею працює. Для цього потрібно визначити теми, які повинна охоплювати база даних, звіти, які вона повинна видавати, проаналізувати форми, які в даний час використовуються для запису даних, порівняти створену базу даних з добре спроектованою базою даних, подібною до неї.
2. Визначення таблиць, які повинна містити база даних. Одним із найскладніших етапів у процесі проектування бази даних є розробка таблиць, оскільки результати, які повинна бачити база даних (звіти, вихідні форми тощо), не завжди дають уявлення про структуру таблиці . При проектуванні таблиць зовсім не обов'язково використовувати СУБД. Найкраще спочатку розробити конструкцію на папері. Отже, при розробці таблиці слід керуватися наступними основними принципами: - інформація в таблиці не повинна дублюватися. Між таблицями не повинно бути повторень. Коли певна інформація збирається лише в одній таблиці, її доведеться змінювати лише в одному місці. Це робить роботу більш ефективною, а також можливість невідповідності інформації в різних таблицях. За заявою одна таблиця повинна містити адреси та номери телефонів клієнта; кожна таблиця повинна містити інформацію лише з однієї теми. Дані по кожній темі обробляти набагато простіше, якщо вони містяться в таблицях, які не залежать одна від одної. Наприклад, адреси клієнтів та замовлення зберігаються в окремих таблицях, щоб при видаленні замовлення інформація про клієнта перезаписувалась у базі даних.
3. Визначення обов’язкових полів у таблиці. Кожна таблиця містить інформацію по окремій темі, а кожне поле таблиці містить окрему інформацію по темі таблиці. Наприклад, таблиця з даними клієнтів може містити поля з назвою компанії, адресою, пунктом призначення, країною та номером телефону. Створюючи поля для кожної таблиці, майте на увазі: - кожне поле повинно бути пов’язане з темою таблиці - не рекомендується включати в таблицю дані, які є результатом виразу; - таблиця повинна містити всю необхідну інформацію - Інформацію слід розбивати на найменші логічні одиниці (наприклад, поля "Ім'я" та "Прізвище", а не загальне поле "Ім'я").
4. Встановлення індивідуального значення для кожного поля. Щоб СУБД могла зв’язувати дані з різних таблиць, наприклад, дані про клієнта та його замовлення, кожна таблиця повинна містити поле або набір полів, встановлювати індивідуальне значення для кожного запису в таблиці. Таке поле або набір полів називається головний ключ.
5. Визначення взаємозв’язків між таблицями. Після розподілу даних по таблицях та визначення ключових полів потрібно вибрати схему для зв’язування даних у різних таблицях. Для цього вам потрібно визначити взаємозв'язки між таблицями. Доцільно вивчити взаємозв'язки між таблицями в існуючій базі даних. Щоб переглянути посилання у вибраній базі даних, відкрийте її та виберіть відповідні команди.
6. Відновлення структури бази даних. Після проектування таблиць, полів та взаємозв’язків вам потрібно переглянути структуру бази даних та виявити можливі недоліки. Бажано зробити це на цьому етапі, поки таблиця не заповнена даними. Для його перевірки потрібно створити кілька таблиць, зв’язки між ними та ввести в кожну таблицю кілька записів, а потім переглянути базу даних, щоб відповідати вимогам. Також рекомендується створювати чернетки результатів та звітів та перевіряти, чи містять вони необхідну інформацію. Крім того, необхідно виключити з таблиць усі можливі дублювання даних.
7. Додавання даних та створення інших об’єктів бази даних. Якщо структури таблиць відповідають вимогам, ви можете ввести всі дані. Потім ви можете створювати будь-які записи, форми, звіти, макроси та модулі.
8. Використання інструментів аналізу в Microsoft Access. Наприклад, Microsoft Access має два інструменти для вдосконалення структури баз даних. Майстер аналізу таблиць аналізує таблицю, якщо це необхідно, пропонує нову структуру та з'єднання та обробляє їх. Аналізатор продуктивності вивчає всю базу даних, дає рекомендації щодо її вдосконалення, а також впроваджує їх.
Розробка проекту бази даних
1. Розробка логічної моделі даних. Логічні моделі розробляються базами даних для формального представлення інформаційних потреб виробництва, економіки, бізнесу тощо. Найбільш формою відображення цієї моделі є ER-діаграми. Основними поняттями моделі ER є сутність, взаємозв'язок та атрибут. Кожна з частин такої діаграми побачить трохи про структуру даних або про те, як ці дані стосуються інших. Як правило, розробка логічної моделі - це ітераційний процес, що складається з фаз аналізу, проектування та оцінки. Одночасно на кожній ітерації додаються нові правила. Хороші засоби проектування баз даних повинні бути гнучкими та ефективно організованими. Діаграми ER повинні доповнюватися детальною діловою інформацією, правилами та загальними посиланнями на цілісність, а також забезпечувати можливість контролю візуального представлення деталей моделі. Створюючи логічну модель, ви насамперед повинні виконати важливу роботу для замовника. Найбільший обсяг роботи над базами даних пов’язаний із запитами. Тому вам потрібно якомога більше дізнатися від замовника про можливі запити до бази даних. Досвід дизайну показує, що замовники часто не уявляють, які можливості може дати їм база даних, до яких нових завдань вони можуть приєднатися. Через це під час проекту необхідно якомога раніше показати клієнтам їх потенційні горизонти, щоб зміни в логічній моделі також мали бути зроблені раніше.
2. Підготувати звіт про логічну модель. Звіти використовуються для відстеження процесу проектування логічної моделі. 3. Вони також корисні для обговорення вимог із клієнтами. Посилання, як правило, перелічують сутності, їх атрибути, правила та обмеження, що містяться в базі даних. Хороші інструменти звітування містять різні типи інформації про логічну модель, полегшують гнучке розміщення та форматування, а також надають звіт у файл або експортують його в інші програми. У випадку звуження вимог до замовників, варто скласти результат за окремим протоколом.
3. Перетворення логічної моделі у фізичну. У процесі розбиття фізичної моделі сутності, атрибути та відносини складають фізичну модель, відображаються в таблиці та стовпцях. До попередніх додаються нові властивості стовпців (типи даних, тривалість та невизначені значення) - первинний та зовнішній ключі, індекси, обмеження перевірки та правила підтримки цілісності на основі сили. Щоб правильно та якісно виконати цей етап проектування, інструменти моделювання даних повинні працювати з декількома популярними СУБД типу SQL, графічно відображати фізичні характеристики, дозволяти призначати та змінювати тригери за замовчуванням1, створювати власний тригер, денормалізувати фізичну модель, не торкаючись логічної.
4. Підготуйте звіт про фізичну модель. Як правило, для одночасної перевірки деякої таблиці або всіх таблиць разом із деталями (стовпці, їх характеристики, індекси, кінцеві ключі та тригер) використовується звіт про фізичну модель. Хороші інструменти для підготовки таких звітів прості у використанні, мають гнучкий інтерфейс для визначення елементів, зокрема звіту, організації звіту та його генерації. Вони зобов'язані надати детальну інформацію про введення обмежень, правила цілісності посилок, включаючи мету та зміст тригерів.
5. Генерація схеми бази даних. Схема описує реалізацію бази даних, враховуючи особливості конкретної СУБД. Схему можна створити або за допомогою мови визначення даних (файли DDL), або шляхом прямого доступу до СУБД. Програмні продукти, які добре виявляють генерацію схеми, забезпечують засоби контролю над сформованими елементами схеми, що робить цей процес ітеративним. Ми повинні шукати інструменти, які підключаються до нашої цільової СУБД і дають можливість перемикатися між різними СУБД, мінімізуючи ручне редагування.
6. Ведення розробленої моделі даних. Більшість баз даних еволюціонують протягом свого життєвого циклу. Для спрощення цього процесу рекомендується синхронно модифікувати модель та базу даних. Варто звернути увагу на засоби синхронізації, утиліти контролю версій та захисту. За допомогою найкращих в роботі інструментів ви можете перенести зміни в обидві сторони: від моделі до схеми і навпаки. Якщо раніше замовник після введення СУБД в експлуатацію відмовлявся підтримувати, то зараз, як правило, проектувальники супроводжують роботу СУБД. Це покладає на них додаткову відповідальність за якість проекту, оскільки вони повинні самі усувати всі проблеми.
7. Перевернутий дизайн виходить із існуючої бази даних. Повторне відтворення схеми існуючої бази даних обслуговує кілька циліндрів. Це дозволяє побудувати модель цієї бази даних, перенести існуючу базу даних з однієї СУБД в іншу, а також просто змінити схему бази даних, вона функціонує. Точність та гнучкість є ключовими параметрами для такого завдання. Ми повинні мати можливість вказати елементи схеми, з якими буде працювати програма, і очікується, що в результаті генерації схеми бази даних із відновленої моделі повинна з’явитися однакова копія початкової схеми.
Як бачимо, другий варіант визначає більш загальний підхід до проектування баз даних та враховує стосунки із замовником проекту.
У роботі було обрано СУБД SQLite.
SQLite - це дивовижна бібліотека, вбудована в додаток, який використовує його. Як база даних на базі файлів, вона забезпечує чудовий набір інструментів для полегшення (порівняно з базами даних на стороні сервера) обробки будь-яких даних. Коли програма використовує SQLite, їх зв'язок здійснюється за допомогою функціональних та прямих викликів до файлів, що містять дані (наприклад, бази даних SQLite), а не за допомогою якогось інтерфейсу, що збільшує швидкість та продуктивність операцій.
Звязки та типи даних. Звязки можна визначити як математичні набори, що містять набори атрибутів, що відображають збережену інформацію. Кожен елемент, що формує запис, повинен відповідати певному типу даних (ціле число, дата тощо). У різних СУБД використовуються різні типи даних, які не завжди є взаємозамінними. Цей тип обмежень є загальним у реляційних базах даних. Насправді вони складають суть відносин.
Підтримувані типи даних
NULL: значення NULL.
ЦІЛИЙ: ціле число з підписом, що зберігається в 1, 2, 3, 4, 6 або 8 байтах.
REAL: число з плаваючою комою, що зберігається у 8-байтовому форматі IEEE.
ТЕКСТ: текстовий рядок, кодований UTF-8, UTF-16BE або UTF-16LE.
BLOB: тип даних, що зберігається в тій самій формі, в якій він був отриманий.
Примітка. Ознайомтеся з документацією, щоб отримати докладнішу інформацію.
До переваг можна віднести наступне: вся база даних зберігається в одному файлі, що полегшує навігацію.
Стандартизовано: SQLite використовує SQL; деякі функції пропущені (ПРАВО ЗОВНІШНЄ ПРИЄДНАННЯ або ДЛЯ КОЖНОЇ ЗАЯВИ), однак є деякі нові. Дуже добре підходить для розробки і навіть тестування: на етапі розробки більшість потрібно масштабувати. SQLite, з його багатим набором функцій, може забезпечити більш ніж достатньо функціональних можливостей, будучи досить простим для роботи з одним файлом та пов'язаною з ним бібліотекою. обмеження
Відсутність контролю користувача: розширені бази даних надають користувачам можливість керувати взаємозв’язками в таблицях відповідно до привілеїв, але SQLite цього не робить. Неможливість додаткових налаштувань: Знову ж таки, SQLite не можна зробити більш продуктивним, заглибившись у налаштування - так це працює. Коли використовувати SQLite Вбудовані програми: будь-яка портативність, яка не призначена для масштабування програми - наприклад, локальні однокористувацькі програми, мобільні програми чи ігри.
Система доступу до диска: у більшості випадків програми, які часто виконують операції прямого читання / запису на диск, можна перенести на SQLite для підвищення продуктивності. Тестування: ідеально підходить для більшості програм, де тестування бізнес-логіки є частиною функціональних можливостей. Коли не використовувати SQLite Багатокористувацькі програми: Якщо ви працюєте над додатком, яким одночасно буде користуватися кілька людей, краще вибрати повнофункціональну СУБД - наприклад, MySQL. Додатки записують великі обсяги даних: Одним з обмежень SQLite є операції запису. Ця СУБД дозволяє одночасно лише одну операцію запису.
1 2 3 4 5 6 7 8 9 10