Классификация ограничений целостности по способам реализации

Преимущества и недостатки иерархических моделей

В иерархической модели связи между данными, имеющими какой-либо общий признак, отражены в виде дерева-графа, где возможны только односторонние связи от старших вершин к младшим. Это облегчает доступ к необходимой информации, но только если все возможные запросы отражены в структуре дерева. Никакие иные запросы удовлетворены быть не могут. Использование иерархических моделей ускоряет доступ к информации в базе данных. Но поскольку каждый элемент данных должен содержать ссылки на некоторые другие элементы, требуются значительные ресурсы как дисковой, так и основной памяти ЭВМ. Недостаток основной памяти, конечно, снижает скорость обработки данных, для таких моделей характерна сложность реализации СУБД.

Сетевая модель данных

состоит из множества записей, которые могут быть владельцами или членами групповых отношений. Связь между между записью-владельцем и записью-членом также имеет вид 1:N.

Основное различие этих моделей состоит в том, что в сетевой модели запись может быть членом более чем одного группового отношения. Согласно этой модели каждое групповое отношение именуется и проводится различие между его типом и экземпляром. Тип группового отношения задается его именем и определяет свойства общие для всех экземпляров данного типа. Экземпляр группового отношения представляется записью-владельцем и множеством (возможно пустым) подчиненных записей. При этом имеется следующее ограничение: экземпляр записи не может быть членом двух экземпляров групповых отношений одного типа.

Физическое размещение данных в базах сетевого типа может быть организовано практически теми же методами, что и в иерархических базах данных.

• поиск записи в БД;

• переход от предка к первому потомку;

• переход от потомка к предку;

• создание новой записи;

• удаление текущей записи;

• обновление текущей записи;

• включение записи в связь;

• исключение записи из связи;

• изменение связей и т. д.

Достоинством сетевой модели данных является возможность эффективной реа­лизации по показателям затрат памяти и оперативности. В сравнении с иерархичес­кой моделью сетевая модель предоставляет большие возможности в смысле допусти­мости образования произвольных связей.

Недостатком сетевой модели данных является высокая сложность и жесткость схемы БД, построенной на ее основе, а также сложность для понимания и выполне­ния обработки информации в БД обычным пользователем. Кроме того, в сетевой мо­дели данных ослаблен контроль целостности связей вследствие допустимости уста­новления произвольных связей между записями.

8. Реляционная модель В отличие от иерархической и сетевой моделей данных в реляционной отсутствует понятие группового отношения. Для отражения ассоциаций между кортежами разных отношений используется дублирование их ключей.

реляционная модель состоит из трех частей, описывающих разные аспекты реляционного подхода: структурной части, манипуляционной части и целостной части

столбцы в таблице, представляющей реляционное отношение, называют атрибутами.

Именованное множество пар "имя атрибута - имя домена" называется схемой отношения. Мощность этого множества - называют степенью или "арностью" отношения. Набор именованных схем отношений представляет из себя схему базы данных.

Достоинство реляционной модели данных заключается в простоте, понятности и удобстве физической реализации на ЭВМ. Именно простота и понятность для пользо­вателя явились основной причиной их широкого использования. Проблемы же эффек­тивности обработки данных этого типа оказались технически вполне разрешимыми.

Основными недостатками реляционной модели являются следующие: отсутствие стандартных средств идентификации отдельных записей и сложность описания иерар­хических и сетевых связей.

9. Модель сущность-связь (ER-модель ). Опытно представляется в виде ER-диаграммы.

ER-модель используется при высокоуровневом (концептуальном) проектировании баз данных. С её помощью можно выделить ключевые сущности и обозначить связи, которые могут устанавливаться между этими сущностями.

Сущность – предмет сведений который подлежит сбору информации. Описывается набором атрибутов, каждый атрибут описывает отдел. свойства сущности.

Связь – описывает соединение между данными. Обозначается «птичья лапка» или ромб, в котором название связи.

10. Реляционная модель БД – реализуется с помощью системы упр-ия реляционных БД РСУБД.

РСУБД:

Реляционная модель ориентирована на организацию данных в виде двумерных таблиц. Каждая реляционная таблица представляет собой двумерный массив и обладает следующими свойствами:

· каждый элемент таблицы — один элемент данных

· все ячейки в столбце таблицы однородные, то есть все элементы в столбце имеют одинаковый тип (числовой, символьный и т. д.)

· каждый столбец имеет уникальное имя

· одинаковые строки в таблице отсутствуют

· порядок следования строк и столбцов может быть произвольным

