Головна
Лекції
Завдання
Побажання
Гостьова
Лінки
Лекція №7 Скачати лекцію

Лекція 8

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

 

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

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

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

Приклад: Інтернет-аптека.

Категорії користувачів, які працюють з віртуальною аптекою:

  • Покупці (користувачі, які вже зареєструвались в аптеці);
  • Анонімні відвідувачі (які не зареєструвалися);
  • Менеджери (користувачі,що мають більш широкі права доступу до даних).

Таблиці, в яких зберігаються вся інформація:

  • Каталог товарів (найменування, ціни);
  • Замовлення;
  • Зміст замовлень;
  • Покупці.
  1. Визначення потрібних таблиць та полів БД.
  • Потрібно написати перелік таблиць, з яких буде складатись БД, визначити їх імена;
  • Для кожної таблиці визначити потрібний набір полів та їх положення в таблиці;
  • Для кожного поля обрати тип даних, які в ньому зберігатимуться. Визначити розмір текстових полів та підтип числових;
  • Сформулювати правила перевірки даних для полів.

Правила та рекомендації, яких потрібно дотримуватись.

  • Намагайтесь включити в БД всю інформацію, яка буде необхідна в роботі.
  • Створюйте прості таблиці, які зручніше використовувати.
  • Уникайте давати таблицям імена, які можуть співпасти із зарезервованими словами СУБД (наприклад, SELECT, DATE), щоб уникнути помилок при виконанні запитів.
  • Якщо дані містять перерахування (наприклад, типи товарів, придивіться до них уважніше. Можливо ці поля доведеться виділити в окрему таблицю.
  • Не рекомендується вміщати в таблицю поля, значення яких є результатом виразу (тобто, може бути обчислене на основі даних інших полів таблиці, як у випадку з відомими значеннями кількості та вартості замовленого товару);
  • Призначення поля, в загальному випадку, повинне бути зрозуміле з його назви (Назва_товару).

Дублювання даних.

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

Приклад ненадлишкового дублювання.

С_Т

Співробітник

Телефон

Іванов І.М.

3271

Петров М.І.

4328

Сидоров Н.Г.

4328

Єгоров В.В.

4328

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

Приклад надлишкового дублювання.

С_Т_Н

Співробітник

Телефон

Н_комн

Іванов І.М.

3271

109

Петров М.І.

4328

111

Сидоров Н.Г.

4328 /-

111

Єгоров В.В.

4328/-

111

Це відношення доповнене атрибутом Н_комн (номір кімнати співробітика). Можна вважати, що всі співробітники з однієї кімнати мають один і той же номер телефону. Вцьому відношенні присутнє надлишкове дублювання даних. В звязку з тим, що Сидоров та Єгоров находяться в цій же кімнаті, що й Петров, їхні номери можна дізнатись із запису з відомостями про Петрова.

Можливий спосіб вихода із даної ситуації наведено на мал., де показані 2 відношення, отримані шляхом декомпозиції вихідного. Перше з них містить інформацію про номери кімнат, в якмх розміщені співробітники, а друге – інформацію про номери телефонів в кожній кімнаті. Тепер, якщо Петрова звільнять і видалять інформацію про нього з БД, це не призведе до втрати інформації про телефон в 111 кімнаті.

Співробітник

Н_комн

Іванов І.М.

109

Петров М.І.

111

Сидоров Н.Г.

111

Єгоров В.В.

111

Телефон

Н_комн

3271

109

4328

111

Процедура декомпозиції відношення на 2 відношення є основною процедурою нормалізації відношень.

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

Аномалії модифікації проявляються в тому, що зміна значення одного данного може потягнути за собою перегляд всієї таблиці, та зміну деяких іншиз записів таблиці. Так зміна телефону в 111 кімнаті потребуватиме перегляду всієї таблиці С_Т_Н, та зміну поля телефон в трьох записах.

Аномалії видалення – при видаленні даних з таблиці може втратитись інформація, не звязана напряму з видаленим даним. Видалення запису про Іванова призводить до втрати телефону в 109 кімнаті (табл. С_Т_Н).

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

Прикладом може бути операція введення нового співробітника в таблицю С_Т_Н. Безсумнівно буде неприродним зберігання відомостей в цій таблиці тільки про кімнату та номер телефону в ній, доки там не розміщений жодний співробітник. Більш того, якщо поле СПІВРОБІТНИК є ключовим, то зберігання в ній неповних записів з відсутнім прізвищем співробітника неприпустиме, через невизначене значення ключа.

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

Формування вихідного відношення

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

Приклад. Формування вихідного відношення.

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

ПІБ – прізвище та ініціали викладача.

Посада – посада, яку займає викладач.

Оклад – оклад викладача.

Стаж –стаж викладача.

Д_стаж – надбавка за стаж

Предмет

Група

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

Явна надлишковість заключається в тому, що в відношенні ВИКЛАДАЧ строки з даними про викладачів, що проводять занятття в декількох групах, повторюються відповідне число разів.

Неявна надлишковість в відношенні ВИКЛАДАЧ виявляється в однакових окладах у всіх викладачів, та однакових надбавках за однаковий стаж. При цьому, якщо при зміні окладів за посаду з 500 до 510, це значення зміниться в усіх викладачів крім Сидорова, то база стане суперечливою.

Нормалізація відношень

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

Атрибут В функціонально залежить від атрибута А, якщо кожному значенню А відповідає тільки одне значення В, позначається Аà B. Це означає, що в усіх кортежах з однаковим значенням атрибута А, атрибут В матиме те ж саме. В нашому випадку ПІБà ПОСАДА; ПІБà ПОСАДА; ПОСАДАà OКЛАД.

Функціональна взаємозалежність, якщо між атрибутами А<-->B є взаємнооднозначна відповідність. (ПІБ – ід. Код)

С залежить від А транзитивно, якщо Aà B, Bà C, а обернена залежність відсутня (ПІБà Посадаà Оклад).

Багатозначна залежність : якщо кожному значенню А, може відповідати більше одного значення В.

Виявлення залежностей між атрибутами відношення ВИКЛАДАЧ. ПІБ- унікальне. Існує залежність ПІБ à Стаж, та ПІБ à Д_Стаж, ПІБà Посада, але обернені залежності відсутні. ПІБ à Оклад, Посадаà Оклад, Окладà Посада

Відношення знаходится в першій нормальній формі, якщо всі його атрибути прості, мають єдине значення. Вихідне відношення – це відношення в 1НФ.

2НФ, відношення знаходиться в 2НФ, якщо воно знаходиться в 1НФ і кожний неключовий елемент функціонально повно залежить від первинного ключа. R1(ПІБ, Предмет, Група); R2 (ПІБ,ПОСАДА, ОКЛАД, СТАЖ, Д_СТАЖ);

Відношення R2 має транзитвні залежності:

ПІБà Посадаà Оклад;

ПІБà Окладà Посада;

ПІБà Стажà Д_Стаж;

Ці залежності теж породжують надлишкове дублювання. Приберемо їх.

Перетворимо відношення R2, отримавши R3 R4 R5, кожне з яких знаходиться в 3НФ. R3 (ПІБ, Посада, Стаж); R4(Посада,Оклад); R5(Стаж, Д_Стаж);

На практиці процес проектування БД на цьому закінчується.

Рекомендації відносно розробки структур.

  1. Кожній сутності відводити окрему таблицю. Визначити її ключ (простий або складний);
  2. Якщо є повторення значень – виділити їх в допоміжну таблицю, при цьому неключові поля повинні бути незалежні.
  3. Визначити структурні обмеження – кожна таблиця повинна мати первинний ключ,

Цілісність посилань. Для кожного значення зовнішнього ключа в батьківській таблиці повинен існувати запис з таким ключем в допоміжній таблиці.

Настроювання та адміністрування БД

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

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

Можна виділити 3 основні задачі захисту:

  • Захист від розкрадання;
  • Захист в д втрати інформаціїї;
  • Захист від збоїв та відмов.

Існують 4 основних класи методів захисту:

  • Фізичні;
  • Апаратні (схеми блокування);
  • Програмні (парольний захист, ідентифікація користувачів, шифрування інформації, організація рівнів доступу);
  • Організаційні.

ВИКЛАДАЧ

ПІБ

Посада

Оклад

Стаж

Д_стаж

Предмет

Група

Іванов І.М.

викл

500

5

100

СУБД

262

Іванов І.М.

викл

500

5

100

Програмув.

267

Петров М.І.

Ст.викл

800

7

150

СУБД

263

Петров М.І

Ст.викл

800

7

150

Інформатика

250

Сидоров Н.Г.

викл

500

10

100

Програмув.

303

Сидоров Н.Г.

викл

500

10

100

Інформатика

248

Єгоров В.В.

викл

500

5

100

ПЕОМ

287

 

Лекція №7 Скачати лекцію

 

Hosted by uCoz