Проектування бази даних. Створення структури реляційної бази даних



Скачати 105.45 Kb.
Дата конвертації26.12.2016
Розмір105.45 Kb.
Тема: Проектування бази даних. Створення структури реляційної бази даних.

План.

  1. Принципи побудови баз даних.

  2. Концепція побудови баз даних.

  3. Етапи проектування баз даних.

  4. Структура таблиці.




  1. Принципи побудови баз даних.

До сучасних баз даних, а, отже, і до СУБД, на яких вони будуються, пред'являються наступні основні вимоги.

1. Висока швидкодія (малий час відгуку на запит).

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

2. Простота оновлення даних.

3. Незалежність даних.

4. Спільне використання даних багатьма користувачами.

5. Безпека даних - захист даних від навмисного чи ненавмисного порушення секретності, спотворення або руйнування.

6. Стандартизація побудови та експлуатації БД (фактично СУБД).

7. Адекватність відображення даних відповідної предметної області.

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

Незалежність даних передбачає інваріантність до характеру зберігання даних, програмного забезпечення і технічних засобів. Вона забезпечує мінімальні зміни структури БД при змінах стратегії доступу до даних і структури самих вихідних даних.Це досягається «зсувом» всіх змін на етапи концептуального і логічного проектування з мінімальними змінами на етапі фізичного проектування.



Безпека даних включає їх цілісність і захист.
Цілісність данихстійкість даних, що зберігаються до руйнування і знищення, пов'язаних з несправностями технічних засобів, системними помилками і помилковими діями користувачів.

Вона передбачає:

1. відсутність неточно введених даних або двох однакових записів про одне й те ж факт;

2. захист від помилок при оновленні БД;

3. неможливість видалення (або каскадне видалення) пов'язаних даних різних таблиць;

4. неспотворене даних при роботі в многопользовательском режимі і в розподілених базах даних;

5. збереження даних при збої техніки (відновлення даних).


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

1. введенням системи паролів;

2. отриманням дозволів від адміністратора бази даних (АБД);

3. забороною від АБД на доступ до даних;

4. формування видів - таблиць, похідних від вихідних і призначених конкретним користувачам.

Стандартизація забезпечує спадкоємність поколінь СУБД, спрощує взаємодію БД одного покоління СУБД з однаковими і різними моделями даних. Стандартизація (ANSI / SPARC) здійснена в значній мірі в частині інтерфейсу користувача СУБД і мови SQL. Це дозволило успішно вирішити завдання взаємодії різних реляційних СУБД як за допомогою мови SQL, так і з застосуванням програми Open DataBase Connection (ODBC). При цьому може бути здійснено як локальний, так і віддалений доступ до даних (технологія клієнт / сервер або мережевий варіант).


  1. Концепція побудови баз даних.

Існує два підходи до побудови БД, що базуються на двох підходах до створення автоматизованої системи управління(АСУ).

Перший з них, широко використовувався в 80-і роки і тому отримав назву класичного (традиційного), пов'язаний завтоматизацією документообігу (сукупність документів, що рухаються в процесі роботи підприємства). 

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

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

