 |
Нормализация баз данных. Преимущества и недостатки нормализованных баз данных. Возможные дефекты в базах данных, нарушающих требования нормализации. Привести примеры
|
|
|
|
Генераторы и триггеры в базах данных. Условия активизации триггеров. Префиксы new и old.
Генераторами называется специальная область данных, которая хранится в базе данных и содержит какое то целое число. Генераторы- это счетчики, но в отличие от локальных БД, увеличение значения этих счетчиков осуществляется с помощью триггеров.
Создаются генераторы с помощью оператора CREATE GENERATOR:
CREATE GENERATOR Gen1;
Триггерами называются подпрограммы, которые всегда выполняются автоматически на стороне сервера, в ответ на изменение данных в таблицах БД.
Синтаксис определения триггера следующий:
CREATE TRIGGER <имя_триггера> FOR <имя_таблицы>[ACTIVE | INACTIVE]{BEFORE | AFTER} {DELETE | INSERT \ UPDATE}[POSITION <число>]AS[DECLARE [VARIABLE] <переменная тип_данных>;]BEGIN <операторы_триггера>END В зависимости от времени наступления события, используется определенное имя ссылки на запись на которой сработал триггер (если можна так выразиться). Зависит от условия активации триггера: для BEFORE указываем OLD, а для AFTER - NEWПрефиксы new и old.
Эти префиксы объявлять не нужно, они уже присутствуют в каждом триггере. Соответственно, переменные хранят старое и новое значения какого либо поля. Обращаться к этим значениям можно так:
NEW.<имя_поля>Эти префиксы могут быть использованы для:
- Получения допустимых значений по умолчанию.
- Проверки входных данных, и при необходимости, их изменения.
- Получения значений полей для модификации других таблиц.
- Реализации автоинкрементных полей.
Хранимые процедуры в СУБД FireBird. Виды хранимых процедур. Привести примеры. Различие переменных памяти и полей таблиц в хранимых процедурах.
Используя язык PSQL (процедурный язык SQL) Firebird, возможно создавать сложные хранимые процедуры для обработки данных полностью на стороне сервера. Для генерации отчётов особенно удобны хранимые процедуры с возможностью выборки, возвращающие данные в виде набора записей.
|
|
|
В FireBird имеется несколько типов хранимых процедур.
- Системные хранимые процедуры предназначены для выполнения различных административных действий. Практически все действия по администрированию сервера выполняются с их помощью. Системные хранимые процедуры имеют префикс sp_, хранятся в системной базе данных и могут быть вызваны в контексте любой другой базы данных.
- Пользовательские хранимые процедуры реализуют те или иные действия. Хранимые процедуры – полноценный объект базы данных. Вследствие этого каждая хранимая процедура располагается в конкретной базе данных, где и выполняется.
- Временные хранимые процедуры существуют лишь некоторое время, после чего автоматически уничтожаются сервером. Они делятся на локальные и глобальные. Локальные временные хранимые процедуры могут быть вызваны только из того соединения, в котором созданы. Глобальные временные хранимые процедуры доступны для любых соединений сервера, на котором имеется такая же процедура
. CREATE PROCEDURE NewOrder @cust_id CHAR(IO)
AS
- - Объявление переменной для номера заказа
DECLARE @order_num INTEGER
-- Получение текущего наибольшего номера заказа
SELECT @order_num=MAX (order_num)
FROM Orders
Determine next order number
SELECT @order_num=@order_num+l
-- Добавление нового заказа
INSERT INTO Orders(order_num, order_date, cust_id)
VALUES(®order_num, GETDATEO, @cust_id)
-- Возвращение номера заказа
RETURN ©order num;
Эта хранимая процедура создает новый заказ в таблице Orders. Она принимает один параметр — идентификатор клиента, сделавшего заказ. Два других столбца таблицы, номер и дата заказа, генерируются автоматически в самой хранимой процедуре. Вначале в коде объявляется локальная переменная для хранения номера заказа. Затем выбирается текущий наибольший номер заказа (посредством функции МАХ ()) и увеличивается на единицу (с помощью оператора SELECT). После этого добавляется заказ посредством оператора INSERT с использованием только что сгенерированного номера заказа, выбирается текущая системная дата (с помощью функции GETDATE ()) и передается идентификатор клиента. Наконец, номер заказа (необходимый для обработки предметов заказа) возвращается как RETURN @order_num. Отметим, что код снабжен комментариями, это всегда следует делать при написании хранимых процедур.
|
|
|
В отличие от полей таблиц, нам не нужно заранее определять тип используемых переменных. Дело в том, что переменные имеют “слабую типизацию”. Это означает, что при определенных условиях одна и та же переменная может использовать данные различных типов.
Нормализация баз данных. Преимущества и недостатки нормализованных баз данных. Возможные дефекты в базах данных, нарушающих требования нормализации. Привести примеры
Нормализация представляет собой процесс, направленный на уменьшение избыточности информации в базе данных. Кроме самих данных, в базе данных также могут быть нормализованы различные наименования, имена объектов и выражения.
Нормализация — это процесс, направленный на уменьшение избыточности информации в реляционной базе данных.
Основные преимущества нормализации:
- Лучшая общая организация базы данных
- Сокращение избыточности информации
- Непротиворечивость информации внутри базы данных
- Более гибкий проект базы данных
- Большая безопасность данных
Недостатком нормализованной БД является необходимость считывать связанные данные из нескольких таблиц при выполнении одного запроса, что негативно сказывается на производительности, т.к. замечено, что ненормализованные или не вполне нормализованные данные отыскиваются быстрее, если они хранятся в одной таблице, по сравнению со случаем поиска данных в связанных таблицах. Подобное ускорение тем заметнее, чем больше число записей в связанных таблицах.
Пример:
Рис. 1 База данных до нормализации
| Компания |
| ID sotr Фамилия Имя Отчество квартира дом улица город индекс телефон дата рождения должность оклад стаж работы кредит дата выплаты ежемесячный взнос |
Рис. 2 1 нормальная форма
|
|
|
| Компания | |
| Сотрудник | Адрес |
| ID_sotr Фамилия Имя Отчество дата рождения должность оклад стаж работы кредит дата выплаты ежемесячный взнос ID_adr | ID_adr квартира дом улица город индекс телефон |
Рис. 3 2 нормальная форма
| Компания | |||
| Сотрудник | Адрес | Телефон | Должность |
| ID_sotr Фамилия Имя Отчество дата рождения стаж работы кредит дата выплаты ежемесячный взнос ID_adr ID_ph ID_dolg | ID_adr квартира дом улица город индекс | ID_ph телефон | ID_dolg должность оклад |
|
|
|