Таблица содержит группу связей сущностей, т.е. набор сущностей

Отношение представляет собой множество элементов, называемых кор­тежами. Наглядной формой представления от­ношения является привычная для человеческого восприятия двумерная таблица.

Таблица имеет строки (записи) и столбцы (колонки). Каждая строка таб­лицы имеет одинаковую структуру и состоит из полей. Строкам таблицы соответствуют кортежи, а столбцам — атрибуты отношения.

Свойства отношений

1. Степень отношений – число его атрибутов

2. Координ. число или мощность отношений- число кортежей (число строк), изм. во времени в отличие от его степени

3. Каждая таблица имеет первичный ключ, уникально индентиф. каждую строку

4. Каждый столбец имеет опред. диапазон значений, наз. доменом атрибута.

Реляционные термины:

Отношение – таблица

Картежи – строки

Атрибуты - столбцы

11. Ключи. Зная величину атрибута А можно найти значение атрибута Б.

Принцип определённости – исп. При формирование центр. Концепции реляционной БД, в функц. зависимости.

Функц. зависимость – атрибут В функ. зависит от атрибута А, если все строки в таблице, совпадающий по значению атрибута А , так же совпадают со значением атрибута В.

Сост. ключи – когда ключ состоит более чем из одного атрибута. (атрибуты все ключевые).

Типы ключей

1. Суперключ – атрибут или комб. атрибутов уник. идентифицирующих каждую сущность таблицы.

2. Потенциальный ключ – миним. суперключ, т.е. СК который не содержит подмножество атрибутов, которое само по себе явл. суперключом.

3. Первич. ключ – PK - потенц. ключ, выбран для уникальной идентификации всех остальных значений в любой строке, не может содержать пустые значения.

4. альтерн. ключ – потен. ключ, который не был выбран в качестве первичного ключа.

5. вторичный ключ – атрибут или комбинация атрибутов, исп. исключительно в целях поиска данных и не требующий уникальности.

6. Внешний ключ (FK) – атрибут или комбинация атрибутов в одной таблице, значение, которого должно совпадать со значением первичного ключа в другой таблице или быть пустым.

Цели исп. ключей:

1) исключения дублирования значений в ключевом атрибуте в пределах таблицы первичного ключа. Должен быть уникальным и тогда таблица проявляет целостность на уровне сущности, так же для целостности на уровне сущности в перв. ключе не допускаются пустые значения

2)упорядочивание картежей

3) ускорение работы с картежами отношениями

4) организация связывания таблиц

12. Неопределённая информация и 3хзначная логика.

-хранить в БД не только достоверную и полностью опред. информацию, но и такую, которая частично не точна или неопределенна.

Неопределённое значение – если при вычисление арифм. выр-ия, хотя бы одно из испол. значений неопределенно, то есть в значение всего арифмит. выр-ия есть NULL (например сравнение, =,>=) то значение операции сравнения unknown.

В 3хзначной логике:

true and unknown =unknown

false and unknown = false

NOT (unknown)=unknown

Основы доводы исп. неопред. зна-ий 2х и 3хзначной логики :

1) наличие пустых значений, в некоторых случаях, решает проблему предоставления не полной инф-ии

2) 3хзначная логика позволяет не заботиться о наличии неопред. знач-ий при формулировке запросов.

Неопределённость и 3хзначная логика позволяет повысить выраз. мощности языка запросов.

13. связывание таблиц – для унификации связей.

Преимщества:

1) контроль целостоности вводимых данных, в соотвест. с установ. связями. Что повышает достоверность в хранимой БД информации

2)тустанов. связей между таблицами облешчает досступ к данным.

Виды связей:

1) бинарные, 2) тернарные, 3) н-арные

Бинарные – с помощью ключа связей, который может состоять из нескольких полей, называемых полями связей.

Суть связей – в установ. соответствия полей-связей между 2я таблицами.

Связь 1 к одному: обеспечивает взаимно-однозначное соответствие записей их таблиц.

Связь 1 ко многим, связь многие -ко-многим- при этом каждая сторона отношений выглядит как отношение 1 ко многим. необходима 3 таблица между ними, которая служит мостом между 2мя таблицами. её ключ состоит из ключей полей этих таблиц. помимо ключ. полей, связываемая таблица может иметь дополнительные поля, в которых нет в связанных таблицах, но которые будут иметь значения для каждой из них.

Контроль целостности связей – анализ содержимого 2х таблиц н соблюдение правил:

1) каждой записи главн. таблицы соответствует 0 или более записей подчинённой таблицы

