Анализ       Справочники       Сценарии       Рефераты       Курсовые работы       Авторефераты       Программы       Методички       Документы     опубликовать

Бд и субд. Классификация и примеры




Скачать 326.53 Kb.
НазваниеБд и субд. Классификация и примеры
страница3/3
Дата01.10.2014
Размер326.53 Kb.
ТипДокументы
1   2   3

Нормализация, аномалии, плюсы и минусы, 1НФ

-пошаговый процесс приведения БД к некоторому более удобному ”совершенному” состоянию

Цель нормализации-устранить аномалии в табл

Аномалия-некот особ-ть в структуре табл, кот приводит к неудобствам в работе(например, повторный ввод 1 и тех же данных, нежелательная потеря связей,..)

Аномалии бывают 3х видов: вставки, редактирование, удаление

Нормализация примен либо на ранних этапах проектирования, сразу после построения модели сущность-связь, либо вместо создания ER-модели

До появления ER-модели это был основное инструмент проектирования

В процессе нормализации БД приводится к 6 так называемым нормальным формам:

1NF, 2NF, 3NF, BCNF, 4NF,5NF

Каждая базируется на предыдущей, является в чем то лучше нее

В процессе происходит дробление таблиц на несколько более мелких, это-недостаток нормализации

1НФ требует наличия в таблице только атомарных столбцов, столбец в кортеже должен иметь только 1 значение

Является следствием 1 из св-в реляц БД, атрибуты могут содержать только 1 значение

Сотрудник: имя должность, телефон – не атомарный, мб несколько



Имя

Телефон дом

Тел моб

Ввести для каждого значения свой атрибут, на практике



Имя

Телефон

1, 2,…



дб так:

рисунок

Многозначный атрибут выносится в отд таблицу, с кот уст-ся идент связь 1 ко многим

По первичному ключу 1 таблица

Телефоны

1 3495793

2 439509


2НФ. 
Основана на понятии функуиональной зависимости. В отношении Х→У атрибут У функционально зависит от атрибута Х, если атрибуту Х соответствует только 1 значение атрибута У. В отношениях с несоставным РК все атрибуты функционально зависят от РК. Пример (опровергающий). Заказчики:


CustID

CustName

1

2

3



1

Ив

Пет

Сид



Соловьев

Соловьев не может быть из-за ограничения РК. Проблемы, когда первичные атрибуты составные, тогда вводят понятие полной функциональной зависимости. Функциональная зависимость Х→У полная, если У не зависит функционально от любого подмножества Х, т.е. атрибут У должен функционально зависеть от всего РК, но не от какой-либо его части. Частичная зависимость не допускается. Отношение находится во 2NF <=> когда находится в 1NF и каждый неключевой атрибут функционально полно зависит от РК. Не ключевой – не является ни РК, ни его частью, не является возможным РК. Пример. Управление проектами. 1) сотрудники. 2) 1 сотрудник может участвовать в нескольких проектах и 1 проект может содержать несколько сотрудников. 3) в рамках проекта у сотрудника только 1 задание. № сотр и № проекта – составной РК, Зарплата, Должность, Задание. Выявить РК. РК – уникальный. Рассмотрим, какие имеются функциональные зависимости. 1. (№сотр, №проекта) → задание. 2. № сотр → должность. 3. №сотр → зарплата. 2 и 3 от части РК, т.е. противоречит условиям 2NF, т.к. имеется зависимость неключевого атрибута от части РК. Аномалии. Вставки: не можем добавить сотрудника в организацию, не включив его сразу в проект, т.к. № проекта – часть РК – не может быть пустым. Включая сотрудника в новый проект должны многократно переписать должность и зарплату. Модификации: при изменении должности или зарплаты должны это сделать во всех строчках, где он встречается, что чревато ошибками. Удаление: удаляя сотрудника из его последнего проекта мы автоматически удаляем его из организации. Решение: разбиваем на 2 сущности: сотрудники, занятость сотрудников. Картинка. Алгоритм: в первом отношении РК становится тот атрибут, от которого имеется частичная зависимость. Остальные атрибуты зависят от него функционально. Во втором отношении сохраняется РК второго отношения (сотрудник и проект) и указываются только те атрибуты, которые функционально полно от него зависят. 1 отношение связано со 2 идентифицирующей связью 1 ко многим. И 1 и 2 отношение удовлетворяет NF. Если бы была информация о проекте, то ее нужно было бы ввести в новую сущность (отношение).
3НФ
Атрибут У зависит от Х транзитивно Х → У, если существует атрибут Z: X→Z, Z→Y. Приводят к проблемам. Предположим: СотрНом, Должность, Зарплата. Имеем зависимости: СотрНом→Должность, СотрНом→Зарплата, Должность→Зарплата. Аномалии: Модификации: при попытке изменить зарплату – должны изменить ее столько раз, сколько должность человека встречается; Удаление: если удаляем последнего человека, работающего в некоторой должности, то теряется информация о должности; Вставка: когда принимаем много людей в 1 должности, происходит дублирование информации, что чревато ошибками. Отношение находится в 3NF <=> находится во 2NF и каждый неключевой атрибут нетранзитивно зависит от РК. В данном случае зарплата транзитивно зависит от РК (СотрНомер). Решение: картинка. Алгоритм: атрибуты, зависящие от РК транзитивно, выносятся в отдельную сущность, она связывается по транзитивному ключу с дочерней сущностью, неидентифицирующей связью с сущностью, содержащей остальные атрибуты. Каждый факт в 1 листе. На практике 3NF ограничиваются, и базу, которая ей удовлетворяет, называют нормализованной.
БКНФ
NF Бойса-Кодда. Отношение находится в BCNF <=> когда оно находится в 3 NF и каждый детерминант – возможный ключ. Детерминант – атрибут, от которого что-то зависит, т.е. функционально зависит какой-то другой атрибут. BCNF – усиленная 3 NF. Пример: СотрНомер, ПроектНомер, Задание, УчетнИмяСотр. (СотрНомер, ПроектНомер) → задание. (ПроектНомер, УчетнИмяСотр) → задание. Только составной первичный ключ. Отношение относится и к 2 NF и к 3 NF. СотрНомер → УчетнИмяСотр, УчетнИмяСотр → СотрНомер. Вроде как 2NF, но от РК зависит ключевой атрибут. Вроде как 3NF, но нет транзитивности. Аномалии: модификации и вставки: при включении человека в проект, должны указать и УчетнИмяСотр, и СотрНомер, а т.к. проектов много, происходит дублирование информации. Причина: УчетнИмяСотр и СотрНомер – детерминанты, но не являются РК. Решение: Картинка. Алгоритм: вводится отношение, где детерминант является РК, от него связь 1 ко многим к отношению, где находятся все остальные атрибуты. В качестве первичного ключа можно выбрать любой детерминант.
4НФ
В отличие от предыдущих не использует понятие функции зависимости, но опирается на понятие многозначной зависимости. В отношении с атрибутами (A, B, C) С многозначно зависит от А. А→>C, если он зависит от А и не зависит от В, т.е каждому значению атрибута А соответствует некоторое неизменное множество значений атрибута С. Пример. № зачетки, № группы, предмет. Отношение описывает, какие предметы должны сдавать студенты каждой группы.

