- •1 Модели данных
- •2 Иерархическая модель
- •3 Сетевая модель
- •4 Реляционная модель
- •5 Структура реляционных данных
- •Отношение Студент
- •6 Отношения : определение, свойства
- •7 Реляционная алгебра. ( основные операции)
- •Унарные операции .
- •Бинарные операции
- •8 Реляционная алгебра. ( дополнительные операции).
- •9 Реляционное исчисление доменов.
- •10 Реляционное исчисление кортежей.
- •11 Построение sql- запросов.
- •12 Sql. Операторы between, in, like, is null
- •13 Комбинированные запросы.
- •14 Вложенные запросы.
- •15 Связанные запросы.
- •16 Использование оператора exists
- •17 Использование предложения union, except, intersect
- •18 Ввод, удаление, изменение значений полей в sql.
- •19 Использование подзапросов с командами обновления
- •20 Использование функций агрегирования в построении запросов
- •21 Форматирование результатов запросов
- •22 Ограничение foreign key.
- •23 Создание, изменение и удаление таблиц средствами -sql.
- •24 Поддержка основных правил целостности данных.
- •25 Sql server. Характеристика объектов бд.
- •Представления
- •Пользовательские типы данных
- •Ограничения целостности
- •28 Основные типы данных
- •Двоичные данные
- •Специальные типы данных.
- •29 Индексы: типы, назначение, создание
- •30 Представления. Изменение значений с помощью представлений
- •31 Обновляемые представления
- •32 Концепция er-модели
- •33 Типы связей и структурные ограничения в er-модели.
- •34 Проблемы er-моделирования
- •35 Основные положения проектирования схем реляционных баз данных
- •36 Избыточность данных и аномалии обновления.
- •37 Функциональные зависимости
- •38 Нормальные формы
- •39 Многозначные зависимости и 4нф ,5нф
- •40 Обзор процесса нормализации
- •41 Основные этапы проектирования баз данных
- •42 Методология концептуального проектирования
- •43 Методология логического проектирования
- •44 Основные задачи логического этапа проектирования базы данных.
- •45 Проверка логической модели с помощью правил нормализации и в отношении транзакций пользователей.
- •46 Определение требований поддержки целостности данных
- •47 Общий обзор методологии физического проектирования реляционных баз данных
- •48 Управление транзакциями.
- •49 Этапы обработки запросов
- •50 Методы защиты базы данных.
35 Основные положения проектирования схем реляционных баз данных
Проектирование базы данных (БД) – одна из наиболее сложных и ответственных задач, связанных с созданием информационной системы (ИС). В результате её решения должны быть определены содержание БД, эффективный для всех её будущих пользователей способ организации данных и инструментальные средства управления данными.
Основная цель процесса проектирования БД состоит в получении такого проекта, который удовлетворяет следующим требованиям:
• |
корректность схемы БД, т. е. база должна быть гомоморфным образом моделируемой предметной области (ПО), где каждому объекту предметной области соответствуют данные в памяти ЭВМ, а каждому процессу – адекватные процедуры обработки данных; |
• |
обеспечение ограничений ; |
• |
эффективность функционирования ; |
• |
защита данных (от аппаратных и программных сбоев и несанкционированного доступа); |
• |
простота и удобство эксплуатации; |
• |
гибкость, т. е. возможность развития и адаптации к изменениям предметной области и/или требований пользователей. |
Процесс проектирования включает в себя следующие этапы.
Концептуальное проектирование – это процедура конструирования информационной модели, не зависящей от каких-либо физических условий реализации.
Логическое проектирование – это процесс конструирования информационной модели на основе существующих моделей данных, не зависимо от используемой СУБД и других условий физической реализации.
Физическое проектирование – это процедура создания описания конкретной реализации БД с описанием структуры хранения данных, методов доступа к данным.
В начало
36 Избыточность данных и аномалии обновления.
Основная цель проектирования заключается в определении атрибутов в отношении, чтобы минимизировать избыточность данных и т.о. сократить объем памяти, которая необходима для физического хранения отношения.
Сотрудник (Nсотр, ФИО, Адрес, Должность, З/П, Nотд)
Отдел (Nотд, Адрес, Nтел)
Сотрудники отдела (Nсотр, ФИО, Адрес, Должность, З/П, Nотд, Адрес_отд, Nтел_отд)
В отношении «Сотрудники отдела» есть избыточность данных.
Поскольку сведения об отделе будет повторяться для каждого сотрудника отдела. В связи с этим в «Сотрудники отдела» существует следующее отношения обновления.
- При добавлении нового сотрудника отдела, необходимо указывать все сведения об этом отделе.
- При добавлении сведений о новом отделе, который еще не имеет сотрудников, придется присвоить значение NULL ключевому полю, что нарушает целостность данных.
При возникновении подобных аномалий рекомендуется отношение разбивать на две части. Для отношений «Сотрудники» и «Отдел» подобных аномалий уже не будет.
В начало
37 Функциональные зависимости
Функциональная зависимость описывает связь между отношениями: R(A,B) A->B.
Атрибут B функциональная зависимость от атрибута A, что означает, что каждое значение атрибута A связано только с одним значением атрибута B. При наличии функциональной зависимости атрибут или группа атрибутов, которые расположены слева от стрелки называются детерминантом.
Сотрудники_отделения:
Nсотр -> ФИО, Адрес, Должность, З/П, Nотд, Адрес_отд, Nтел_отд.
Nотд -> Адрес_отд, Nтел_отд.
Адрес_отд -> Nотд, Nтел_отд.
Nтел_отд -> Nотд, Адрес_отд.
Первичный ключ - Nотд, поскольку все остальные атрибуты функционально зависят отNотд.
В начало