ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 16.03.2024
Просмотров: 37
Скачиваний: 0
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
Через надмірності інформації в базі даних виникають не тільки проблеми модифікації, додавання та видалення даних з бази даних, а й гостро постає питання економії місця на диску, погодьтеся нерозумно зберігати одну і ту ж інформацію в різних місцях. Надмірність баз даних тісно пов'язана з нормальними формами. Точніше, інформаційна надмірність - це негативний фактор, що впливає на цілісність бази даних, що змушує нас приводити свої бази даних до нормальної форми.
Інформаційна надмірність - термін з теорії інформації, що означає перевищення кількості інформації, використовуваної для передачі або зберігання повідомлення, над його інформаційної ентропією.
Інформаційна ентропія - це міра невизначеності інформації, невизначеність появи якого-небудь символу.
Будь-яка база даних призначена для зберігання інформації. І при проектування бази даних слід врахувати те, що якась інформація може повторюватися кілька разів. А кожна повторювана запис - це зайняте місце на диску. Тобто перевищення кількості інформації необхідного для зберігання даних.
Надмірність даних в базі даних - це небажане явище ще й тому, що при роботі з таблицями бази даних (які ще називають відносинами), що містять надлишкові дані, виникають проблеми пов'язані з обробкою інформації, ці проблеми називаються аномалії.
Нормалізація, нормальні форми та функціональні залежності
Нормалізація – це розбиття таблиці на дві або більш, що мають кращі властивостями при включенні, зміні і видаленні даних. Остаточна мета нормалізації зводиться до отримання такого проекту бази даних, в якому кожний факт з'являється лише в одному місці, тобто виключена надмірність інформації. Це робиться не стільки з метою економії пам'яті, скільки для виключення можливої суперечності даних.
Кожна таблиця в реляційній БД задовольняє умові, відповідно до якої в позиції на перетині кожного рядка і стовпця таблиці завжди знаходиться єдине атомарне значення, і ніколи не може бути безлічі таких значень. Будь-яка таблиця, що задовольняє цій умові, називається нормалізованою. Фактично, ненормалізовані таблиці, тобто таблиці, що містять групи , які повторюються, навіть не допускаються в реляційній БД.
Перша нормальна форма
Перша нормальна форма вимагає, щоб кожне поле таблиці було неподільним і не містило повторюваних груп.
Неподільність означає, що поле даних не повинно поділятися на більш дрібні. Наприклад, якщо мова йде про БД для відділу кадрів, то у таблиці з інформацією про співробітників поле "Прізвище" є неподільним, подільність поля "ПІП" залежить від контексту використання відповідної таблиці. Якщо у процесі експлуатації БД не передбачається використовувати такі запити, як "Обрати всіх Івановичів", то поле ПІП теж можна вважати неподільним. А от адресу краще розділити на вулицю, будинок і квартиру, тобто на 2 чи 3 поля, тоді буде простіше здійснити відюір всіх, то живе на одній вулиці. Хоча,
можуть бути випадки, коли його доцільно вважати неподільним (наприклад, якщо адреса є другорядною та рідковживаною інформацією).
Неповторюваність означає, що ми у якихось полях не повторюємо значення інших полів. Мається на увазі не та ситуація, коли у якійсь таблиці вказали кілька полів з однаковими значеннями.
Друга нормальна форма
Таблиця задовольняє другій нормальній формі, якщо вона виконує, по-перше вимоги першої нормальної форми та, по-друге, кожен її рядок таблиці однозначно і ненадлишково визначається первинним ключем. Тут є кілька варіантів. Перший - якщо радки таблиці, у яку вводиться інформація (наприклад, накладні на продажі) нумеруються щодня починаючи з першої, то номер не може однозначно визначити накладну, і не може бути первинним ключем. А номер разом з датою - може. Можна пошукати первинні ключі серед наявних полів (табельний номер співробітників), а можна спробувати об'єднати кілька, намагаючись забезпечити унікальність
Дуже простий варіант - створювати поле-лічильник і вказувати його в якості первинного ключа.
Третя нормальна форма
Третя нормальна форма вимагає виконання вимог першої та другої нормальних форм. А крім того, щоб значення будь-якого поля, що не входить у первинний ключ, не залежало від інших полів, що не входять у первинний ключ. Вважається, що перших трьох нормальних форм досить для більшості практичних застосувань, хоча в теорії БД існують ще й інші, більш складні означення нормальних форм.
Нормальна форма Бойса-Кодда
Відношення знаходиться в нормальній формі Бойса-Кодда тоді і тільки тоді, коли детермінанти є потенційними ключами.
Концепція НФБК дозволяє позбавитися проблем, властивих формам, відповідним визначенню ЗНФ. Більш того, нове визначення концептуально простіше старого, оскільки в ньому не використовуються поняття 1НФ, 2НФ, первинного ключа або транзитивної залежності. Поняття потенційного ключа може бути замінене введенням фундаментальнішого поняття функціональної залежності. З другого боку, концепції первинного ключа, транзитивної залежності і т.д. вельми корисні на практиці, оскільки дозволяють представити ідею поступового процесу, виконуваного розробником для приведення довільного відношення до еквівалентного набору відносин в НФБК.
Схема відношення R з залежностями F знаходиться в нормальній формі Бойса-Кодда, якщо кожен раз, коли в R має місце залежність x
A і A
x , х включає деякий ключ R. Іншими словами допукаються тільки такі нетривіальні залежності, в яких ключ функції визначає один або більше інших атрибутів.Схема відношення може знаходитись в третій нормальній формі, але не може бути в формі Бойса-Кодда. Нормальна форма Бойса-Кодда позбавляє від аномалій включення, видалення і надлишковості. Відношення, що представляють деякий набір об’єктів, або відображення типу багато до одного між наборами об’єктів, будуть знаходиться в нормальній формі Бойса-Кодда.
Метод: декомпозицію r для R конструюємо ітеративним методом. При цьому r весь час буде володіти властивістю з’єднання без втрат відносно F. Якщо S схема ... з r і s не знаходиться в НФБК, то нехай x A – залежність, що має місце в S, де х – не містить ключа S, а А не належить х (A x). Тоді в S повинен існувати деякий атрибут, який не належить А і не належить х. В іншому випадку х повинен містити ключ S. Задінемо S на S1 і S2, де S1 складається з А і атрибутів х (S1={А,х}), а S2 з усіх атрибутів S за виключенням А.
Оскільки в S1 та S2 менше атрибутів ніж в S, ми досягаємо деякого моменту, коли еквівалентна схема відношення r буде знаходитись в НФБК. При цьому r володіє властивістю з’єднання без втрат.
Теорія нормалізації грунтується на наявності функціональної залежності між полями таблиці.
Функціональна залежність. Поле В таблиці функціонально залежить від поля А тієї ж таблиці в тому і лише у тому випадку, коли в будь-який заданий момент часу для кожного з різних значень поля А обов'язково існує тільки одне з різних значень поля В.
Алгоритм декомпозиції
Алгоритм декомпозиції являє собою послідовніть кроків розбиття схеми так, що кожна з них містить одну з функціональних залежностей, які створюють транзитивність.
Нехай R не знаходиться в третій нормальній формі відносно множини F-залежностей F. Необхідно розкласти цю схему бази даних так, щоби вона була приведеною до третьої нормальної форми, тобто нормалізованою. Розклад схеми відношень позначає розбиття схеми відношення на пару схем відношень R1 і R2 (які, можливо, перетинаються) так, щоб будь-яке відношення r (R), що задовольнить F, розкладалося без втрат на R1 і R2. Тобто розбиття відбувається таким чином, що при будь-якому значенні атрибута з dom r - відношення чи проекція ПрR1 (r) *ПрR2 (r) = r для всіх R. Якщо щось з R1 і R2 не буде знаходитися в 3-й нормальній формі, то необхідно буде повторити процес декомпозиції.
Розглянемо дії по розбиванню схем, нехай існує транзитивна залежність від ключа в схемі R. Існує ключ, котрий не є власною підмножиною для схеми R і не первинний атрибут А, що є елементом схеми R, такі, що К → У і У функціонально визначає А. видно, що існує транзитивна залежність. У функціонально не визначає К - виключена умова "один в один". Тоді нехай R1 буде представлене як R1=R-A і R2=YA (розрізаємо транзитивність). А може бути не єдиним атрибутом, а множиною атрибутів. Тоді умова зберігання буде виконуватися, R2 буде знаходитися в 3-й нормальній формі, а R1 може не знаходитися. Це твердження стосується випадку, коли А - окремий атрибут..
Негативні моменти:
1. Нормалізація призводить до збільшення об'єма даних та зв'язків між таблицями.
2. Після кожного кроку розбиття необхідно робити перевірку вимог третьої нормальної форми.
3. Процес декомпозиції може давати неоднозначні результати.
Найпопулярніші СУБД, що встановлюються в невеликих організаціях і орієнтовані на роботу з кінцевими користувачами, є Access, FoxPro, Paradox.
Системою управління базами даних є додаток Access, що входить в Microsoft Office. У Access використовується стандартний для середовища Windows & Offiсе багатовіконний інтерфейс, але на відміну від інших додатків, що не багатодокументний. Одноразово може бути відкрита тільки одна база даних, що містить обов'язкове вікно бази даних і вікна для роботи з об'єктами бази даних. У кожен момент часу одне з вікон є активним і в ньому курсором відзначається активний об'єкт. На рис. 1 зображене головне вікно бази даних, після входа в меню Пуск
Рис. 1. Головне вікно бази даних
Тип даних поля можна уявляти собі як набір характеристик, які відносяться до всіх значень, що містяться в полі, і які визначають, якого роду можуть бути ці значення. У таблиці 2 наведені використовувані типи даних та їх розмір.
Таблица 2. Типы данных , использование и их размер
| ТИП ДАННЫХ | ИСПОЛЬЗОВАНИЕ | РАЗМЕР |
| Краткий текст (ранее известный как "Текст") | Алфавитно-цифровые данные (имена, названия и т.д.) | До 255 знаков. |
| Полный текст (ранее известный как Memo) | Большие объемы алфавитно-цифровых данных: предложения и абзацы. | До 1 гигабайта (ГБ), но контроль отображения полного текста ограничен первыми 64 000 знаков. |
| Числовой | Числовые данные. | 1, 2, 4, 8 или 16 байт. |
| Date/Time | Значения даты и времени. | 8 байт. |
| Денежный | Денежные данные, хранящиеся с точностью до 4 десятичных знаков после запятой. | 8 байт. |
| AutoNumber | Уникальные значения, сгенерированные Access для каждой новой записи. | 4 байта (16 байт для кода репликации). |
| Yes/No | Логические (истина/ложь) данные. Access хранит числовое значение нуль (0) для лжи и -1 для истины. | 1 байт. |
| Объект OLE | Изображения, графики или другие объекты ActiveX из другого приложения Windows. | До 2 ГБ. |
| Гиперссылка | Адрес ссылки на документ или файл в Интернете, интрасети, локальной сети или на локальном компьютере | До 8192 (каждая часть типа данных гиперссылки может содержать до 2048 знаков). |
| Вложение | Можно вкладывать изображения, документы, электронные таблицы или диаграммы. Каждое поле вложений может содержать неограниченное количество вложений на одну запись, вплоть до допустимого размера файла базы данных. | До 2 ГБ. |
| Вычисляемый | Можно создать выражение, использующее данные из одного или более полей. Из выражения можно назначить различные типы данных результатов. | Зависит от типа данных свойства "Тип результата". Результат типа данных "Краткий текст" может содержать до 243 знаков. Данные типа "Полный текст", "Числовой", "Да/нет" и "Дата/время" должны соответствовать своим типам данных. |
| Мастер подстановок | Запись "Мастер подстановок" в колонке "Тип данных" в "Конструкторе" фактически не является типом данных. При выборе этой записи запускается мастер, чтобы помочь определить простое или сложное поле подстановки. Простое поле подстановки использует содержимое другой таблицы или списка значений, чтобы проверить правильность содержимого единственного значения в ряду. Сложное поле подстановки позволяет хранить множественные значения одного типа данных в каждом ряду. | Зависит от типа данных поля подстановки. |
Зв’язки
Сучасні бази даних зазвичай містять велику кількість взаємозв'язаних таблиць, що дозволяє уникнути повторів. Наприклад, крупні фірми можуть зберігати відомості про магазини в одній таблиці, номенклатуру товарів, отриманих цими магазинами в поточному місяці в іншій таблиці, а відомості про оптових покупців в третій таблиці. Access дозволяє працювати одночасно з декількома таблицями, кожна з яких повинна містити записи, присвячені певній темі. Зв'язок між ними встановлюється по загальних для декількох таблиць полях, наприклад, номера магазинів, через які здійснюється реалізація товару. Бажано, аби в одній з таблиць загальне поле було ключовим. Якщо таблиці взаємозв'язані, то зміни, виконані в записі однієї таблиці, можуть впливати на записі в іншій таблиці.
Для збереження повноти і цілісності даних Access накладає певні обмеження на введення і редагування даних, наприклад, неможливо видалити запис з однієї таблиці, якщо існують пов'язані з нею записи в інших таблицях.
Реляційна база даних може містити велику кількість взаємозв'язаних таблиць. Зв'язку встановлюється між двома загальними полями (стовпцями) двох таблиць. Зв'язувані поля можуть мати різні імена, але повинні мати однакового типа даних за винятком випадку, коли поле первинного ключа є полем типа Лічильник. Поле лічильника зв'язується з числовим полем, якщо значення властивості Розмір поля (FieldSize) обоє полів збігаються. Наприклад, якщо властивість обоє полів має значення Довге ціле. Навіть у тому випадку, коли зв'язуються поля типа «Числовою», їх властивості Розмір поля (FieldSize) повинні мати однакові значення.
Задавши зв'язки між таблицями, можна створити запити, форми і звіти для відображення відомостей, представлених в декількох таблицях. Між двома таблицями можуть існувати наступні зв'язки:
-
один до одного — при такому типові зв'язку одного запису в першій таблиці відповідає лише одна запис в іншій таблиці. В цьому випадку слід перевірити можливість розміщення всіх записів в одній таблиці. Проте у ряді випадків можна використовувати декілька простіших таблиць. Відповідність записів встановлюється по полю, яке є первинним ключем в першій таблиці, і полю, званим зовнішнім ключем іншої таблиці; -
один до багатьом — в цьому випадку запис однієї таблиці може мати декілька погоджених з нею записів в іншій таблиці. При цьому кожен запис в другій таблиці узгоджується лише з одним записом в першій таблиці. Наприклад, кожен покупець може купити декілька товарів, але кожен проданий товар має лише одного покупця. Поле, що містить первинний ключ нової таблиці, зв'язується із зовнішнім ключем старою. Значення в полі із зовнішнім ключем можуть повторюватися; -
багато до одного — будь-якому запису таблиці, зв'язок з якою ми розглядаємо, можуть відповідати декілька записів нової таблиці, але не навпаки. Фактично це відношення один до багатьом, що розглядається, в зворотному порядку. В цьому випадку ключове поле нової таблиці є зовнішнім ключем; -
багато до багатьом — кожному запису з однієї таблиці може відповідати будь-яка кількість записів в іншій таблиці і навпаки. Наприклад, кожна людина може дзвонити з декількох телефонів. З іншого боку деякими телефонами можуть користуватися декілька чоловік. В цьому випадку поля, по яких встановлюється зв'язок, є зовнішніми ключами. Вони можуть містити значення, що повторюються.
