Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
КУРСОВИЙ ПРОЕКТ
з дисципліни: "Організація баз даних і знань"
Тема проекту: "Проектування та розробка бази даних "Виставка собак"
РЕФЕРАТ
Ключові слова: БАЗИ ДАНИХ, КОНЦЕПТУАЛЬНА МОДЕЛЬ, БІЗНЕС ПРАВИЛА, ГЛОСАРІЙ.
Розглядається процес проектування та розробки бази даних для "Виставки собак". Проведено огляд сучасних тенденції в області проектування й розробки баз даних, побудовано концептуальну модель даних, аналіз даної предметної області. Запропоновано програмні інструменти SQL Manager for MySQL, ERWin.
База даних являє собою структуровану сукупність даних, що спільно зберігаються і обробляються відповідно з деякими правилами. База даних моделює деяку предметну область або її фрагмент. В якості постійного сховища інформації баз даних виступають файли.
РЕФЕРАТ
Ключевые слова: БАЗЫ ДАННЫХ, КОНЦЕПТУАЛЬНА МОДЕЛЬ, БИЗНЕС ПРАВИЛА, ГЛОССАРИЙ.
Рассматривается процесс проектирования и разработки базы данных для "Выставки собак". Проведен обзор современных тенденции в области проектирования и разработки баз данных, построено концептуальную модель данных, анализ данной предметной области. Предложено программные инструменты SQL Manager for MySQL, ERWin.
База данных представляет собой определенным образом структурированную совокупность данных, совместно хранятся и обрабатываются в соответствии с определенными правилами. База данных моделирует некоторую предметную область или ее фрагмент. В качестве постоянного хранилища информации баз данных выступают файлы.
ЗМІСТ
Перелік позначень та скорочень 3
Вступ. …………….4
1 Аналіз предметної області. Постановка задачі курсової роботи 6
1.1 Актуальність розробки баз даних 6
1.2 Аналіз наданої предметної області
1.2.1 Система бізнес-правил 15
1.2.2 Глосарій проекту 16
1.3 Постановка задачі дослідження 14
2 Моделювання даних предметної області 15
2.1 Розробка концептуальної моделі даних 17
2.Перетворення концептуальної моделі в логічну модель даних 19
2.3 Аналіз бізнес-логіки обробки даних у предметній області 23
3 Реалізація моделі бази даних . 27
3.1 Мотивований вибір СКБД 27
3.2 Реалізація моделі бази даних 29
3.3 Результати, отримані при роботі з БД 33
3.3.1 Розробка уявлень для відображення результатів вибірки 33
3.3.2 Проектування збережених процедур 35
3.3.3 Розробка механізмів управління даними в базі за допомогою
тригерів 40
Висновки 43
Джерела інформації 44
Додаток Візуальна схема БД 57
БД – база даних;
ЖЦ – життєвий цикл;
ІВ – Інформаційні відношення;
ІС – інформаційна система;
КП – курсовий проект;
ЛМД – логічна модель даних;
МД – Модель даних;
НІВ – Нормалізоване інформаційне відношення;
ООБД – об'єктно-орієнтована база даних;
ПО – програмне забезпечення;
ПП – програмний продукт;
ПрО – предметна область;
РМД – реляціонна модель даних;
СБП – Система бізнес правил;
СКБД – система управління базами даних;
СОД – система обробки даних;
ФМД – фізична модель даних.
В інформаційному суспільстві головним ресурсом є інформація про самих різних процесах і явищах, що дає можливість ефективно і оптимально будувати будь-яку діяльність. У такому суспільстві конкретні фахівці зайняті у сфері обробки інформації в своєму повсякденному виробничої діяльності.
Основні ідеї сучасної інформаційної технології базуються на концепції, згідно з якою дані повинні бути організовані в бази даних з метою адекватного відображення мінливого реального світу та задоволення інформаційних потреб користувачів. Ці бази даних створюються і функціонують під управлінням спеціальних програмних комплексів, званих системами управління базами даних (СКБД). Інформаційні системи на даний час є дуже актуальною проблемою. Вони використовуються у майже всіх галузях суспільного життя. Основою будь-якої інформаційної системи є база даних (БД). Базу даних розробляють для зберігання великої кількості інформації та швидкого доступу до неї.
Тема даного курсового проекту полягає в розробці бази даних, яка автоматизує процес зберігання та обробки інформації про перелік собак на виставці. Собаки шоу-класу – високопородні собаки, які повністю відповідають стандарту породи. Існує велика кількість виставок, з величезною кількістю собак. Вибір даної предметної області обумовлений тим, що на виставці важливо враховувати наявність зареєстрованих собак, відповідність експертів, а також оперативно організовувати доступ до цієї інформації.
При розробці курсовий проект поділяємо на 3 розділи:
Розділ 1. Розглядаються основні проблеми розробки сучасних баз даних, особливості зберігання даних, сучасні тенденції в області проектування й розробки баз даних.
Розділ 2. Розглядається аналіз обраної предметної області, розробка концептуальної моделі даних.
Розділ 3. Розглядається мотивованій вибір СКБД для реалізації проекту, реалізація БД, результати, одержувані при роботі з БД, розробка уявлень для відображення результатів вибірки, проектування збережених процедур, розробка механізмів управління даними в базі за допомогою тригерів.
Очікуваним результатом роботи є база даних у якій ми зможемо зберігати дані про каталог зареєстрованих собак на виставці змінювати, видаляти їх та робити різноманітні запити.
При розв'язуванні багатьох інформаційних задач сьогодні широко використовуються системи управління базами даних (СУБД) реляційного типу. В даних СУБД реалізується реляційна модель даних зображення їх у табличному вигляді. Рядок такої таблиці еквівалентнийзапису файлу бази даних (БД), а графа - полю запису. Доступ до елемента даних здійснюється з допомогою зв'язку потрібного рядка з потрібною графою.
База даних (БД) — це засіб збирання й впорядкування даних. Бази даних можуть містити відомості про людей, товари, замовлення тощо. Багато баз даних починаються як список у текстовому редакторі або електронній таблиці.[1]
Основні можливості СУБД перераховані нижче.
1 Поповнення, розширення та відновлення БД.
2 Висока надійність зберігання інформації.
3 Засоби захисту інформації в СУБД.
4 Виведення повної й достовірної інформації на запити користувача.
До складу багатьох СУБД, призначених для роботи на персональних комп'ютерах, входять три основні компоненти: командна мова, інтерпретуюча система або компілятор для перетворення команд до виду, придатного до виконання, і засоби взаємодії користувача із СУБД.
Основні операції, які можна виконати за допомогою СКБД:
1 Створити новий файл бази даних у вигляді таблиці.
2 Створити структуру таблиці (тобто структуру запису).
3 Увести дані в таблицю.
4 Зберегти таблицю на диску.
5 У разі потреби модифікувати (змінити) структуру.
6 Доповнити базу даних записами.
7 Вилучити зайві записи.
8 Впорядкувати записи за зростанням чи спаданням значень у деякому полі.
9 Відшукати записи, що задовольняють деякому критерію за допомогою фільтра чи звернувшись до бази даних із запитом.
10 Виконати обчислення.
11 Подати потрібні дані у вигляді форми чи звіту.
Каталог собак на виставці, який розглядається, зберігає інформацію про кожну собаку з яких має породу, ім’я, вік. Інформація в базах даних зберігається у впорядкованому вигляді, в бібліотечному каталозі – або за алфавітом, , або по області знання.
Під визначенням предметної області розуміється наступне: частина реального світу, що розглядається в межах певного контексту.
Данна предметна область, тобто "Перелік зареєстрованих собак на виставці" передбачає під собою програмну допомогу організаторові, який веде облік зареєстрованих собак на виставці, у вигляді бази даних. Щоб розробити базу даних для цієї предметної області треба провести її аналіз.
Всі собаки мають базу даних для прискорення пошуку і для зберігання інформації про породу, ім’я та вік.
Протягом дослідження предметної області, визначаємо дані необхідні для зберігання: назва породи, ім’я собаки, вік собаки.
Перелік усієї інформації яку повинна зберігати база даних двох виставок:
- перелік груп FCI;
- перелік порід, що відповідають певним групам FCІ;
- перелік господарів;
- перелік зареєстрованих собак;
- перелік забарвлень собак.
База, що розглядається є універсальною, тобто дану базу можна використовувати для постійного обліку собак на виставках. Також в представленій базі можна зберігати історію вже пройдених виставок.
Сутність постановки задачі полягає в розробці бази даних для обліку можливих та зареєстрованих собак на виставках в цілях зпрощення організації даного заходу.
Бізнес-правила являють собою спеціалізований вид логіки, яка описує обмеження на образ дій, які система або люди повинні враховувати у своїй поведінці. Ці правила визначаються цілим рядом факторів, включаючи директиви розпорядчих органів, промислові стандарти, ділову хватку і простий здоровий глузд. Нерідко вони змінюються від країни до країни, від галузі до галузі, і навіть від бізнесу до бізнесу.[2]
Систему бізнес-правил формує група експертів-аналітиків по даній предметній області та представляються на одній з природних мов, зрозумілій для всіх учасників розробки даного інформаційного середовища. Аналізуючи предметну область, отримуємо наступну систему бізнес правил для інформаційної системи бібліотек:
- існує декілька виставок;
- на кожній виставці є групи FCI;
- кожна група має власний перелік собак;
- у кожної собаки є лише один власник, динамічно змінюваний вік, стать;
- кожен експерт може оцінювати окрему кількість собак;
- кожний експерт дає короткий опис собаці;
- у кожного експерта є лише одна рингова бригада;
- кожний експерт надає титул собаці.
В проекті використовується багато термінів. Для систематизації цих термінів використовується глосарій.
Глосарій – це словник певних понять або термінів, об'єднаних загальною специфічної тематикою.
При складанні глосарію важливо дотримуватися наступних правил:
- максимальна точність та достовірність інформації;
- необхідно вказувати коректні наукові терміни і уникати всякого роду жаргонізмів.
- необхідно приводити в приклад контекст, в якому може вживати даний термін;
- в глосарій можна включити не тільки окремі слова і терміни, а й цілі фрази.
Глосарій для даної предметної області:
1) виставка (Dog_Show) – шоу-показ собак;
2) собака (Dog) – тварина шоу-класу, яка представляється на виставці;
3) групи FCI (FCI_Groups) – стандартизовані групи порід собак;
4) власник (Owner) – власник собаки або декількох собак;
5) експерт (Judge) – людина, яка надає короткий опис та присвоює титул собаці;
6) рингова бригада (Ring_Brigade) – окрема кількість людей, що допомагають експерту в наданні опису;
7) результат (Result) – короткий опис та титул, присвоєний окремій собаці.
Утримання великої кількості літератури, великого списку користувачів ускладнює роботу фахівцям. Створення бази даних, що дозволяє автоматизувати рутинні процеси і значно скоротити тимчасові витрати на їх виконання, дає можливість перейти на новий рівень.
Каталог собак на виставці повинен мати базу даних для зберіння інформації про виставку і зареєстрованих собак. Також каталог повинен мати зручний інструмент доступу до інформації.
Oсновні цілі, які повинні бути досягнуті в результаті виконання курсової роботи:
дослідження й опис предметної області;
Початковою стадією проектування системи баз даних є побудова семантичної моделі предметної області, яка базується на аналізі властивостей і природи об'єктів предметної області та інформаційних потреб майбутніх користувачів системи, що розробляється. Цю стадію прийнято називати концептуальним проектуванням системи, а її результат – концептуальною моделлю предметної області (об'єктом моделювання тут є предметна область майбутньої системи) [17]. Концептуальне проектування є центральною частиною, ядром всього процесу проектування баз даних. Для того щоб база даних адекватно відображала предметну область, проектувальник повинен добре уявляти собі всі нюанси, притаманне їй, і вміти відобразити їх в базі даних.
Концептуальна модель – це відображення предметної області, для якої розробляється база даних. Всі об'єкти, які позначають речі, позначаються у вигляді прямокутника. Атрибути, що характеризують об'єкт – у вигляді еліпсу, а зв'язки між об'єктами – ромбами. Потужність зв'язку позначаються стрілками (у напрямку, де потужність дорівнює багатьом – подвійна стрілка, а з боку, де вона дорівнює одиниці – одинарна). Кожен об’єкт має свої атрибути. Якщо предметна область об’ємна, то її корисно розбити на кілька локальних предметних областей. Після створення моделей кожної виділеної предметної області виробляється об'єднання локальних концептуальних моделей в одну загальну, як правило, досить складну схему [18].
ER-діаграма складеться з 11 об’єктів.
1) тип бібліотеки (зв'язок з Бібліотекою);
бібліотека (Зв'язок з Типом бібліотеки, Бібліотекарем, Читачем);
бібліотекар (Зв'язок з Бібліотекою, Замовленням);
Канонічна ER діаграма. Для обраної предметної області зображена на рисунку 2.1
Рисунок 2.1 – ER-діаграма для Про "Бібліотека"
Поява і широке застосування моделі даних типу " об’єкт-зв'язок "(entity - relationship, ER-модель) пов'язане з практичними потребами системного аналізу та концептуального моделювання великих баз даних (БД) для автоматизованих інформаційних систем. Техніка побудови ER-моделі даних використовується для визначення інформаційних потреб прикладної області та представлення структури бази даних, відповідної ER-моделі, в графічній формі ER-діаграми. В життєвому циклі програмного забезпечення (ЖЦ ПЗ) техніка ER-моделювання використовується в процесах, пов'язаних зі специфікації вимог до розробляємого ПЗ [19]. Ці процеси виконуються на початкових етапах ЖЦ ПЗ. ER-модель даних володіє важливими властивостями, які підтверджують корисність її використання у визначенні вимог до даної розроблюваної програмної системи. По-перше, кошти ER-моделі володіють достатнім ступенем спільності, придатної для передачі розуміння інформаційних потрібностей користувача, в той же час не мають великого розриву з моделями даних комерційних СКБД. Це властивість забезпечує реалізацію інфо-логічної моделі БД, сконструйованої за правилами ER-моделювання, без великих проблем дає наочне уявлення про те, як ER-модель може бути перетворена в будь-яка модель з трьох основних видів - ієрархічну, мережеву, реляційну, які підтримуються комерційними СКБД.
По-друге, техніка ER-моделювання спирається на строгі формальні правила та угоди, включаючи концепції нормалізації даних. Отже, ER-модель може розглядатися як засіб точного вираження уявлень про реальні об'єкти області додатки, що дозволяє забезпечити спілкування між аналітиком і користувачем системи, а також між аналітиком і розробниками системи.
2.2 Проектування логічної моделі бази даних
Логічна структура бази даних, а так само сама заповнена даними база даних, є відображенням реальної предметної області. Тому на вибір проектних рішень найбільше впливає специфіка відображається предметної області.
Оскільки основу будь-якої бази даних складає інформаційна структура, бази даних ділять на три типи: реляційні, мережеві, ієрархічні.
Логічна модель – це абстрактний погляд на дані. На ньому дані представляються так, як виглядають у реальному світі. Об'єкти і моделі, що представляються на логічному рівні, називаються сутностями і атрибутами. Логічна модель даних є універсальною і ніяк не пов'язана з конкретною реалізацією СКБД [20].
У реляційній моделі, об'єкти представлені у вигляді таблиць (двомірних масивів). Причому таблицею можуть відображатися не тільки об'єкти, але і зв'язки кожна таблиця складається з довільної кількості рядків і довільної кількості стовпців. Обов'язковою умовою побудови реляційної моделі є наявність у кожної моделі первинного ключа. Цей вид моделі має найбільше поширення при побудові баз даних.
В основі реляційної моделі даних лежать не графічні табличні методи і засоби представлення даних і маніпулювання ними. Таблиця відображає об'єкт реального світу – сутність. Кожен стовпець таблиці має унікальне для кожної таблиці ім'я.
Реляційні системи виключили необхідність складної навігації, оскільки дані представлені в них не у вигляді одного файлу, а незалежними наборами. У реляційній моделі всі таблиці мають бути перетворені у відносини. Відносини пов'язані між собою. Зв'язки підтримуються зовнішніми ключами. У реляційній теорії є поняття "ключ" і "ймовірний ключ". Ці поняття характеризують не предметну область, а саме таблицю реляційної бази даних.
Після створення різних таблиць, що містять дані, що відносяться до різних аспектів бази даних, необхідно забезпечити цілісність бази даних.
Для даного проекту підходить найбільше реляційна модель побудови бази даних.
Для проектування логічної моделі даних використовують засіб для проектування та документування баз даних ERwin.
ERwin – потужне і просте у використанні засіб конструювання баз даних Воно забезпечує найвищу продуктивність праці при розробці та супроводі додатків з використанням баз даних [21].
Протягом усього процесу – від логічного моделювання вимог до інформації та бізнес-правил, які визначають базу даних, до оптимізації фізичної моделі у відповідності з заданими характеристиками – ERwin дозволяє наочно відобразити структуру та основні елементи БД.
ERwin – це потужний засіб проектування і інструмент розробки, здатний автоматично створювати таблиці і генерувати тисячі рядків тексту збережених процедур і тригерів для всіх популярних СКБД. Революційна технологія Complete-Compare (Завершити-Порівняти) дозволяє організувати ітеративну розробку, підтримуючи постійну узгодженість моделі та бази даних. Завдяки інтеграції з популярними середовищами розробки програм, ERwin дозволяє прискорити створення додатків для обробки даних.
ERwin полегшує проектування баз даних. Для цього досить створити графічну ER-модель, що задовольняє всім вимогам до даних і ввести бізнес-правила для створення логічної моделі, яка відображає всі елементи, атрибути, відносини і угрупування. Розвинені засоби моделювання допомагають краще спроектувати базу даних. Передбачені можливості маніпулювання атрибутами шляхом їх буксирування, внесення змін та нормалізації "на льоту". Засоби редагування безпосередньо на діаграмах дозволяють вносити в модель зміни, не відкриваючи спеціальних діалогових вікон. Навігація по відносинам забезпечує швидке переміщення у великих моделях для переходу до батьківським або дочірнім об'єктах.
ERwin автоматизує процес проектування. ERwin передбачає можливість створення каталогу найбільш часто використовуваних атрибутів, що забезпечує узгодженість імен та описів з усього проекту. Уявлення БД підтримуються як інтегровані компоненти моделі, що дозволяє автоматично відображати в їх описах зміни, внесені до базові таблиці. Автоматичне перенесення ключів забезпечує посилальну цілісність бази даних.
ERwin не тільки кращий інструмент для проектування баз даних, а й засіб для їх швидкого створення. ERwin оптимізує модель відповідно з фізичними характеристиками цільової бази даних. На відміну від інших інструментальних засобів ERwin автоматично підтримує узгодженість логічної і фізичної схем і здійснює перетворення логічних конструкцій, таких як відносини багато-до-багатьох, в їх реалізацію на фізичному рівні.
ERwin встановлює природну динамічну зв'язок між моделлю і базою даних, що дозволяє реалізувати як прямий, так і зворотний інжиніринг. До складу ERwin включений низку оптимізованих шаблонів тригерів, які забезпечують цілісність посилань, і потужний макромова, який дозволяє створювати власні тригери і процедури. Таким чином можуть бути автоматично сформовані тисячі рядків коду, що забезпечує неперевершену продуктивність розробки на основі моделей.
Засоби розрахунку обсягу дозволяють точно оцінити первинний розмір і характер росту бази даних або сховища, полегшуючи ефективне розподіл ресурсів системи та планування потужності.
База даних може бути спроектована і створена без написання окремих SQL-пропозицій типу CREATE TABLE або INDEX. Оскільки фізична схема формується на основі описової логічної моделі, ваш додаток буде відразу ж повністю документовано. ERwin дозволяє також проводити зворотний інжиніринг існуючих баз даних шляхом побудови моделі безпосередньо на основі її таблиць.
ERwin підтримує всі найбільш популярні реляційні СКБД, включаючи Oracle, Microsoft SQL Server, Sybase, DB2 і Informix. Одна і та ж модель може бути використана для створення декількох баз даних або для перенесення програми з платформи однієї СКБД на іншу.
Зазвичай розробка моделі бази даних складається з двох етапів: складання логічної моделі і створення на її основі фізичної моделі. ERwin повністю підтримує такий процес, він має два подання моделі: логічне і фізичне. Таким чином, розробник може будувати логічну модель бази даних, не замислюючись над деталями фізичної реалізації, тобто приділяючи основну увагу вимогам до інформації та бізнес-процесам, які буде підтримувати майбутня база даних.
В ході виконання курсового проекту будо розроблено концептуальну модель даних, яку зображено на рисунку 2.2.
Рисунок 2.2 – Логічна модель даних
Таким чином у даному підрозділі показане створення концептуальної моделі даних.
Для роботи з базою даних використовуються запити. Запит (query) – це засіб вибору необхідної інформації з бази даних. Питання, сформований по відношенню до бази даних, і є запит. Застосовуються два типи запитів: за зразком Query by example (QBE) і структурований мова запитів – Structured Query Language (SQL). QBE – засіб для відшукання необхідної інформації в базі даних. Він формується не на спеціальній мові, а шляхом заповнення бланка запиту у вікні Конструктора запитів. SQL-запити – це запити, які складаються (програмістами) з послідовності SQL-інструкцій. Ці інструкції задають, що треба зробити з вхідним набором даних для генерації вихідного набору. Всі запити Access будує на основі SQL-запитів, щоб подивитися їх, необхідно в активному вікні проектування запиту виконати команду Вид / SQL [23].
Існує кілька типів запитів: на вибірку, на оновлення, на додавання, на видалення, перехресний запит, створення таблиць. Найбільш поширеним є запит на вибірку. Запити на вибірку використовуються для відбору потрібної користувачу інформації, що міститься в таблицях. Вони створюються тільки для пов'язаних таблиць. Існують такі види запитів
- на вибірку;
- на додавання;
- на видалення.
- вкладений;
- прилучений;
MySQL дозволяє включати один запит до складу іншого. Вкладені запити називають також підлеглими. Вкладений запит у складі запиту SELECT поміщається в круглі дужки. Спочатку виконується вкладений запит, a потім отримані результати використовуються при обробці головного запиту. Оператор внутрішнього сполучення INNER JOIN з'єднує дві таблиці. Порядок таблиць для оператора неважливий, оскільки оператор симетричний. У випадку з left join з головної таблиці будуть вибрані всі записи, навіть якщо в присоединяемой таблиці немає збігів, тобто умова condition не враховує приєднувану праву табліцу.Right join відображає всі рядки задовольняють правій частині умови condition, навіть якщо вони не мають відповідності у головній лівої таблиці
В ході виконання КП було реалізовано ряд запитів.
Запит, що виконує вибірку читача на ім’я Ігор.
SELECT * FROM reader WHERE first_Name_reader LIKE 'Ігор';
Запит що виконує збірку книг замовлених читачем з ім’ям Ігор
SELECT Name_book FROM book WHERE Printed_matter_id IN
(SELECT Printed_matter_id FROM orderr WHERE reader_id IN
(SELECT reader_id FROM reader WHERE first_Name_reader LIKE 'Ігор')
);
Запит, що змінює імя всіх людей з фамілією Шураєв на Олег
UPDATE reader
SET first_Name_reader = 'Олег'
WHERE last_Name_reader='Шураєв'
Запит, змінює назву книги з назвою Бульба на повну назву – Тарас Бульба.
UPDATE book
SET Name_book = 'Тарас Бульба'
WHERE Name_book = 'Бульба'
Даний запит виконує видалення усіх читачів з ім’ям Арес .
DELETE FROM reader
WHERE first_Name_reader LIKE '%Арес'
Запит, що видаляє книгу з назвою Тарас Бульба з бібліотеки.
DELETE FROM book
WHERE Name_book LIKE '%Тарас Бульба'
Запит, що виконує вибірку книг і їх жанрів.
SELECT
`genre`.`Name_genre`,
`book`.`Name_book`
FROM
`book`
LEFT OUTER JOIN `genre` ON (`book`.`Genre_id` = `genre`.`Genre_id`)
GROUP BY
`genre`.`Name_genre`,
`book`.`Name_book`
Запит, що виконує вибірку книг з інформацією про їх авторів, жанр та серію.
SELECT
`genre`.`Name_genre`,
`book`.`Name_book`,
`series`.`Name_series`,
`series`.`Number`,
`author`.`first_Name`,
`author`.`last_Name`
FROM
`series`
INNER JOIN `book` ON (`series`.`Series_id` = `book`.`Series_id`)
INNER JOIN `genre` ON (`book`.`Genre_id` = `genre`.`Genre_id`)
INNER JOIN `author` ON (`book`.`Author_id` = `author`.`Author_id`)
GROUP BY
`genre`.`Name_genre`,
`book`.`Name_book`,
`series`.`Name_series`,
`series`.`Number`,
`author`.`first_Name`,
`author`.`last_Name`
Запит який здійснює вибірку читачів замовивши книгу з автором на імя Дмитро.
SELECT first_Name_reader,last_Name_reader FROM reader WHERE Reader_id IN
(SELECT Printed_matter_id FROM orderr WHERE Printed_matter_id IN
(SELECT Book_id FROM book WHERE author_id IN
(SELECT Author_id FROM author WHERE first_Name = 'Дмитро')
)
)
3 РЕАЛІЗАЦІЯ МОДЕЛІ БАЗИ ДАНИХ "БІБЛІОТЕКИ" У MYSQL 5.5. ІНСТРУМЕНТАЛЬНІ ЗАСОБИ
Існує безліч видів СКБД. Наприклад: Oracle10g, MySQL, MS SQL Server і багато інших.
Oracle Database або Oracle RDBMS – об'єктно-реляційна система управління базами даних компанії Oracle [24].
Основні характеристики СКБД Oracle
Microsoft Office Access або просто Microsoft Access реляційна СКБД корпорації Microsoft. Має широкий спектр функцій, включаючи пов’язані запити, зв'язок із зовнішніми таблицями і базами даних. Завдяки вбудованій мові VBA, в самому Access можна писати програми, що працюють з базами даних [25].
Основні характеристики СКБД Access:
MySQL – вільна реляційна система управління базами даних. Розробку та підтримку MySQL здійснює корпорація Oracle, що отримала права на торговельну марку разом з поглиненої Sun Microsystems, яка раніше придбала шведську компанію MySQL AB. Продукт поширюється як під GNU General Public License, так і під власною комерційною ліцензією [26].
Основні характеристики My SQL Server:
Розглядаючи особливості побудованої логічної моделі даних видно що для реалізації бази даних найкращим варіантом буде використання СКБД My SQL Server.
MySQL – компактний багато поточний сервер баз даних. Характеризується великою швидкістю, стійкістю і простотою використання. MySQL вважається гарним рішенням для малих і середніх застосувань[27].
Можливості сервера MySQL:
Головна таблиця це "Library", в неї є одне ключеве поле – Bibrary_id (Номер книги). Він починається з одиниці і збільшується на один з кожним наступним пристроєм. Також в таблиці "Library" є наступні поля:
- adress (адреса бібліотеки)
- name_library (назва бібліотеки)
- telephone (телефон бібліотеки)
- type_library_id (номер виду) – ключ, з таблиці "Type_library"
Таблиця "Library" призначена для зберігання інформації про різні бібліотеки та їх телефон і адресу.
Для взаємодії таблиць "Library" і "Type_library" прописуються References – зв’язки між ними що забезпечує неможливість введення не існуючого ключа типу бібліотек.
Кожний запис складається з наступних полів, опис яких наведено в таблиці 3.1
Таблиця 3.1 – таблиця "Library"
|
Ім’я поля |
Тип даних |
Опис |
|
Biblary_id |
Integer |
номер бібліотеки ключ |
|
Name_library |
Varchar |
Назва бібліотеки |
|
adress |
Varchar |
Адреса бібліотеки |
|
telephone |
Integer |
Телефон бібліотеки |
|
Type_library_id |
Integer |
Номер виду |
Таблиця "Type_library" зберігає інформацію про види бібліотек. В ній будуть зберігатися види бібліотек та їх номер. Кожен запис таблиці складається з полів, наведених у таблиці 3.2.
Таблиця 3.2 – Таблиця "Type_library"
|
Ім’я поля |
Тип даних |
Опис |
|
Type_library_id |
Integer |
код бібліотеки ключове поле |
|
Type_Name |
Varchar |
Назва бібліотеки |
Таблиця "Printed_matter" зберігає інформацію про наявність книги в одній з бібліотек. Кожен запис таблиці складається з полів, наведених у таблиці 3.3.
Таблиця 3.3 – Таблиця "Printed_matter"
|
Ім’я поля |
Тип даних |
Опис |
|
Printed_matter_id |
Integer |
Номер печатного видання ключове поле |
|
Biblary_id |
Integer |
Номер бібліотеки |
Таблиця "Orderr" Зберігає інформацію про замовлені читачами книги. Кожен запис таблиці складається з полів, наведених у таблиці 3.4.
Таблиця 3.4 – Таблиця "Orderr"
|
Ім’я поля |
Тип даних |
Опис |
|
Order_id |
Integer |
Номер замовлення ключове поле |
|
Printed_matter_id |
Integer |
Номер печатного видання |
|
Reader_id |
Integer |
Номер читача |
|
DateTime |
Data |
Дата замовлення |
Таблиця "Author" призначена для зберігання інформації про авторів книг. Кожний запис складається з наступних полів, опис яких наведено в таблиці 3.5
Таблиця 3.5 – Таблиця "Author"
|
Ім’я поля |
Тип даних |
Опис |
|
Author_id |
Integer |
Номер автора ключове поле |
|
First_Name |
Varchar |
Ім’я автора |
|
Last_Name |
Varchar |
Прізвище автора |
Таблиця "Series" зберігає інформацію про серії. В ній будуть зберігатися номер серії, назви серії та число книг у серії. Кожен запис таблиці складається з полів, наведених у таблиці 3.6.
Таблиця 3.6 – Таблиця "Series"
|
Ім’я поля |
Тип даних |
Опис |
|
Series_id |
Integer |
Номер серії ключове поле |
|
Name_series |
Varchar |
Назва серії |
|
Number |
Integer |
Число книг у серії |
Таблиця "Genre" зберігає інформацію про жанри книг. Кожен запис таблиці складається з полів, наведених у таблиці 3.7.
Таблиця 3.7 – Таблиця "Genre"
|
Ім’я поля |
Тип даних |
Опис |
|
Genre_id |
Integer |
Номер жанру ключове поле |
|
Name_genre |
Varchar |
Назва жанру |
Таблиця "Book" зберігає інформацію про книги. Кожен запис таблиці складається з полів, наведених у таблиці 3.8.
Таблиця 3.8 – Таблиця "Book"
|
Ім’я поля |
Тип даних |
Опис |
|
Book_id |
Integer |
Номер книги ключове поле |
|
Printed_matter_id |
Integer |
Номер печатного видання |
|
Name_book |
Varchar |
Назва книги |
|
Genre_id |
Integer |
Номер жанру |
Закінчення таблиці 3.8.
|
Author_id |
Integer |
Номер автора |
|
Series_id |
Integer |
Номер серії |
Таблиця "Magazine" Зберігає журнали. Кожен запис таблиці складається з полів, наведених у таблиці 3.9.
Таблиця 3.9 – Таблиця "Magazine"
|
Ім’я поля |
Тип даних |
Опис |
|
Magazine_id |
Integer |
Номер журналу ключове поле |
|
Printed_matter_id |
Integer |
Номер пчатного видання |
|
Name_magazine |
Varchar |
Назва журналу |
|
Genre_id |
Integer |
Номер жанру |
Таблиця "Reader" Зберігає перелік читачів. Кожен запис таблиці складається з полів, наведених у таблиці 3.10.
Таблиця 3.10 – Таблиця "Reader"
|
Ім’я поля |
Тип даних |
Опис |
|
Reader_id |
Integer |
Номер читача ключове поле |
|
First_Name_reader |
Varchar |
ім’я читача |
|
Last_Name_reader |
Varchar |
прізвище читача |
|
Telephone_reader |
Integer |
Телефон читача |
|
Adress_reader |
Varchar |
адреса читача |
|
Biblerian_id |
Integer |
номер бібліотекаря |
|
Biblary_id |
Integer |
номер бібліотекаря |
Таблиця "Librarian" Зберігає перелік бібліотекарів. Кожен запис таблиці складається з полів, наведених у таблиці 3.11.
Таблиця 3.11 – таблиця "Librarian"
|
Ім’я поля |
Тип даних |
Опис |
|
Biblarian_id |
Integer |
Номер бібліотекаря ключове поле |
|
First_Name_librarian |
Varchar |
ім’я бібліотекаря |
|
Last_Name_librarian |
Varchar |
прізвище бібліотекаря |
Закінчення таблиці 3.11
|
Work_time |
Varchar |
Час роботи |
|
Biblary_id |
Integer |
Номер бібліотеки |
3.3.1 Розробка уявлень для відображення результатів вибірки
Уявлення іноді називають "віртуальними таблицями". Така назва пов'язана з тим, що подання доступно для користувача як таблиця, але саме воно не містить даних, а витягує їх з таблиць в момент звертання до нього. Якщо дані змінені в базовій таблиці, то користувач отримає актуальні дані при зверненні до подання, що використовує дану таблицю; хешування результатів вибірки з таблиці при роботі уявлень не проводиться. При цьому, механізм хешування запитів (query cache) працює на рівні запитів користувача безвідносно до того, чи звертається користувач до таблиць або уявленням [29].
Уявлення (VIEW) – об'єкт бази даних, що є результатом виконання запиту до бази даних, визначеного за допомогою оператора SELECT, у момент звернення до поданням.
Уявлення можуть ґрунтуватися як на таблицях, так і на інших уявленнях, тобто можуть бути вкладеними (до 32 рівнів вкладеності).
Переваги використання уявлень:
У базі даних розроблено уявлення "r", яке містить інформацію про ім’я, прізвище та телефон читачів яких обслуговував бібліотекар з номером "1" .
select
`r`.`first_Name_reader` AS `first_Name_reader`,
`r`.`last_Name_reader` AS `last_Name_reader`,
`r`.`telephone_reader` AS `telephone_reader`,
`r`.`adress_reader` AS `adress_reader`
from
`reader` `r`
where
(`r`.`Biblarian_id` = '1')
Результат виконання даного уявлення представлено на рисунку 3.1.
Рисунок 3.1 – Результат виконання уявлення "r"
Також було розроблено уявлення "b", яке містить назви книжок з серії "Гаррі Поттер".
CREATE ALGORITHM=UNDEFINED DEFINER=`root`@`localhost` SQL SECURITY DEFINER VIEW `b` AS
select
`b`.`Name_book` AS `Name_book`
from
`book` `b`
where
(`b`.`Series_id` = _utf8'2');
Результат виконання даного уявлення представлено на рисунку 3.2.
Рисунок 3.2 – Результат виконання уявлення "b"
Перевага використання уявлень полягає в тому, що уявлення
буде модифіковано автоматично всякий раз, коли таблиця, що лежить в його основі, змінюється. Зміст подання не фіксоване і перепризначується щоразу, коли воно викликається оператором SQL.
3.3.2 Проектування збережених процедур
Збережена процедура це спосіб інкапсуляції повторюваних дій. У збережених процедурах можна оголошувати змінні, управляти потоками даних, а також застосовувати інші техніки програмування.
Причина їх створення ясна і підтверджується частим використанням. З іншого боку, якщо ви поговорите з тими, хто працює з ними нерегулярно, то думки розділяться на два абсолютно протилежних флангу. Не забувайте про це.
Позитивні наслідки використання зберігаємих процедур:
Негативні наслідки використовування процедур:
У курсовому проекті була розроблена збережена процедура усіх читачів які відвідують першу або другу бібліотеку .
CREATE DEFINER = 'root'@'localhost' PROCEDURE `new_proc1`(
IN `z` INTEGER(4)
)
NOT DETERMINISTIC
CONTAINS SQL
SQL SECURITY DEFINER
COMMENT ''
BEGIN
IF(z>2) THEN
SELECT
`Reader_id`,
`first_Name_reader`,
`last_Name_reader`,
`telephone_reader`,
`adress_reader`,
`Biblarian_id`,
`Biblary_id`
FROM
`reader` where Biblary_id = '1';
ELSE
SELECT
`Reader_id`,
`first_Name_reader`,
`last_Name_reader`,
`telephone_reader`,
`adress_reader`,
`Biblarian_id`,
`Biblary_id`
FROM
`reader` where Biblary_id = '2';
end if;
END;
Після введення вхідного параметру "z" більше ніж два ми отримуємо перелік всіх читачів які відвідують першу бібліотеку що може бути потрібним користувачу під час редагування, систематизації даних, а також перегляду потрібних даних
Результати збереженої процедури зображено на рисунках 3.3 та 3.4.
Рисунок 3.3 – Перелік читачів першої бібліотеки
Після введення вхідного параметру "z" менше чи дорівнює двом ми отримуємо перелік всіх читачів які відвідують другу бібліотеку.
Рисунок 3.4 – Перелік читачів другої бібліотеки
Також була розроблена процедура для вибору усіх читачів відвідуючи першу бібліотеку яких обслуговував певний бібліотекар.
CREATE DEFINER = 'root'@'localhost' PROCEDURE `new_proc2`(
IN `q` INTEGER(4)
)
NOT DETERMINISTIC
CONTAINS SQL
SQL SECURITY DEFINER
COMMENT ''
BEGIN
IF(q < 5) THEN
SELECT
`Reader_id`,
`first_Name_reader`,
`last_Name_reader`,
`telephone_reader`,
`adress_reader`,
`Biblarian_id`,
`Biblary_id`
FROM
`reader` where Biblarian_id = '1';
ELSE
SELECT
`Reader_id`,
`first_Name_reader`,
`last_Name_reader`,
`telephone_reader`,
`adress_reader`,
`Biblarian_id`,
`Biblary_id`
FROM
`reader` where Biblarian_id = '2';
END IF;
END;
Після введення вхідного параметру "q" менше п’яти ми отримуємо перелік всіх читачів яких обслуговує перший бібліотекар що може бути потрібним користувачу під час редагування або систематизації даних.
Результати зображено на рисунках 3.5 та 3.6.
Рисунок 3.5 – Перелік читачів першого бібліотекаря
Після введення вхідного параметру "q" більше або дорівнює п’яти ми отримуємо перелік всіх читачів яких обслуговує другий бібліотекар.
Рисунок 3.6 – Перелік читачів другого бібліотекаря
3.3.3 Розробка механізмів управління даними в базі за допомогою тригерів
Тригери призначені для запобігання, журналювання, аудиту, фіксації змін даних,реалізації бізнес правил, реплікації даних та підвищення продуктивності БД в цілому.
Тригер – збережена процедура, виклик якої відбувається автоматично при виконанні з базою даних певних дій: видалення, зміна, додавання записів.
Залежно від того, який оператор модифікації даних активізує тригер, він називається тригером вставки (insert trigger), тригером видалення (delete trigger) або тригером оновлення (update trigger).
Тригери знаходять різне застосування – від перевірки даних до забезпечення складних ділових правил.
Особливо корисною властивістю тригерів є те, що вони мають доступ до образів запису до і після модифікації; таким чином, можна порівняти два записи і прийняти відповідне рішення.
У даному курсовому проекті для таблиці "Book" був розроблений тригер – "Triger1". Дія цього тригера направлена на запобігання помилок при додаванні запису до таблиці: при вводі порожньої назви записувати туди значення "не задана" Тригері зберігаються не в скрипті бази даних а на сервері My SQL.
Код тригера:
CREATE DEFINER = 'root'@'localhost' TRIGGER `_before_ins_tr1` BEFORE INSERT ON `book`
FOR EACH ROW
BEGIN
SET NEW.Name_book = IFNULL(NEW.Name_book, ' не вказана ');
END;
Для здійснення тригера потрібно створити елемента таблиці "Book" з порожнім полем Name_book, що можна побачити на рисунку 3.3.3.1.Там книга з інформацією про печатне видання, автора, жанр та серію має порожнє поле назви книги.
Ситуація, що викликає тригер:
Рисунок 3.7 – Долучення елемента з порожнім полем
Після роботи тригера ми отримаємо замис з полем заповненим за змовчуванням значенням у полі "Name_book".В таблиці порожнє поле назви книги заміниться записом "не вказана"
Результат роботи тригера зображено на рисунку 3.8
Рисунок 3.8 – Результат роботи тригера
Ще одним прикладом тригера у даному курсовому проекті для таблиці "Series" був розроблений тригер – "Triger2". Дія цього тригера направлена на оновлення інформації про кількість книг у серії. При вводі змін книг у серії він буде додавати попередню кількість книг.Код тригера:
CREATE DEFINER = 'root'@'localhost' TRIGGER `Triger2` BEFORE UPDATE ON `series`
FOR EACH ROW
BEGIN
SET NEW.Number = NEW.Number + OLD.Number;
END;
Початкова ситуація зображена на рисунку 3.9
Рисунок 3.9 – Початкова кількість книг в серії
До серії "Гаррі Поттер" потрібно додати одну книгу.
Ситуація потребуюча тригер зображена на рисунку 3.10:
Рисунок 3.10 – Долучення книги до серії
Після роботи тригера ми отримаємо загальну кількість книг у серії "Гаррі Поттер"
Результат зображено на рисунку 3.11
Рисунок 3.11 – Результат роботи тригера
Тригери є дуже зручним рішенням інформаційних аномалій, регулювання змін в базі даних та забезпечення виконання системи бізнес-правил.
ВИСНОВКИ
Під час виконання КП були вивчені основи проектування концептуальної та логічної БД, роботи в вільній реляційній системі керування базами даних My SQL, а також визначили предметну область, основні сутності БД, визначили інформацію яка буде міститись в базі даних. Була визначена система бізнес-правил, дані які будуть міститися в таблиці згідно вимогам і завданням КП.
Дана БД забезпечує надійне зберігання інформації, а також істотну економію часу, що витрачається на пошук, редагування існуючих даних. При створенні даної бази даних була, проаналізувала предметна область, в даний випадку це область бібліотеки. Була проаналізована інформаційна структура бібліотеки, її особливості функціонування, сформульовані вимоги до бази даних бібліотек. В результаті виконання даного курсового проекту всі поставлені цілі і завдання були виконані. Були описані технології функціонування ІС, побудовані концептуальна і логічна моделі БД, виконано фізичне проектування БД, розроблена функціональної моделі СКБД, розроблені запити для існуючої БД, розроблені тригери для запобігання інформаційних аномалій, розроблені збережені процедурі для виконання.
При розробці бази даних проект було розділено на три розділи :
Розділ 1. Було розглянуто основні проблеми створення сучасних баз даних, зберігання даних, сучасні тенденції у розробці БД
Розділ 2. Була проаналізована ПрО, розроблена концептуальна модель даних та система бізнес-правил. Особливу увагу приділено трансформуванню концептуальної в логічну модель даних засобами CASE-системи ErWin.
Розділ 3.Було розглянуто мотивований вибір СКБД для реалізації проекту, реалізація БД, результати, одержувані при роботі з БД, розроблені уявлення для відображення результатів вибірки, спроектовані збережені процедури, розроблені механізми управління даними в базі за допомогою тригерів.
Результатом роботи над КП є створена працездатна база даних, перевагами якої є зручність, швидкість знаходження серед великої кількості інформації.
1. Н.Ф.Халімон, О.І. Никопоренко, А.В. радченко: Система керування базами даних Access. – К.: НАУ, 2009. – 88 с.
2. Створення проектів у візуальному об’єктно-орієнтованому середовищі C++ Builder – методичні вказівки до виконання лабораторних тобіт та завдання на курсовий проект.
3. Дейт К. Дж. Введение в системы баз данных.- 7-е изд.: Пер. С англ. – М.: Издательский дом «Вильямс», 2011. – 1072 с.
4. Джеймс Р. Грофф, Пол Н. Вайнберг. SQL : Полное руководство: Пер. С англ. – К.: Издательская группа BHV, 2009.- 608 с.
ДОДАТОК
Візуальна схема БД
Візуальна схема БД