У роботі БД можливий одно-і багатокористувацький (кілька користувачів підключаються до одного комп'ютера через різні порти) режими.

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


  1. Етапи проектування баз даних.

Проектування баз даних відбувається в чотири етапи.

На етапі формулювання й аналізу вимог встановлюються цілі організації, визначаються вимоги до БД. Вони складаються з загальних вимог, визначених у розділі 1, і специфічних вимог. Для формування специфічних вимог зазвичай використовується методика інтерв'ювання персоналу різних рівнів управління. Всі вимоги документуються у формі, доступній кінцевому користувачу і проектувальнику БД.

Етап концептуального проектування полягає в описі і синтезі інформаційних вимог користувачів у початковий проект БД. Вихідними даними можуть бути сукупність документів користувача при класичному підході або алгоритми додатків (алгоритми бізнесу) при сучасному підході. Результатом цього етапу є високорівневе подання (у вигляді системи таблиць БД) інформаційних вимог користувачів на основі різних підходів.

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

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

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

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

На етапі фізичного проектування вирішуються питання, пов'язані з продуктивністю системи, визначаються структури зберігання даних та методи доступу.

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

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

Простіше справа при роботі з кількісними критеріями, до яких відносяться час відповіді на запит, вартість модифікації, вартість пам'яті, час на створення, вартість на реорганізацію. Утруднення може викликати протиріччя критеріїв одне одному.

У той же час існує багато критеріїв оптимальності, які є невимірними властивостями, важко виразність у кількісному поданні або у вигляді цільової функції.

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

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

Основними причинами низької ефективності проектованих БД можуть бути:

1. недостатньо глибокий аналіз вимог (початкові етапи проектування), включаючи їх семантику та взаємозв'язок даних;

2. велика тривалість процесу структурування, що робить цей процес стомлюючим і важко виконуваним при ручній обробці.

У цих умовах важливого значення набувають питання автоматизації розробки.


4. Структура таблиці.

Таблиця бази даних складається з рядків і стовпців. У системі Access рядок таблиці називається записом, а стовпчик – полем. 
Запис містить інформацію про один елемент таблиці бази даних: одну людину, книжку, продукцію, рейс тощо. Він складається зі значень полів, що формують структуру запису. Структура запису фактично визначає структуру таблиці і всієї бази даних, якщо в ній є лише одна таблиця. 

Запис складається зі значень всіх полів одного елементу таблиці

Поле - це мінімальна порція інформації в записі, над якою визначені операції введення, виведення, перетворення тощо

Кожне поле має ім'я, значення, характеризується типом і властивостями. 

Від властивостей залежить, які типи даних можна вносити до поля, а які -  ні, а також те, що можна виконувати з даними, які містяться у полях. 

Імена полів бажано задавати літерами англійського алфавіту. В одній базі даних імена полів не повинні повторюватись (бути унікальними). 

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

 Типи полів та їхні властивості

В Access використовують такі типи полів:   


Тип поля


Тип даних

1. Текстовий 


текстові дані не більше за 255 символів 


2. Числовий 


числові дані 


3. Дата/час 


дати, час 


4. Логічний 


дані, що набувають значень "так" чи "ні" 


 5. Грошовий 


грошові суми 


6. Поле об’єкту OLE 


зв’язані або впроваджені об’єкти (фотокартки, відео, звук і т.і.) 


7. МЕМО 

текстові дані не більше за 65535 символів 

8. Лічильник 


автоматично привласнює наступний порядковий номер запису 




Текстове поле. В текстовому полі можуть записуватись літери, цифри та інші символи. 

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

Поле Дата/час (Дата/время). Це поле використовують для запису дат та часу. Багато із властивостей цього поля такі самі, як і текстового поля.

Логічне поле. В логічному полі може записуватися одне з таких двох значень: “так” або “ні”, “хибне” чи “істинне” - “ввімкнено” чи “вимкнено”. Логічні поля можуть використовуватися з різною метою. Але найчастіше їх використовують в анкетних даних, де є тільки дві можливі відповіді. 

Поле типу лічильник (счетчик). Виконують як лічильник записів, його також часто використовують як ключове поле. 

Поле типу Memo.  В цьому полі може вміщуватися текст або комбінація тексту та чисел, що містить значну за обсягом інформацію. 

 Поле об’єкту ОLE. Це поле вміщує безпосередньо не інформацію про об’єкт, а посилання на ім’я об’єкту. Як ім’я об’єкту може бути ім’я додатку, наприклад, електронна таблиця Excel, редактор Word, засобами яких можуть бути створені об’єкти для впровадження їх у таблицю Access. Крім того, об’єктами можуть бути малюнки, звукозаписи. 

Властивості полів залежать від їхніх типів. Деякі властивості задаються програмою за замовчанням. 

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


База даних захищена авторським правом ©lecture.in.ua 2016
звернутися до адміністрації

    Головна сторінка