2) в подчиненной таблице нет записей, которые не имеют родительской записи в главной таблице

3) каждая запись подчинённой таблицы имеет только одну родительскую запись в главной таблице, тогда говорят, что таблица, использующая такую связь, проявляет целостность на уровне ссылке.

Связан. полям необязательно иметь одинаковые имена, но должны иметь один тип данных.

Не идентифицирующая связь – когда 2 самостоятельные сущности, осуществляется путём миграции ключ. атрибутов родительской сущности в область не ключевых атрибутов дочерней сущности. Миграционные атрибуты в дочерней сущности подчин. определению внешнего ключа.

-------------

Идентифицирующая – если сущность А связывается с сущностью В индентифиц. связью, то сущестование экземпляра В не имеет смысла без существование А

Сущность В – наз. зависимой или слабой сущностью.

Идентифицирующая связь всегда носит характер 1ко многим.

14. 4 вопрос

Проектирование БД – это итерационный процесс, который имеет своё начало, но не имеет конца. Важную роль играет концептуальное и логическое проектирование БД.

Нормализация БД – технология, применяемая при проектирование таблиц, заключающая в познание атрибутов сущности, целью нормализации является минимизация избыточности информации и устранение аномальных данных, появляющихся в следствии избыточностей.

Когда нужна нормализация:

1) есть пустые значение, в атрибуте, который бы мог быть ключевым

2) когда есть похожие значения, типа сист. аналитик и системный аналитик, что приводит к :

1. аномалия обновления, 2. аномалия включения (при вводе в пустую строку инфор-ии о каком-либо сотруднике, если он не включен в проект, то придётся создавать фиктивный проект) 3. аномалия удаления(придётся удалять все строки с emp_NUm равным 102, при этом может быть потеряна важная информация)

Этапы: первая, вторая, третья иногда и выше

15. необходимость нормализации - на примере таблице, и трёх аномалий 14 вопрос.

т.о. когда новый сотрудник назначается приходиться вводить некоторые элементы данных приходиться вводить без всякой необходимости, проще вводить индеф. номер сотрудника , который содержит ж всю необходимо информацию. Поэтому, избыточность данных приводит к экономическим затратам пространства и возникновению аномалий.

Приведение к первой нормальной форме

1. удаление повторных групп, чтобы каждая строка определяла единс. зна-ие сущности.

2. определение первичного ключа. – уникально опред. любое значение атрибутов

3. Установление зависимости между атрибутами: частичная – опред. только частичный состав. перв. ключ, то есть зависимость не первичного атрибута от первичного; транзитивная – зависимость одного не первичного атрибута от другого не первичного атрибута

Таблица приведена к 1й н.ф. если:

1. определенны все ключевые атрибуты

2. отсутствие повт. групп ( на пересечение которых столбцы и строки имеют един. значение)

3. все атрибуты зависят от РК

16. Недостатки ненормализованной таблицы – все три аномалии. 15-14 вопросы

Приведение ко 2ой норм. форме. Отношение находится во второй нормальной форме, если оно находится в первой нормальной форме, и при этом любой его атрибут, не входящий в состав потенциального ключа, функционально полно зависит от каждого потенциального ключа. Функционально полная зависимость означает, что атрибут функционально зависит от всего составного потенциального ключа, но при этом не находится в функциональной зависимости от какой-либо из входящих в него частей. Или другими словами: в 2NF нет неключевых атрибутов, зависящих от части составного потенциального ключа.

1. Записать каждый ключ. компомент в отд. строке, затем в послед. строке записать последний сост. ключ.

Prog_Num

Emp_Num

Prog_num, Emp_num

2. кажый компонент станет ключ. в новой таблице, иначе исх. таблица поеделиться на 3 таблицы: Project, Employer, assign

3. после каждого нового ключа записать завис атрибуты Project ( Proj_num, Proj_name)

Employer ( Emp_num, Emp_name, job_class, chg_hour)

assign (proj_num, emp_num, assign_hour)

4. т.к. кол-во часов, затрач. на проект сотрудником, зависет в табл. assign как атрибуты proj_num, emp_num, помещаем в табл. assign под названием assign_hour

Таблица приведена ко 2й нф, если :

1. если приведена к 1нф – у неё нет част. зав-ей, то есть атрибуты зависят от частей первичного ключа.

17. приведение к 3нф

во 2 нф не устранены транзитивные зависимости. , поэтому необходимо фрагменты с транзитивной зависимостью поместить в отд. таблицу. но job_class должен остаться в исх. таблице как внешний ключ

Project ( Proj_num, Proj_name)

