- •Основные понятия и определения баз данных и знаний (бдз)
- •Иерархическая модель данных
- •Сетевая модель данных
- •Реляционная модель данных
- •Основы реляционной алгебры
- •Термины и определения реляционных бд
- •Основные термины, используемые при нормализации данных
- •Первая, вторая, третья нормальные формы
- •Вторая нормальная форма
- •Третья нормальная форма
- •9. Нормальная форма Бойса-Кодда, четвертая и пятая нф
- •Нормальная форма Бойса-Кодда
- •Четвертая нормальная форма
- •Пятая нормальная форма
- •Проектирование связей между таблицами
- •11. Типы информационных моделей
- •Концептуальные и логические модели данных
- •Физические модели данных
- •Файловые структуры организации данных
- •Разрешение коллизий с помощью области переполнения
- •Разрешение коллизий методом свободного замещения
- •Индексные файлы и файлы с плотным индексом
- •Файлы с неплотным индексом
- •Иерархическая организация памяти
- •Организация кэш памяти
- •Алгоритм замещения lru и случайный алгоритм
- •Организация основной памяти
- •Виртуальная память
- •Бд и cals технологии
- •Системный подход при разработке многопользовательских ис
- •Стандартизация разработки ис
- •Организация многопользовательских субд
- •Разработка проекта субд в соответствии с тз в техническом задании необходимо:
- •Основные компоненты су реляционными бд
- •Язык запросов sql
- •Ddl (Data Definition Language) — операторы определения данных.
- •Язык определения данных
- •Язык манипулирования данными
- •Язык управления данными
- •Язык обработки транзакций
- •Язык управления курсором
- •Формат команды select
- •Простые запросы
- •Выборка по условию
- •Выборка на основе between …. And
- •Выборка на основе like, in
- •Сортировка строк
- •Группировка строк
- •Вычисляемые выражения и статистические функции
- •Выборка групп
- •Формализация знаний
- •Продукционная модель представления знаний
- •Исчисление предикатов первого порядка 1 вариант ответа:
- •2 Вариант ответа:
- •Семантическая сеть
Третья нормальная форма
Отношение находится в 3НФ, когда находится во 2НФ и каждый неключевой атрибут нетранзитивно зависит от первичного ключа. Проще говоря, второе правило требует выносить все не ключевые поля,
содержимое которых может относиться к нескольким записям таблицы в отдельные таблицы.
Рассмотрим таблицу:
Таблица находится во 2НФ, но не в 3НФ.
В отношении атрибут «Модель» является первичным ключом. Личных телефонов у автомобилей нет, и телефон зависит исключительно от магазина.
Таким образом, в отношении существуют следующие функциональные зависимости: Модель → Магазин, Магазин → Телефон, Модель → Телефон.
Зависимость Модель → Телефон является транзитивной, следовательно, отношение не находится в 3НФ.
В результате разделения исходного отношения получаются два отношения, находящиеся в 3НФ:
9. Нормальная форма Бойса-Кодда, четвертая и пятая нф
Нормальная форма Бойса-Кодда
Переменная отношения находится в нормальной форме Бойса — Кодда (иначе — в усиленной третьей нормальной форме) тогда и только тогда, когда каждая её нетривиальная и неприводимая слева функциональная зависимость имеет в качестве своего детерминанта некоторый потенциальный ключ.
В отношении R (A, B, C) существует многозначная зависимость R.A -> ->
R.B в том и только в том случае, если множество значений B, соответствующее паре значений A и C, зависит только от A и не зависит от С.
Четвертая нормальная форма
Отношение находится в 4НФ, если оно находится в НФБК и все нетривиальные многозначные зависимости фактически являются функциональными зависимостями от ее потенциальных ключей.
Пятая нормальная форма
Отношения находятся в 5НФ, если оно находится в 4НФ и отсутствуют сложные зависимые соединения между атрибутами.
Если «Атрибут_1» зависит от «Атрибута_2», а «Атрибут_2» в свою очередь зависит от «Атрибута_3», а «Атрибут_3» зависит от «Атрибута_1», то все три атрибута обязательно входят в один кортеж.
Это очень жесткое требование, которое можно выполнить лишь при дополнительных условиях. На практике трудно найти пример реализации этого требования в чистом виде.
Проектирование связей между таблицами
Связи делятся на:
Многие ко многим.
Один ко многим.
с обязательной связью;
с необязательной связью;
Один к одному.
с обязательной связью;
с необязательной связью;
Многие ко многим.
Представим, что нам нужно написать БД, которая будет хранить работником IT-компании. При этом существует некий стандартный набор должностей. При этом:
Работник может иметь одну и более должностей. Например, некий работник может быть и админом, и программистом.
Должность может «владеть» одним и более работников. Например, админами является определенный набор работников. Другими словами, к админам относятся некие работники.
Работников представляет таблица «Employee» (id, имя, возраст), должности представляет таблица «Position» (id и название должности). Как видно, обе эти таблицы связаны между собой по правилу многие ко многим: каждому работнику соответствует одна и больше должностей (многие должности), каждой должности соответствует один и больше работников (многие работники).
Для реализации связи многие ко многим нам нужен некий посредник между двумя рассматриваемыми таблицами. Он должен хранить два внешних ключа, первый из которых ссылается на первую таблицу, а второй
— на вторую.
Один ко многим.
Эта самая распространенная связь между базами данных. Мы рассматриваем ее после связи многие ко многим для сравнения.
Предположим, нам нужно реализовать некую БД, которая ведет учет данных о пользователях. У пользователя есть: имя, фамилия, возраст, номера телефонов. При этом у каждого пользователя может быть от одного и больше номеров телефонов (многие номера телефонов).
В этом случае мы наблюдаем следующее: пользователь может иметь многие номера телефонов, но нельзя сказать, что номеру телефона принадлежит определенный пользователь.
Другими словами, телефон принадлежит только одному пользователю. А пользователю могут принадлежать 1 и более телефонов (многие).
Один к одному.
Таблицы будут связаны один к одному тогда, когда одному объекту таблицы А соответствует один объект таблицы Б, и одному объекту таблицы Б соответствует один объект таблицы А. Как я уже говорил: если вы видите, что связь один к одному – смело объединяйте таблицы в одну, за исключением тех случаев, когда происходит модернизация базы данных.
Например, у нас была таблица, в которой хранились данные о сотрудниках компании. Но произошли какие-то изменения в бизнес-процессе и появилась необходимость создать таблицы с теми же самыми сотрудниками, но не для всей компании, а разбив их по отделам. Таблицы отделов будут дочерними по отношению к таблице, в которой хранятся данные обо всех сотрудниках компании, и связаны такие таблицы будут связью один к одному.
Связь один к одному – самая редко встречающаяся связь между таблицами. В 97 случаях из 100, если вы видите такую связь, вам необходимо объединить две таблицы в одну.