№ зач

№ гр

Пред

1

1

2

2



4

4

4

4



Ист

Филос

Ист

Филос



Многократное дублирование данных возможно, РК составной. Отношение относится к первым 4-ем NF. 2 функциональных зависимости: № гр→№ зач, № гр → предмет. Аномалии: вставки при добавлении студента в группу, необходимо заново для него записывать все предметы. При попытке изменить состав предметов это придется делать для всех студентов в данной группе. Причина в многозначных зависимостях. Отношение находится в 4 NF <=> находится в BCNF, а при наличии многозначной зависимости А→>C, все остальные атрибуты функциональны, т.е. не многозначно зависят от А. Решение: разбиваем на 2 отношения: (№ гр, предм) и (№ гр, № зач). Каждое из отношений относится к 4 NF. При необходимости они могут быть связаны внутренним соединением по ключу № гр (оператор Select).
^ Пример проектирования методом нормализации. 
Отношение Заказчики. Атрибуты: CustID, CustName, Address, OrderID (PK), SaleData, Total, ProductID (PK), ProdCount, Price, Rest, ProdName

Приводим ко 2 NF^

(OrderID, ProductID, ProdCount)

(ProductID, ProdName, Rest, Price)

(CustID, OrderID, Address, CustName, SaleData, Total)

Последнее отношение не относится к 3 NF, т.к. CustName и Address зависят не от первичного ключа, следовательно разбиваем еще на 2:

(CustID, CustName, Address)

(CustID, OrderID, SaleData, Total)

Все таблицы относятся к 3 NF – нормализовано.
Представления. 
Представление - виртуальная (логическая) таблица, представляющая собой поименованный запрос, который будет подставлен как подзапрос при использовании представления. Упрощает написание многих сложных запросов. Имя представления может присутствовать везде, где присутствует имя таблицы. Представления и таблицы равноправны. Представления скрывают от пользователя структуру БД. Вместо столбцов – синонимы. Обращения к базам через представления. Представления для пользователя уменьшают негатив от результатов нормализации. Плюс нормализации: устранение аномалий, минус: дробление БД, т.к. для соединения БД сложные операции. Наряду с нормализацией, обратный процесс – денормализация (соединение уже нормализированных таблиц), чтобы работало быстрее. Пользователь не знает, в каком состоянии таблица. По ходу эксплуатации базы структуру таблицы можно менять, не меняя представления.

Create view <имя представления>

[<список столбцов>] //использующихся в качестве псевдонимов

As <оператор select>

[with check option] //с возможностью проверки
Create view GetPhones

As

Select CustName as FIO, Phone as PhoneName



Customers.CustID = Phones.CustID

