Смекни!
smekni.com

Работа с базами данных 2 (стр. 4 из 18)

2) Проверка данных => значения колонок могут пересекаться в триггере, представляемом в качестве параметров, где над ними могут производиться самые разнообразные операции. Например, пользователь может создать триггер, который будет получать из приложения данные для ввода в строку таблицы, создавать уникальный ключ для этой строки внутри своей процедуры и перерабатывать в БД полную строку с ключом.

3) Регистрация изменений данных. Создатель таблицы, или администратор БД может пожелать иметь информацию о времени каждого изменения данных в таблице, а также какой пользователь… Для этого он создает триггер, который поступает в системное время операции UPDATE имя пользователя. Процедура триггера затем вводит эту информацию в специальную таблицу регистрации изменений. Триггер может быть определен для выполнения либо перед операцией (BEFORE), либо после (AFTER) INSERT, UPDATE, DELETE.

Форматкоманды

CREATE TRIGGER ON <имятаблицы>

FOR DELETE | UPDATE | INSERT

AS <логическоевыражение>

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

1.1.2 Иерархическая модель

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

где A, B, C, D, E – типы записей (сегменты)

соединяются при помощи связи с одним узлом более высокого уровня.

Узел – информационная модель элемента, находящегося на данном уровне иерархии.

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

Свойства иерархической модели данных:

· Несколько узлов низшего уровня связано только с одним узлом высшего уровня.

· Иерархическое дерево имеет только одну вершину (корень), не подчиненную никакой другой вершине.

· Каждый узел имеет свое имя (идентификатор).

· Существует только один путь от корневой записи к более частной записи данных.

Особенности иерархической модели данных

· Данные организованны в иерархической структуре;

· При отображении сетевых структур необходимо дублирование данных и меры по поддержанию семантической целостности;

· Основная единица обработки – запись;

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

Иерархическая структура реализуется отношением "один ко многим" между исходной и подчиненной записями, однако для предоставления отношения многих ко многим необходимо дублирование деревьев. При этом сохранение целостности БД ложится на программиста.

Операции над данными:

1) Извлечь по значению ключа;

2) Запомнить;

3) Обновить;

4) Удалить.

1.1.3 Сетевая модель

Сетевая модель БД похожа на иерархическую. Она имеет те же основные составляющие (узел, уровень, связь), однако характер их отношений принципиально иной. В сетевой модели принята свободная связь между элементами разных уровней.

Каждую сетевую структуру можно представить в виде иерархической модели, но при этом сеть нуждается в преобразовании:

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

Особенности сетевой модели

· Позволяет устанавливать несколько признаков одинаково направленных групповых отношений между двумя типами записи;

· Допускает циклические структуры.

Возможные операции над данными

1) Запомнить — занести новую запись в БД и автоматически включить её в групповое отношение (ГО), где она объявлена подчиненной соответствующим режимам включения;

2) Включить — позволяет подчинённую запись связать с записью-владельцем;

3) Переключить — переключить подчинённую запись на другого владельца в том же ГО;

4) Исключить — разрывает связь между владельцем и подчинённой записью, сохранив обе записи в БД.

Каждый тип ГО характеризуется:

1) способом упорядочивания подчиненной записи (ПЗ)

2) a) произвольный;

б) хронологический;

в) обратнохронологический;

г) сортированный;

3) режимом включения ПЗ

а) автоматический – подчинённая запись включается в отношение одновременно с запоминанием в БД, т.е. происходит автоматическое закрепление ПЗ за ее владельцем;

б) ручной – позволяет запомнить ПЗ в БД, а не включать сразу в ГО;

4) режимом исключения ПЗ вводится понятие класса принадлежности

Для сетевой модели:

a) фиксированный — ПЗ жёстко закрепляется за владельцем и не может существовать без него (поэт и произведение). При удалении записи-владельца (ЗВ) система автоматически удаляет ПЗ;

б) обязательный — каждая ПЗ всегда будет связана с некоторой ЗВ, но может быть переназначена на другую ЗВ. Для успешного удаления ЗВ необходимо, чтобы не было ПЗ с обязательным членством;

в) необязательный — позволяет исключить ПЗ из экземпляра ГО, но сохранить её в БД, не прикрепляя к другому владельцу.

Основные особенности обработки данных в сетевых моделях

1) Обработка может быть начата с записи любого типа, независимо от её расположения в структуре БД;

2) От извлечённой записи возможны переходы, как к её подчинённым записям, так и к тем, которым она подчинена;

3) Основная структурная единица – набор, единица обработки – запись.

1.1.4 Объектно-ориентированная модель данных

В настоящий момент времени до конца не разработана.

1.2 Теория нормальных форм

Можно доказать, что любую структуру данных можно преобразовать в простую двухмерную таблицу. Такое представление является наиболее удобным и для пользователя, и для машины, - подавляющее большинство современных информационных систем работает именно с такими таблицами, т.е. с реляционными базами данных.

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

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

1.Однозначная идентификация записи: запись должна однозначно определяться значением ключа.

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

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

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

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

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

При проектировании таблиц рекомендуются следующие "золотые правила":

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

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

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

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

Состав атрибутов отношений БД должен удовлетворять двум основным требованиям:

1) Между атрибутами не должно быть нежелательных функциональных зависимостей (ФЗ);