Employer ( Emp_num, Emp_name, job_class (FK))

assign (proj_num, emp_num, assign_hour)

Job (job_class, chg_hour)

Таблица приведена к 3 нф, если в ней отсутствуют транз. связи и она приведена ко 2нф

. Возможные улучшения БД, приведенной к третьей нормальной форме.

1) для поддержания целостности на уровне ссылок, можно добавить атрибут Job_code в табл. job и сделать его перв. ключом, соотв. изменить внешн. ключ в табл. Employer на Job_code

Job (Job_code , job_class, chg_hour)

2) сделать атрибуты атомарными, например Emp_name, который не явл. атомарным, т. к.

Норм. формы боле высоко уровня

4 нф – устранить многозначные зависимости, например если сотрудник помимо участия в нескольких проектах , может участ. в одной или нескольких организаций.

18. Денормализация

В нормализованной БД число таблиц растёт, что влечёт увеличение кол-ва операций ввода-вывода, увеличение времени б работки лог. связей. , снижение скорости всей системы, поэтому иногда приходят к компромиссу, как правило состоит в денормализации

Денормализация – понижение уровня формы 3нф- >2нф

Нормальные формы низких уровней имеют место в спец. БД – информац хранилища. Они обычно имеют структуру 2нф в условиях сложной легкоуправляемой инф. среды, питающийся из многочисленных источников данных.

Но, не норм. таблица имеет ещё такие недостатки:

1. невысокая эффективность обновлений инф-ии

2.затруднён процесс индексирования

3. затруднённые стратегии создания представлений

19. Ограничение целостности

согласованность БД – свойство БД. Смысл хранимых данных для БД является набор ограничений целостности, если все ограничения выполнены СУБД считает, что данные корректны

Ограничения целостности- некоторые утверждения, которые м. б. истинными или ложными в зависимости от состояния данных (или БД, не известно)

Примеры: каждый студент имеет уникальный номер, студен обязан числиться только в 1 группе, средний балл не м.б. > 5 или <2.

Целостность данных - это механизм поддержания соответствия базы данных предметной области. В реляционной модели данных определены два базовых требования обеспечения целостности:

· целостность ссылок

· целостность сущностей.

Целостность сущностей.

каждый кортеж любого отношения должен отличатся от любого другого кортежа этого отношения (т.е. любое отношение должно обладать первичным ключом).

с помощью двух ограничений:

· при добавлении записей в таблицу проверяется уникальность их первичных ключей

· не позволяется изменение значений атрибутов, входящих в первичный ключ.

Целостность ссылок

для каждого значения внешнего ключа, появляющегося в дочернем отношении, в родительском отношении должен найтись кортеж с таким же значением первичного ключа.

Как правило, поддержание целостности ссылок также возлагается на систему управления базой данных. Например, она может не позволить пользователю добавить запись, содержащую внешний ключ с несуществующим (неопределенным) значением.

Реакция БД на полученные нарушения целостности:

1.Отказ выполнить незаконную операцию

2. Выполнение некоторых компенсирующих действий (проверка и выдача сообщения пользователю)

20. Классификация ограничения целостностей 19 вопрос

· По способам реализации.

· По времени проверки.

· По области действия.

Классификация ограничений целостности по способам реализации

Декларативная поддержка ограничений целостности заключается в определении ограничений средствами языка определения данных (DDL - Data Definition Language). Обычно средства декларативной поддержки целостности (если они имеются в СУБД) определяют ограничения на значения доменов и атрибутов, целостность сущностей (потенциальные ключи отношений) и ссылочную целостность (целостность внешних ключей). Декларативные ограничения целостности можно использовать при создании и модификации таблиц средствами языка DDL или в виде отдельных утверждений (ASSERTION).

Процедурная поддержка ограничений целостности заключается в использовании триггеров и хранимых процедур. По сути, наличие ограничения целостности (как декларативного, так и процедурного характера) всегда приводит к созданию или использованию некоторого программного кода, реализующего это ограничение. Разница заключается в том, где такой код хранится и как он создается.

Если ограничение целостности реализовано в виде триггеров, то этот программный код является просто телом триггера. Если используется декларативное ограничение целостности, то возможны два подхода:

1. При декларировании (объявлении) ограничения текст ограничения хранится в виде некоторого объекта СУБД, а для реализации ограничения используются встроенные в СУБД функции, и тогда этот код представляет собой внутренние функции ядра СУБД.

2. При декларировании ограничения СУБД автоматически генерирует триггеры, выполняющие необходимые действия по проверке ограничений.