- •Вопросы к экзамену по курсу ппсубДиЗ Оглавление
- •Основные понятия и определения баз данных и знаний (бдз)
- •Иерархическая модель данных
- •Сетевая модель данных
- •Реляционная модель данных
- •Основы реляционной алгебры
- •Термины и определения реляционных бд
- •Основные термины, используемые при нормализации данных
- •Первая, вторая, третья нормальные формы
- •Нормальная форма Бойса-Кодда, четвертая и пятая нф
- •Проектирование связей между таблицами
- •Типы информационных моделей
- •Структурные, функциональные, структурно-функциональные
- •Концептуальные и логические модели данных
- •Физические модели данных
- •Файловые структуры организации данных
- •Разрешение коллизий с помощью области переполнения
- •Разрешение коллизий методом свободного замещения
- •Индексные файлы и файлы с плотным индексом
- •Файлы с неплотным индексом
- •Иерархическая организация памяти
- •Организация кэш памяти
- •Алгоритм замещения lru и случайный алгоритм
- •Организация основной памяти
- •Виртуальная память
- •Бд и cals технологии
- •Системный подход при разработке многопользовательских ис
- •Стандартизация разработки ис
- •Организация многопользовательских субд
- •Разработка концептуальной модели многопользовательской субд
- •Разработка проекта субд в соответствии с тз
- •Основные компоненты су реляционными бд
- •Основные сведения ms sql, Access
- •Язык запросов sql
- •Динамическое самоуправление sql Server
- •Обработчик запросов sql Server
- •Технология разработки таблиц бд
- •Разработка физической модели данных
- •Создание ключевых полей и связей между таблицами в Access
- •Технология разработки запросов
- •Разработка запроса в режиме конструктора Access
- •Правила составления условий отбора данных
- •Конструирование перекрестных запросов
- •Автоматизация расчетов с помощью запросов
- •Разработка форм средствами Access
- •Основные элементы форм ввода данных
- •Технология разработки форм для ввода данных в запросы
- •Технология разработки форм организации пользовательского интерфейса
- •Создание отчета с помощью мастера Access
- •Управление объектами бд с помощью макросов
- •Разработка меню пользователя
- •Основные понятия распределенной обработки данных
- •Модель клиент-сервер в технологии распределенных бд
- •Двухуровневые модели
- •Модель сервера бд
- •Модель сервера приложений
- •55. Модели серверов бд
- •56. Типы параллелизма
- •57. Что включает в себя обработка знаний
- •58. Что включает в себя проблемная область
- •59. Как классифицируются знания
- •60. Понятие модели предоставления знаний.
- •61. Продукционная модель представления знаний.
- •62. Модель исчисления предикатов первого порядка.
- •63. Фреймовая модель представления знаний.
Нормальная форма Бойса-Кодда, четвертая и пятая нф
1. Нормальная форма Бойса-Кодда
Переменная отношения находится в нормальной форме Бойса — Кодда (иначе — в усиленной третьей нормальной форме) тогда и только тогда, когда каждая её нетривиальная и неприводимая слева функциональная зависимость имеет в качестве своего детерминанта некоторый потенциальный ключ.
В отношении R (A, B, C) существует многозначная зависимость R.A -> -> R.B в том и только в том случае, если множество значений B, соответствующее паре значений A и C, зависит только от A и не зависит от С.
2. Четвертая нормальная форма
Отношение находится в 4НФ, если оно находится в НФБК и все нетривиальные многозначные зависимости фактически являются функциональными зависимостями от ее потенциальных ключей.
3. Пятая нормальная форма
Отношения находятся в 5НФ, если оно находится в 4НФ и отсутствуют сложные зависимые соединения между атрибутами.
Если «Атрибут_1» зависит от «Атрибута_2», а «Атрибут_2» в свою очередь зависит от «Атрибута_3», а «Атрибут_3» зависит от «Атрибута_1», то все три атрибута обязательно входят в один кортеж.
Это очень жесткое требование, которое можно выполнить лишь при дополнительных условиях. На практике трудно найти пример реализации этого требования в чистом виде.
Проектирование связей между таблицами
Связи делятся на:
Многие ко многим.
Один ко многим.
с обязательной связью;
с необязательной связью;
3. Один к одному.
с обязательной связью;
с необязательной связью;
Многие ко многим.
Представим, что нам нужно написать БД, которая будет хранить работником IT-компании. При этом существует некий стандартный набор должностей. При этом:
Работник может иметь одну и более должностей. Например, некий работник может быть и админом, и программистом.
Должность может «владеть» одним и более работников. Например, админами является определенный набор работников. Другими словами, к админам относятся некие работники.
Работников представляет таблица «Employee» (id, имя, возраст), должности представляет таблица «Position» (id и название должности). Как видно, обе эти таблицы связаны между собой по правилу многие ко многим: каждому работнику соответствует одна и больше должностей (многие должности), каждой должности соответствует один и больше работников (многие работники).
Для реализации связи многие ко многим нам нужен некий посредник между двумя рассматриваемыми таблицами. Он должен хранить два внешних ключа, первый из которых ссылается на первую таблицу, а второй — на вторую.
Один ко многим.
Эта самая распространенная связь между базами данных. Мы рассматриваем ее после связи многие ко многим для сравнения.
Предположим, нам нужно реализовать некую БД, которая ведет учет данных о пользователях. У пользователя есть: имя, фамилия, возраст, номера телефонов. При этом у каждого пользователя может быть от одного и больше номеров телефонов (многие номера телефонов).
В этом случае мы наблюдаем следующее: пользователь может иметь многие номера телефонов, но нельзя сказать, что номеру телефона принадлежит определенный пользователь.
Другими словами, телефон принадлежит только одному пользователю. А пользователю могут принадлежать 1 и более телефонов (многие).
Один к одному.
Таблицы будут связаны один к одному тогда, когда одному объекту таблицы А соответствует один объект таблицы Б, и одному объекту таблицы Б соответствует один объект таблицы А. Как я уже говорил: если вы видите, что связь один к одному – смело объединяйте таблицы в одну, за исключением тех случаев, когда происходит модернизация базы данных.
Например, у нас была таблица, в которой хранились данные о сотрудниках компании. Но произошли какие-то изменения в бизнес-процессе и появилась необходимость создать таблицы с теми же самыми сотрудниками, но не для всей компании, а разбив их по отделам. Таблицы отделов будут дочерними по отношению к таблице, в которой хранятся данные обо всех сотрудниках компании, и связаны такие таблицы будут связью один к одному.
Связь один к одному – самая редко встречающаяся связь между таблицами. В 97 случаях из 100, если вы видите такую связь, вам необходимо объединить две таблицы в одну.