Представления могут использоваться в операторах модификации (вставка, обновление, удаление). Но для этого они должны удовлетворять требованиям: не содержать подзапросов. Группировок, соединений и т.д. Недостаток – нельзя использовать параметры.
Индексы. 
Индексы – вспомогательная структура в БД, которая формирует логический порядок записи. Используются для сортировки или поиска. Без индексов эти процессы идут очень медленно. Индексы создаются по столбцу или группе столбцов. При активном индексе таблица для пользователя выглядит упорядоченной, хотя физический порядок может отличаться (тот порядок, как мы вставляли). По первичным ключам индексы создаются автоматически. Иногда автоматически создаются по внешним ключам. Программист может сам создать индекс по столбцам, по которым часто происходит поиск.

Create.index [unique] [asc|desc] <имя индекса> //порядок по возрастанию|убаванию

On <имя таблицы> (список столбцов). Пример

Create.index FIOind on Customers (CustName). Создали индекс по имени. Удаление индекса

Drop.index <имя индекса>. Перестройка индекса

Alter.index <имя>

Activate|deactivate

Индекс занимает много места и при вставке данных должны менять и индекс и таблицу, т.е. индекс и замедляет, и ускоряет. При многочисленной вставке, лучше индекс deactivate. При activate индекс строится заново, поэтому активировать лучше, когда сервер не очень используется. Существует несколько способов: плотные индекса и B-Tree. Организация плотных индексов: наиболее быстрый – физический поиск строки в таблице по ее номеру. Длина строки L в реляционных СУБД известна. Следовательно, зная номер можно найти адрес нужной записи. a=b+(k-1)L+1, k – номер записи, b – адрес начала таблицы. Пример

столбец

Физ № записи

Иванов

Лебедев

Петров

Сидоров

Соловьев

3

5

1

2

4







CustName

1

2

3

4

5

Петров

Сидоров

Иванов

Соловьев

Лебедев

Поиск в 2 этапа: 1. Быстрый бинарный поиск по индексу. Результат – физический номер. 2. Номер подставляется в формулу. Результат – адрес. По адресу – поиск мгновенный. С индексами только критичные столбцы, по которым происходит постоянный поиск.
^ ЭС, модели знаний. 
Экспертные системы - одно из направлений AI (искусственного интеллекта). Делятся на: нейрокибернетические, черный ящик. Нейрокибернетика – основа человеческого мозга, нейросети. Черный ящик – не важно, как устроена система интеллекта, главное, чтобы выдавала правдоподобный результат. Основные направления AI: 1. представление знаний и разработка систем, основанных на знаниях. 2. распознавание образов, машинный перевод. Экспертная система – аппаратно-програмный комплекс, может воспроизводить процесс решения проблемы. Задача – выдача заключений, рекомендаций, прогнозов. Включает в себя средства накопления и хранения знаний. Типовая структура экспертной системы: картинка. Решатель – алгоритм работы с базой знаний. База знаний – пополняема знаниями данной предметной области. Пополнять имеют право специалисты, эксперты или инженеры по знаниям (специалист данной системы). Отличается от БД внутренними форматами. Могут использоваться реляционные модели. Главное отличие в характере информации. Хранятся факторы, выводы, заключения, связи. Полученные знания тоже могут добавляться в базу знаний. Является ядром. Представление знаний и выводы о знаниях. Данные – отдельные факты предметной области. Знания – закономерности, полученные в результате анализа данных. Применяется 2 способа выразить понятие: интенсионал и экстенсионал. Интенсионал – определение понятия через соотнесение его с понятием более высокого уровня. Экстенсионал – определение через понятие более низкого уровня. Связи бывают и других типов, обозначаются глаголами: является частью, состоит в, это принадлежит. Способ представления зависит от модели знаний. 3 классические модели знаний: продукционные, семантические сети, фреймы. Продукционная – самая популярная в диагностике, медицинской и технической, при тестировании и т.д. В данной модели содержатся правила: если (условие), то (действие). Любое количество таких правил. Условие – исходное положение, может быть сложным. Записывается через логические операции: and, or, not. Пример: если (IQ>100), то (интеллект высокий). Действие может быть частью условия в каких-то других правилах. Пример: если (интеллект высокий AND 5 по математике), то (математические способности). Если (математический способности AND любит программирование), то (поступать на ПММ). Если (математические способности AND не любит программирование), то (поступать на матфак). Достоинство – простота. Решатель многократно просматривает совокупность правил, пока не найдет точного совпадения. Семантические сети – знания в виде ориентированного графа. Узлы – понятия. Ребра – связи (глаголы, наречия). Семантическая сеть отвечает современным представлениям об организации долговременной памяти. Задача поиска в базе – нахождение подграфа, удовлетворяющего условию. Минусы: сложности хранения, редактирования, поиска. Фреймы – абстрактный образ или стереотип восприятия. Комната – с потолком. Аудитория – комната с доской, партами. Фреймы наследуют друг друга.
1   2   3



Разместите кнопку на своём сайте:
Документы




База данных защищена авторским правом ©kiev.convdocs.org 2000-2013
При копировании материала обязательно указание активной ссылки открытой для индексации.
обратиться к администрации
Похожие:
Документы