БАЗЫ ДАННЫХ подготовка к междисциплинарному государственному экзамену

(филиал) РЭУ им. Г.В. Плеханова Экономический факультет
Кафедра вычислительной техники и

информационных технологий

базы данных. Определение, свойства, требование целостности. Атрибут, домен, кортеж, отношение,

ключи.
Понятие нормализации. Функциональные зависимости. Первая, вторая, третья нормальные формы. Привести примеры процесса нормализации на конкретной таблице. Аномалии обновления, удаления, добавления
Язык SQL. Оператор SELECT. Операторы INSERT, UPDATE, DELETE.
Язык SQL. Операторы определения базы данных, таблицы, представления.
Понятие хранимой процедуры. Типы хранимых процедур. Триггеры. Определение триггера. Создание и реализация триггеров.
Транзакции. Свойства транзакций. Управление транзакциями.
Семантическое моделирование данных с использованием ER-модели.
Технологии OLTP и OLAP. Требования к системам. Примеры систем.
Архитектура БД в технологиях «клиент-сервер». Распределенные базы данных. Модели распределенных баз данных. Особенности функционирования распределенных баз данных
 

сведений, зафиксированных на определенном носителе в форме, пригодной для постоянного

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

конфиденциальности, целостности:
данные должны быть защищены от искажения, хищения, разрушения;
данные должны

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

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

общего назначения (СУБД ОН) и специализированные СУБД (СпСУБД).
СУБД ОН не ориентированы на

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

СУБД.
По характеру использования СУБД делят на персональные и многопользовательские.
Персональные СУБД

обычно обеспечивают возможность создания персональных БД и недорогих приложений, работающих с ними. Персональные СУБД или разработанные с их помощью приложения зачастую могут выступать в роли клиентской части многопользовательской СУБД. К персональным СУБД, например, относятся Visual FoxPro, Paradox, Clipper, dBase, Access и др.
Многопользовательские СУБД включают в себя сервер БД и клиентскую
часть и, как правило, могут работать в неоднородной вычислительной среде
(с разными типами ЭВМ и операционными системами). К многопользовтельским СУБД относятся, например, СУБД Oracle и Informix.
По методам организации хранения и обработки данных СУБД делят на централизованные и распределённые. Первые работают с БД, которая физически хранится в одном месте (на одном компьютере). Это не означает, что пользователь может работать с БД только за этим же компьютером: доступ может быть удалённым (в режиме клиент–сервер). Большинство централизованных СУБД перекладывает задачу организации удаленного доступа к данным на сетевое обеспечение, выполняя только свои стандартные функции, которые, естественно, усложняются за счёт одновременности доступа многих пользователей к данным.
.
 

СУБД трех групп:
Мощные крупные коммерческие СУБД, ориентированные на хранение огромных

объемов информации (от гигабайт). Наиболее известными СУБД в этой группе являются: Oracle (Oracle Corp.), Ingres (Computer Associates International), Sybase SQL server (Sybase Inc.).
Мобильные компактные свободно распространяемые СУБД, использование которых оправдано и для БД объемом всего лишь в десятки килобайт. К наиболее популярным СУБД этой группы относятся: PostgreSQL (организации PostgreSQL), mySQL (T.C.X. DataKonsult AB), Microsoft SQL Server (Microsoft).
Настольные персональные СУБД, ориентированные на простые варианты построения БД, решение менее сложных задач, на персональные компьютеры и, на меньшие объемы и сравнительно простую структуру данных. К настольным СУБД относятся: Access, входящая в состав пакета Microsoft Office и рассчитанная на одного пользователя; Visual FoxPro.
СУБД первых двух групп построены по принципу «клиент-сервер».
 

данными в оперативной памяти.
3.Управление транзакциями.
4.Журнализация, применяемая при восстановлении программы после

сбоя.
5.Поддержка языков БД (Язык определения и манипулирования данных)
 
1.Управление данными во внешней памяти.
Включает обеспечение необходимой структуры данных во внешней памяти, как для хранения непосредственно данных, так и для служебных целей, например организация индексов для ускорения доступа к данным. В одних СУБД активно используется возможности существующих файловых систем, в других работа производится вплоть до уровня устройств внешней памяти. В развитых СУБД пользователи не обязаны знать как организованы файлы. В частности СУБД поддерживает собственную системы именования объектов.
2.Управление данными в оперативной памяти.
СУБД обычно работает с БД большого размера, которая больше чем оперативная память => при обращении к любому элементу данных будет производиться общение с внешней памятью и будет работать со скоростью внешних устройств. Единственный способ повысить скорость работы – буферизация оперативной памяти, поэтому в развитых СУБД поддерживается собственный набор буферов оперативной памяти с собственной заменой.

СУБД как единое целое. Либо транзакция успешно выполняется, и СУБД

фиксирует изменения БД, произведенные этой транзакцией, во внешней памяти, либо ни одно из этих изменений никак не отражается на состоянии БД. Понятие транзакции необходимо для поддержания логической целостности БД.
Поддержание механизма транзакций есть обязательное условие даже в однопользовательской СУБД. Но понятие транзакции гораздо существеннее для многопользовательских СУБД.
При соответствующем управлении каждой СУБД, каждый пользователь может ощущать себя единственным. Существует 2 типа систем обработки транзакциями: OLTP, OLAP
4.Журнализация. Это надежность СУБД в хранении данных, т.е. способность восстанавливать последнее согласованное состояние БД после любого программного или аппаратного сбоя. Для этого ведется журнал (особая часть БД, в которую поступают данные об изменениях в основной части БД). Иногда поддерживаются 2 копии журнала и хранятся на разных винчестерах. Изменения в журнале производятся, до изменения в БД (WAL-протокол). После сбоя используется журнал и архивная копия БД (полная копия БД к началу заполнения БД). По журналу производятся все транзакции до момента сбоя.
5.Поддержка языков БД. Таким языком является непроцедурный язык SQL.
 

кортеж, отношение, ключи.
Реляционная база данных — база данных, основанная на реляционной модели

данных. Слово «реляционный» происходит от англ. relation (отношение). Для работы с реляционными БД применяют реляционные СУБД.
Использование реляционных баз данных было предложено доктором Коддом из компании IBM в 1970 году. Эти модели характеризуются простотой структуры данных и возможностью использования формального аппарата алгебры отношений и реляционного исчисления для обработки данных.
Реляционная модель ориентирована на организацию данных в виде двумерных таблиц и обладает следующими свойствами:
каждый элемент таблицы — один элемент данных
все ячейки в столбце таблицы однородные, то есть все элементы в столбце имеют одинаковый тип (числовой, символьный и т. д.)
каждый столбец имеет уникальное имя
одинаковые строки в таблице отсутствуют
порядок следования строк и столбцов может быть произвольным
Базовыми понятиями реляционных СУБД являются: атрибут, отношение, кортеж, ключ

правило (Foundation Rule): Реляционная СУБД должна быть способна полностью управлять базой данных, используя связи

между данными:
правило 1: Явное представление данных (The Information Rule):
Информация должна быть представлена в виде данных, хранящихся в ячейках. Данные, хранящиеся в ячейках, должны быть атомарны.
правило 2: Гарантированный доступ к данным (Guaranteed Access Rule):
правило 3: Полная обработка неизвестных значений (Systematic Treatment of Null Values):
правило 4: Доступ к словарю данных в терминах реляционной модели (Active On-Line Catalog Based on the Relational Model):
Словарь данных должен сохраняться в форме реляционных таблиц
правило 6: Возможность модификации представлений (View Updating Rule):
правило 7: Наличие высокоуровневых операций управления данными (High-Level Insert, Update, and Delete):
правило 8: Физическая независимость данных (Physical Data Independence):
правило 9: Логическая независимость данных (Logical Data Independence):
правило 10: Независимость контроля целостности (Integrity Independence):
правило 11: Дистрибутивная независимость (Distribution Independence):
База данных может быть распределённой, может находиться на нескольких компьютерах, и это не должно оказывать влияние на приложения. Перенос базы данных на другой компьютер не должен оказывать влияния на приложения.
правило 12: Согласование языковых уровней (The Nonsubversion Rule):

может адресоваться непосредственно, и с помощью которой выполняется построение всех

остальных структур. Атрибут имеет имя и значение.
Понятие тип данных в реляционной модели данных полностью адекватно понятию типа данных в языках программирования. Обычно в современных реляционных БД допускается хранение данных следующих типов: символьных, числовых, битовых, специализированных числовых данных (таких как «деньги», «темпоральных» данных (дата, время, временной интервал). Достаточно активно развивается подход к расширению возможностей реляционных систем абстрактными типами данных (соответствующими возможностями обладают, например, системы семейства Ingres/Postgres). В нашем примере мы имеем дело с данными трех типов: строки символов, целые числа и «деньги».
Домен – допустимое потенциальное множество значений простого типа данных. В самом общем виде домен определяется заданием некоторого базового типа данных, к которому относятся элементы домена, и произвольного логического выражения, применяемого к элементу типа данных. Если вычисление этого логического выражения дает результат «истина», то элемент данных является элементом домена.

атрибута - значение}, которое содержит одно вхождение каждого имени атрибута,

принадлежащего схеме отношения. "Значение" является допустимым значением домена данного атрибута (или типа данных, если понятие домена не поддерживается). Степень или «арность» кортежа, т.е. число элементов в кортеже, совпадает с «арностью» соответствующей схемы отношения.
Кортеж - это набор именованных значений заданного типа. Схема отношения - это именованное множество пар {имя атрибута – имя домена (или типа, если понятие домена не поддерживается)}. Степень или "арность" схемы отношения - мощность этого множества. Степень отношения СОТРУДНИКИ равна четырем, то есть оно является 4-арным.
Схема БД (в структурном смысле) - это набор именованных схем отношений
Отношение - это множество кортежей, соответствующих одной схеме отношения. Иногда, чтобы не путаться, говорят «отношение-схема» и «отношение-экземпляр», иногда схему отношения называют заголовком отношения, а отношение как набор кортежей - телом отношения. На самом деле, понятие схемы отношения ближе всего к понятию структурного типа данных в языках программирования. Было бы вполне логично разрешать отдельно определять схему отношения, а затем одно или несколько отношений с данной схемой. Однако в реляционных базах данных это не принято.

с именами схем отношений в схеме БД.
Ключ – набор

атрибутов, значение которых однозначно идентифицирует кортежи. Отношение может иметь несколько ключей, но всегда один из ключей объявляется первичным и его значения не могут обновляться.
Все остальные ключи называются возможными ключами.
Атрибуты, представляющие собой копии ключей других отношений называются внешними ключами. Согласно Дейту реляционная модель состоит из трех частей, описывающих разные аспекты реляционного подхода: структурной части, манипуляционной части и целостной части.
В структурной части реляционной модели данных фиксируется, что единственной структурой данных, используемой в реляционных БД, является нормализованное n-арное отношение. По сути дела, ранее мы рассматривали именно понятия и свойства структурной составляющей реляционной модели.
В манипуляционной части реляционной модели данных утверждаются два фундаментальных механизма манипулирования реляционными БД - реляционная алгебра и реляционное исчисление. Первый механизм базируется в основном на классической теории множеств (с некоторыми уточнениями), а второй - на классическом логическом аппарате исчисления предикатов первого порядка.
В целостной части реляционной модели данных фиксируются два базовых требования целостности, которые должны поддерживаться в любой реляционной СУБД.

мира в реляционных БД соответствуют кортежи отношений. Конкретно требование состоит

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

кортежей с одним и тем же значением первичного ключа.
С

целостностью по ссылкам дела обстоят несколько более сложно.
Существуют три подхода, каждый из которых поддерживает целостность по ссылкам:
1. запрещается производить удаление кортежа, на который существуют ссылки (т.е. сначала нужно либо удалить ссылающиеся кортежи, либо соответствующим образом изменить значения их внешнего ключа);
2. при удалении кортежа, на который имеются ссылки, во всех ссылающихся кортежах значение внешнего ключа автоматически становится неопределенным;
3. каскадное удаление, состоящее в том, что при удалении кортежа из отношения, на которое ведет ссылка, из ссылающегося отношения автоматически удаляются все ссылающиеся кортежи.
В развитых реляционных СУБД обычно можно выбрать способ поддержания целостности по ссылкам для каждой отдельной ситуации определения внешнего ключа. Конечно, для принятия такого решения необходимо анализировать требования конкретной прикладной области.

примеры процесса нормализации на конкретной таблице. Аномалии обновления, удаления, добавления
В

теории реляционных баз данных обычно выделяется следующая последовательность нормальных форм:
первая нормальная форма (1NF);
вторая нормальная форма (2NF);
третья нормальная форма (3NF);
нормальная форма Бойса-Кодда (BCNF);
четвертая нормальная форма (4NF);
пятая нормальная форма (5NF или PJ/NF).
Основные свойства нормальных форм:
каждая следующая нормальная форма в некотором смысле лучше предыдущей;
при переходе к следующей нормальной форме свойства предыдущих нормальных свойств сохраняются.
В основе процесса проектирования лежит метод нормализации, декомпозиция отношения, находящегося в предыдущей нормальной форме, в два или более отношения, удовлетворяющих требованиям следующей нормальной формы.
Если отношения не нормализованы, то возникает проблемы избыточности, потенциальной противоречивости (аномалии обновления), аномалии включения, аномалии удаления.
На практике многие пользователи делают выбор хранения данных в пользу 3NF - третьей нормальной формы).

в предыдущей нормальной форме, в два или более отношения, удовлетворяющих

требованиям следующей нормальной формы.
Наиболее важные на практике нормальные формы отношений основываются на фундаментальном в теории реляционных баз данных понятии функциональной зависимости. Для дальнейшего изложения нам потребуются несколько определений.
Определение 1. Функциональная зависимость
В отношении R атрибут Y функционально зависит от атрибута X
(X и Y могут быть составными) в том и только в том случае,
если каждому значению X соответствует в точности одно значение Y:
R.X ->R.Y.
Определение 2. Полная функциональная зависимость
Функциональная зависимость R.X ->R.Y называется полной,
если атрибут Y не зависит функционально от любого точного подмножества X.
Определение 3. Транзитивная функциональная зависимость
Функциональная зависимость R.X -> R.Y называется транзитивной,
если существует такой атрибут Z, что имеются функциональные зависимости R.X -> R.Z и R.Z -> R.Y
и отсутствует функциональная зависимость R.Z -/-> R.X.

не входящий в состав первичного ключа (в частности, первичного).
Определение

5. Взаимно независимые атрибуты
Два или более атрибута взаимно независимы, если ни один из этих атрибутов не является функционально зависимым от других.
Определение 6 Первая нормальная форма - все атрибуты сущности содержат атомарные значения и среди атрибутов нет повторяющихся групп.
Поскольку требование первой нормальной формы является базовым требованием классической реляционной модели данных, мы будем считать, что исходный набор отношений уже соответствует этому требованию, т.е. все атрибуты атомарны.
.Если таблица содержит составные атрибуты, то привести ее к 1NF можно, используя алгоритм нормализации, предложенный Э. Коддом:
начиная с исходной таблицы, берется ее первичный ключ и добавляется в каждую подчиненную таблицу (составной атрибут);
первичный ключ каждой расширенной таблицы состоит из первичного ключа подчиненной таблицы и добавленного родительского первичного ключа;
после этого из родительской таблицы вычеркиваются все непростые атрибуты, и эта процедура повторяется для каждой из подчиненных таблиц;
условие окончания алгоритма - атомарность всех атрибутов.

обновления может возникнуть в том случае, когда информация дублируется. Другие

аномалии возникают тогда, когда две и более независимые сущности объединены в одно отношение.
Определение 7. Вторая нормальная форма (в этом определении предполагается, что единственным ключом отношения является первичный ключ): Отношение R находится во второй нормальной форме (2NF) в том и только в том случае, когда находится в 1NF, и каждый не ключевой атрибут полностью зависит от первичного ключа.
Пример 1. Рассмотрим в качестве предметной области – учебный процесс.
Представим схему отношения (вся информация в одной таблице):
СТУДЕНТЫ-ДИСЦИПЛИНЫ-ОЦЕНКИ
(ФИО, №_зач, группа, дисц, оценка)
Первичный ключ: №_зач, дисц
Функциональные зависимости: №_зач -> ФИО, №_зач -> группа
не зависят от атрибута дисц , т.е. зависят только от части первичного ключа и, следовательно, не находятся во второй нормальной форме.

(№_зач, дисц, оценка)
Оба отношения находятся во второй нормальной форме.
Укажите ,

какие аномалии могут возникнуть, если не приводить отношение ко второй нормальной форме.
Определение 8. Третья нормальная форма (определение дается в предположении существования единственного ключа.) Отношение R находится в третьей нормальной форме (3NF) в том и только в том случае, если находится в 2NF и каждый не ключевой атрибут не транзитивно зависит от первичного ключа.
Пример 3 Рассмотрим отношение
СТУДЕНТ-ФАКУЛЬТЕТ-КАФЕДРА
(ФИО, №_зач, группа, фак_т, спец, вып_каф)
В этом отношении есть зависимости:
группа -> фак_т
группа -> спец
группа -> вып_каф
вып_каф -> фак_т

вып_каф)
КАФЕДРА-ФАКУЛЬТЕТ (вып_каф, фак_т)

На практике третья нормальная форма схем отношений достаточна

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

предназначен для доступа к информации и управления реляционной БД. Он

является общим при работе c различными базами данных, такими как Oracle, Microsoft SQL Server, Informix, DB2, Access, MySQL.
Все СУБД, претендующие на название «реляционные», реализуют тот или иной диалект SQL: SQL*Plus корпорации Oracle; Transact-SQL для СУБД Microsoft SQL Server и др. В диалектах язык может быть дополнен операторами процедурных языков программирования.
В настоящее время, ни одна система не реализует стандарт SQL в полном объеме. Кроме того, во всех диалектах языка имеются возможности, не являющиеся стандартными. Таким образом, можно сказать, что каждый диалект – это надмножество некоторого подмножества стандарта SQL.
Язык SQL определяет:
операторы языка, называемые командами языка SQL;
типы данных;
набор встроенных функций.
DDL (Data Definition Language) – это язык определения данных, который включает операторы, управляющие объектами базы данных. К последним относятся таблицы, индексы, представления. Для каждой конкретной базы данных существует свой набор объектов базы данных, который может значительно расширять набор объектов, предусмотренный стандартом.
CREATE DATABASE – создать базы данных;

таблицу;
ALTER TABLE – изменить таблицу;
DROP TABLE – удалить таблицу;

CREATE VIEW – создать представление;
DROP VIEW – удалить представление.
DML (Data Manipulation Language) – язык манипулирования данными:
SELECT – отобрать строки из таблиц;
INSERT – добавить строки в таблицу;
UPDATE – изменить строки в таблице;
DELETE – удалить строки в таблице;
DCD (Data Control Language) – язык управления данными состоит из операторов контроля данных, защиты и управления данными:
COMMIT – зафиксировать внесенные изменения;
ROLLBACK – откатить внесенные изменения.
GRANT – предоставить привилегии пользователю или приложению на манипулирование объектами;
REVOKE – отменить привилегии пользователя или приложения

{ [ DISTINCT | ALL] ,….} FROM

{ < имя_таблицы>
[ < псевдоним > ] }.,.. [ WHERE <предикат>] [ GROUP BY <имя_столбца>.,..]
[ HAVING <предикат>] [ ORDER BY <имя_столбца>.,. | <номер_столбца>.,..]
[ { UNION [ALL] SELECT * | { [DISTINCT | ALL] < < выражение >.,..} FROM .] } ] ...;
 Элементы, используемые в команде SELECT:
< список выбора > - выражения, включающее имена столбцов, функции, знаки операций
<предикат>::=< выражение1 > < оператор> < выражение2> |
[NOT] EXISTS < выражение2 >
< оператор> ::= > | < | >= | <= | <> | = | IN | LIKE | BETWEEN …AND | OR | AND | NOT
< выражение2 >::= < выражение1> | [ANY | SOME | ALL ] <подзапрос>
<подзапрос>::= (SELECT * | { [ DISTINCT | ALL] < выражение >,….} FROM { < имя_таблицы> [ < псевдоним > ] }.,.. [ WHERE <предикат>] …)  
Пример Вывести имена и номера всех продавцов, у которых более одного заказчика: SELECT snum, sname FROM t1 main WHERE 1 <
(SELECT COUNT (*) FROM t2 WHERE snum = main.snum );

FROM [WHERE ];
и

позволяет удалить содержимое всех строк указанной таблицы (при отсутствии WHERE фразы) или тех ее строк, которые выделяются WHERE фразой.
Пример 1 Удалить все содержимое таблицы Продавцы:
DELETE FROM t1;
Теперь, когда таблица пуста, ее можно окончательно удалить командой DROP TABLE. Обычно, нужно удалить только некоторые определенные строки из таблицы. Чтобы определить, какие строки будут удалены, используется предикат, так же как и для запросов SELECT.
Пример 2 Удалить продавца Аксельрода из таблицы Продавцы:
DELETE FROM t1 WHERE snum = 1003;
Оператор вставки данных INSERT
Оператор INSERT имеет один из следующих форматов:
INSERT INTO <базовая таблица | представление> [(<столбец> [,<столбец>] ...)] VALUES (<константа>|<переменная> [,<константа>| <переменная>] ...);
или
INSERT INTO <базовая таблица | представление> [(<столбец> [,<столбец>] ...)] <подзапрос>;

полей, указанными в перечне фразы VALUES (значения), причем i-е значение

соответствует i-му столбцу в списке столбцов (столбцы, не указанные в списке, заполняются NULL-значениями). Если в списке VALUES фразы указаны все столбцы модифицируемой таблицы и порядок их перечисления соответствует порядку столбцов в описании таблицы, то список столбцов в предложении INTO можно опустить.
Пример 3 Добавить нового продавца:
INSERT INTO t1 VALUES (1009, 'Вильсон', 'Лондон', 0.12);
Пример 4 INSERT INTO Лондон_1 SELECT * FROM t1 WHERE city = 'Лондон';
Здесь выбираются все значения, произведенные запросом - все строки из таблицы Продавцы со значениями city = ‘Лондон’ - и помещаются в таблицу, называемую Лондон_1. Эта таблица должна отвечать следующим условиям:

она должна уже быть создана командой CREATE TABLE.;
она должна иметь четыре столбца, которые совпадают с таблицей Продавцы по типу данных.

| представление> SET = [,= ] ...[WHERE ];

где <значение>::=<столбец> |< выражение> | <константа> | <переменная>
и может включать столбцы лишь из обновляемой таблицы, т.е. значение одного из столбцов модифицируемой таблицы может заменяться на значение ее другого столбца или выражения, содержащего значения нескольких ее столбцов, включая изменяемый.
При отсутствии WHERE фразы обновляются значения указанных столбцов во всех строках модифицируемой таблицы. WHERE фраза позволяет сократить число обновляемых строк, указывая условия их отбора.
Пример 5 Предположим, что продавец Мотика с номером 1004 ушел на пенсию, и необходимо переназначить его номер новому продавцу:
UPDATE t1 SET sname = 'Гибсон', city = 'Бостон', comm = .10 WHERE snum = 1004;

в SQL с помощью предложения CREATE TABLE (создать таблицу). Рассмотрим

синтаксис этого предложения:
CREATE TABLE <имя_таблицы>
(<элемент_таблицы> [,<элемент_таблицы >*,] [ограничения_целостности_таблицы]);
< элемент_таблицы > ::= <определение_столбца>
< определение_столбца > ::= <имя_столбца> <тип_данных> [DEFAULT <значение>] [<ограничения_ целостности_столбца>...]
< ограничения_ целостности_столбца > ::= NULL | NOT NULL | UNIQUE <спецификация>] | REFERENCES <спецификация> | CHECK (<проверочное_ограничение>)| PRIMARY KEY| FOREIGN KEY
Кроме имени таблицы, в операторе специфицируется список элементов таблицы, каждый из которых служит либо для определения столбца, либо для определения ограничения целостности определяемой таблицы. Требуется наличие хотя бы одного определения столбца. Для столбца задается имя и его тип данных, а также два необязательных раздела: раздел значения столбца по умолчанию и раздел ограничений целостности столбца.

свойство, назначенное столбцу или таблице, которое запрещает ввод в указанный

столбец (или столбцы) недопустимых значений.
Основные виды ограничений: NULL, NOT NULL, DEFAULT, PRIMARY KEY, FOREIGN KEY, REFERENCES, CHECK, UNIQUE. Ограничения могут быть без имени или с именем, тогда перед ограничением вставляется слово CONSTRAINT <имя_ограничения>. Наличие имени ограничения позволяет ссылаться на него в операторе изменения таблицы, например:
ALTER TABLE Tab1 ADD CONSTRAINT col1 CHECK (col1 BETWEEN 0 AND 1);
В разделе значения по умолчанию DEFAULT указывается значение, которое должно быть помещено в строку, заносимую в данную таблицу, если значение данного столбца явно не указано. Значение по умолчанию может быть указано в виде литеральной константы с типом, соответствующим типу столбца, или путем задания ключевого слова NULL, означающего, что значением по умолчанию является неопределенное значение. Если значение столбца по умолчанию не специфицировано, и в разделе ограничений целостности столбца указано NOT NULL, то попытка занести в таблицу строку с NULL-значением данного столбца приведет к ошибке.
.

ограничений целостности NOT NULL приводит к неявному порождению проверочного ограничения

целостности для всей таблицы «CHECK (C IS NOT NULL)» (где C - имя данного столбца). Если ограничение NOT NULL не указано, и раздел умолчаний отсутствует, то неявно порождается раздел умолчаний DEFAULT NULL. Если указана спецификация уникальности, то порождается соответствующая спецификация уникальности для таблицы.
Если в разделе ограничений целостности указано ограничение по ссылкам данного столбца (REFERENCES <спецификация>), то порождается соответствующее определение ограничения по ссылкам для таблицы:
FOREIGN KEY(C) REFERENCES <спецификация>
Пример 1 Создать таблицу:
CREATE TABLE Заказчики
( cnum integer NOT NULL PRIMARY KEY,
cname char (10) NOT NULL,
city char (10) DEFAULT 'Лондон',
rating integer,
snum integer NOT NULL,
UNIQUE (cnum, snum));
UNIQUE (cnum, snum) – это ограничение целостности таблицы, утверждающее, что комбинация номеров должна быть уникальной, т.е. у каждого заказчика только один продавец.

В следующем примере для задания составного первичного ключа используется ограничение

целостности таблицы PRIMARY KEY для пар:
CREATE TABLE Имена
( firstname char (10) NOT NULL,
lastname char (10) NOT NULL,
city char (10),
PRIMARY KEY ( firstname, lastname ));
Существующую базовую таблицу можно в любой момент уничтожить с помощью предложения:
DROP TABLE <имя_таблицы>; по которому удаляется описание таблицы, ее данные, связанные с ней представления и индексы, построенные для столбцов таблицы.
Оператор определения представлений CREATE VIEW
Представление - это виртуальная таблица, которая сама по себе не существует, но для пользователя выглядит таким образом, как будто она существует. Представление не поддерживаются его собственными физическими хранимыми данными. Вместо этого в каталоге таблиц хранится определение, оговаривающее, из каких столбцов и строк других таблиц оно должно быть сформировано.

является мощным средством языка SQL, позволяющим скрыть реальную структуру БД

от некоторых пользователей за счет определения представления БД, которое реально является некоторым хранимым в БД запросом с именованными столбцами, а для пользователя ничем не отличается от базовой таблицы БД (с учетом технических ограничений).
Любая реализация должна гарантировать, что состояние представляемой таблицы точно соответствует состоянию базовых таблиц, на которых определено представление. Синтаксис предложения CREATE VIEW имеет вид:
CREATE VIEW <имя_представления> [(<столбец>[,<столбец>] ...)] AS <подзапрос> [WITH CHECK OPTION];
где подзапрос, следующий за AS и являющийся определением данного представления, не исполняется, а просто сохраняется в каталоге
Пример 2 Предположим, что компания предусматривает премию для тех продавцов, которые имеют заказчика с самым большим заказом для любой указанной даты. Можно проследить эту информацию с помощью представления:
CREATE VIEW Максимум AS
SELECT b.odate, a.snum, a.sname FROM t1 a, t3 b
WHERE a.snum = b.snum AND b.amt =
(SELECT MAX (amt) FROM t3 c WHERE c.odate = b.odate);


.

является модифицируемой (т.е. по отношению к V можно использовать операторы

DELETE, UPDATE, INSERT) в том и только в том случае, если выполняются следующие условия для спецификации запроса:
в списке выборки не указано ключевое слово DISTINCT;
каждое арифметическое выражение в списке выборки представляет собой одну спецификацию столбца, и спецификация одного столбца не появляется более одного раза (не должно быть агрегатных функций и выражений);
в разделе FROM указана только одна таблица, являющаяся либо базовой таблицей, либо модифицируемым представлением;
в условии выборки раздела WHERE не используются подзапросы;
отсутствуют разделы GROUP BY и HAVING.

Создание и реализация триггеров.
Хранимая процедура — это сохраненная коллекция

инструкций языка Transact-SQL или ссылка на метод среды CLR платформы Microsoft .NET Framework, которая может принимать и возвращать предоставленные пользователем параметры. Процедуры можно создавать для постоянного использования, для временного использования в одном сеансе (локальная временная процедура) или для временного использования во всех сеансах (глобальная временная процедура).
Хранимые процедуры могут выполняться автоматически при запуске экземпляра SQL Server
Хранимые процедуры в аналогичны процедурам в других языках программирования:
они обрабатывают входные параметры и возвращают вызывающей процедуре или пакету значения в виде выходных параметров;
они содержат программные инструкции, которые выполняют операции в базе данных, в том числе вызывающие другие процедуры;
они возвращают значение состояния вызывающей процедуре или пакету, таким образом передавая сведения об успешном или неуспешном завершении (и причины последнего).

Создание и реализация триггеров.
Пример
 CREATE PROCEDURE au_info_all
AS

SELECT au_lname, au_fname, title, pub_name    
FROM authors a, titles t, publishers p, titleauthor ta        
WHERE a.au_id = ta.au_id        
AND t.title_id = ta.title_id        
AND t.pub_id = p.pub_id
Хранимые процедуры могут принимать информацию с помощью задания входных параметров.
Эти параметры определяются при создании хранимой процедуры с помощью выражения CREATE PROCEDURE.
При использовании входных параметров старайтесь придерживаться следующих рекомендаций:
По возможности определяйте для входных параметров значения по умолчанию. Для этого в определении хранимой процедуры используйте ключевое слово DEFAULT.
Проверяйте значения входных параметров в начале хранимой процедуры, чтобы определить отсутствующие или недопустимые значения.

Создание и реализация триггеров.
CREATE PROCEDURE HumanResources.usp_GetEmployeesName
@NamePrefix char(1)
AS
BEGIN
SELECT BusinessEntityID, FirstName,

LastName, EmailAddress
FROM HumanResources.vEmployee
WHERE FirstName LIKE @NamePrefix + '%'
ORDER BY FirstName
END

EXECUTE HumanResources.usp_GetEmployeesName ‘A’

Задание имен объектов в теле хранимой процедуры
ü

Одна хранимая процедура для выполнения одной задачи

ü

Задание имени хранимой процедуры

ü

Контекст выполнения хранимой процедуры

ü

Создание и реализация триггеров.
Использование процедур БД преследует четыре цели:
обеспечение

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

Создание и реализация триггеров.
Триггеры - это хранимые процедуры без

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

изменениях таблицы выражениями INSERT, UPDATE или

DELETE

ü

Выполняются в той же транзакции, что и инициирующее
действие

ü

AFTER выполняются после действий INSERT,
UPDATE или DELETE

INSTEAD OF выполняются вместо действий
INSERT, UPDATE или DELETE

Категории:

Создание и реализация триггеров.
CREATE TRIGGER Триггер_ins
ON Сделка
FOR

INSERT
AS
IF @@ROWCOUNT=1
BEGIN
IF NOT EXISTS(SELECT * FROM inserted WHERE inserted.количество<=ALL(SELECT Склад.Остаток FROM Склад,Сделка WHERE Склад.КодТовара= Сделка.КодТовара))
BEGIN
ROLLBACK TRANSACTION
PRINT 'Отмена поставки: товара на складе нет‘
END
END

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

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

известными как свойства АСИД:
(А) Атомарность. Транзакция выполняется как атомарная

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

системы допускают одновременную работу большого числа пользователей. При этом, если

не предпринимать специальных мер, транзакции будут мешать друг другу. Этот эффект известен как проблемы параллелизма.
Имеются три основных следствия проблемы параллелизма:
проблема потери результатов обновления;
проблема незафиксированной зависимости (чтение "грязных" данных, неаккуратное считывание);
проблема несовместимого анализа.
Для решения проблем параллельной обработки используют механизм блокировок: S-блокировки (Shared locks разделяемые) и X-блокировки (eXclusive locks монопольные). Протокол доступа к данным имеет вид:
Прежде, чем прочитать объект, транзакция должна наложить на этот объект S-блокировку.
Прежде, чем обновить объект, транзакция должна наложить на этот объект X-блокировку. Если транзакция уже заблокировала объект S-блокировкой (для чтения), то перед обновлением объекта S-блокировка должна быть заменена X-блокировкой.
Если блокировка объекта транзакцией B отвергается оттого, что объект уже заблокирован транзакцией A, то транзакция B переходит в состояние ожидания. Транзакция B будет находиться в состоянии ожидания до тех пор, пока транзакция A не снимет блокировку объекта.
X-блокировки, наложенные транзакцией A, сохраняются до конца транзакции A.

определения транзакций:
явное ;
автоматическое;
подразумеваемое.
По умолчанию SQL Server работает в режиме автоматического начала транзакций, когда

каждая команда рассматривается как отдельная транзакция. Явные транзакции
Явные транзакции требуют, чтобы пользователь указал начало и конец транзакции, используя следующие команды:
начало транзакции: в журнале транзакций фиксируются первоначальные значения изменяемых данных и момент начала транзакции ;
BEGIN TRAN[SACTION] [имя_транзакции | @имя_переменной_транзакции [WITH MARK [‘описание_транзакции’]]]
конец транзакции: если в теле транзакции не было ошибок, то эта команда предписывает серверу зафиксировать все изменения, сделанные в транзакции, после чего в журнале транзакций помечается, что изменения зафиксированы и транзакция завершена;
COMMIT [TRAN[SACTION] [имя_транзакции | @имя_переменной_транзакции]]
создание внутри транзакции точки сохранения: СУБД сохраняет состояние БД в текущей точке и присваивает сохраненному состоянию имя точки сохранения;
SAVE TRAN[SACTION] {имя_точки_сохранеия | @имя_переменной_точки_сохранения}

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

что транзакция была отменена. Приведенная ниже команда отменяет все изменения, сделанные в БД после оператора BEGIN TRANSACTION или отменяет изменения, сделанные в БД после точки сохранения, возвращая транзакцию к месту, где был выполнен оператор SAVE TRANSACTION.
ROLLBACK [TRAN[SACTION] [имя_транзакции | @имя_переменной_транзакции | имя_точки_сохранения |@имя_переменной_точки_сохранения]]
Функция @@TRANCOUNT возвращает количество активных транзакций.
Функция @@NESTLEVEL возвращает уровень вложенности транзакций.
BEGIN TRAN
SAVE TRANSACTION point1

моделирование структуры данных, опираясь на смысл этих данных. В качестве

инструмента семантического моделирования используются различные варианты диаграмм сущность-связь (ER - Entity-Relationship).
Первый вариант модели сущность-связь был предложен в 1976 г. Питером Пин-Шэн Ченом . В дальнейшем многими авторами были разработаны свои варианты подобных моделей (нотация Мартина, нотация IDEF1X, нотация Баркера и др. По сути, все варианты диаграмм сущность-связь исходят из одной идеи - рисунок всегда нагляднее текстового описания. Все такие диаграммы используют графическое изображение сущностей предметной области, их свойств (атрибутов), и взаимосвязей между сущностями.
Прежде, чем мы коротко рассмотрим особенности одной из распространенных семантических моделей, остановимся на их возможных применениях:
1. Наиболее часто на практике семантическое моделирование используется на первой стадии проектирования базы данных. При этом в терминах семантической модели производится концептуальная схема базы данных, которая затем вручную преобразуется к реляционной (или какой-либо другой) схеме. Этот процесс выполняется под управлением методик, в которых достаточно четко оговорены все этапы такого преобразования.
2. Реализуется автоматизированная компиляция концептуальной CASE-схемы в реляционную. При этом известны два подхода:
на основе явного представления концептуальной схемы как исходной информации для компилятора;
построения интегрированных систем проектирования с автоматизированным созданием концептуальной схемы на основе интервью с экспертами предметной области.
И в том, и в другом случае в результате производится реляционная схема БД в третьей нормальной форме.

в семантической модели, т.е. СУБД, основанные на семантических моделях данных.

При этом снова рассматриваются два варианта:
обеспечение пользовательского интерфейса на основе семантической модели данных с автоматическим отображением конструкций в реляционную модель данных;
прямая реализация СУБД, основанная на какой-либо семантической модели данных. Наиболее близко ко второму подходу находятся современные объектно-ориентированные СУБД, модели данных которых по многим параметрам близки к семантическим моделям (хотя в некоторых аспектах они более мощны, а в некоторых - более слабы).
Основные понятия модели Entity-Relationship
Опишем работу с ER-диаграммами близко к нотации Баркера, как довольно легкой в понимании основных идей.
Определение 1. Сущность - это класс однотипных объектов, информация о которых должна быть учтена в модели.
Каждая сущность должна иметь наименование, выраженное существительным в единственном числе. Примерами сущностей могут быть такие классы объектов как «Поставщик», «Сотрудник», «Накладная».
Каждая сущность в модели изображается в виде прямоугольника с наименованием (рис.1).

- это конкретный представитель данной сущности.
Например, представителем сущности «Сотрудник»

может быть «Сотрудник Иванов».
Экземпляры сущностей должны быть различимы, т.е. сущности должны иметь некоторые свойства, уникальные для каждого экземпляра этой сущности.
Определение 3. Атрибут сущности - это именованная характеристика, являющаяся некоторым свойством сущности.
Наименование атрибута должно быть выражено существительным в единственном числе (возможно, с характеризующими прилагательнми). Примерами атрибутов сущности «Сотрудник» могут быть такие атрибуты как «Табельный номер», «Фамилия», «Имя», «Отчество», «Должность», «Зарплата» и т.п.
Атрибуты изображаются в пределах прямоугольника, определяющего сущность (рис. 2).
Определение 4. Ключ сущности - это неизбыточный набор атрибутов, значения которых в совокупности являются уникальными для каждого экземпляра сущности. Неизбыточность заключается в том, что удаление любого атрибута из ключа нарушается его уникальность.

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

Связь - это графически изображаемая ассоциация, устанавливаемая между двумя сущностями. Эта ассоциация всегда является бинарной и может существовать между двумя разными сущностями или между сущностью и ей же самой (рекурсивная связь).
Связи позволяют по одной сущности находить другие сущности, связанные с нею.
Например, связи между сущностями могут выражаться следующими фразами – «СОТРУДНИК может иметь несколько ДЕТЕЙ», «каждый СОТРУДНИК обязан числиться ровно в одном ОТДЕЛЕ».
Графически связь изображается линией, соединяющей две сущности.
Каждая связь имеет два конца и одно или два наименования. Наименование обычно выражается в неопределенной глагольной форме: "иметь", "принадлежать" и т.п.
Каждое из наименований относится к своему концу связи. Иногда наименования не пишутся ввиду их очевидности.
Каждая связь может иметь один из следующих типов связи

экземпляр первой сущности (левой) связан с одним экземпляром второй сущности

(правой). Связь один-к-одному чаще всего свидетельствует о том, что на самом деле мы имеем всего одну сущность, неправильно разделенную на две.
Связь типа один-ко-многим означает, что один экземпляр первой сущности (левой) связан с несколькими экземплярами второй сущности (правой). Это наиболее часто используемый тип связи. Левая сущность (со стороны "один") называется родительской, правая (со стороны "много") - дочерней. Характерный пример такой связи приведен на рис. 4.
Связь типа много-ко-многим означает, что каждый экземпляр первой сущности может быть связан с несколькими экземплярами второй сущности, и каждый экземпляр второй сущности может быть связан с несколькими экземплярами первой сущности. Тип связи много-ко-многим является временным типом связи, допустимым на ранних этапах разработки модели. В дальнейшем этот тип связи должен быть заменен двумя связями типа один-ко-многим путем создания промежуточной сущности.
Каждая связь может иметь одну из двух модальностей связи

сущности может быть связан с одним или несколькими экземплярами другой

сущности, а может быть и не связан ни с одним экземпляром.
Модальность «должен» означает, что экземпляр одной сущности обязан быть связан не менее чем с одним экземпляром другой сущности. Связь может иметь разную модальность с разных концов Описанный графический синтаксис позволяет однозначно читать диаграммы, пользуясь следующей схемой построения фраз:
<Каждый экземпляр СУЩНОСТИ 1> <МОДАЛЬНОСТЬ СВЯЗИ> <НАИМЕНОВАНИЕ СВЯЗИ> <ТИП СВЯЗИ> <экземпляр СУЩНОСТИ 2>.
Каждая связь может быть прочитана как слева направо, так и справа налево. Связь на рис.4 читается так:
Слева направо: «каждый сотрудник может иметь несколько детей».
Справа налево: «Каждый ребенок обязан принадлежать ровно одному сотруднику».

г.

моделирование структуры данных, опираясь на смысл этих данных. В качестве

инструмента семантического моделирования используются различные варианты диаграмм сущность-связь (ER - Entity-Relationship).
Первый вариант модели сущность-связь был предложен в 1976 г. Питером Пин-Шэн Ченом . В дальнейшем многими авторами были разработаны свои варианты подобных моделей (нотация Мартина, нотация IDEF1X, нотация Баркера и др. По сути, все варианты диаграмм сущность-связь исходят из одной идеи - рисунок всегда нагляднее текстового описания. Все такие диаграммы используют графическое изображение сущностей предметной области, их свойств (атрибутов), и взаимосвязей между сущностями.
Прежде, чем мы коротко рассмотрим особенности одной из распространенных семантических моделей, остановимся на их возможных применениях:
1. Наиболее часто на практике семантическое моделирование используется на первой стадии проектирования базы данных. При этом в терминах семантической модели производится концептуальная схема базы данных, которая затем вручную преобразуется к реляционной (или какой-либо другой) схеме. Этот процесс выполняется под управлением методик, в которых достаточно четко оговорены все этапы такого преобразования.
2. Реализуется автоматизированная компиляция концептуальной CASE-схемы в реляционную. При этом известны два подхода:
на основе явного представления концептуальной схемы как исходной информации для компилятора;
построения интегрированных систем проектирования с автоматизированным созданием концептуальной схемы на основе интервью с экспертами предметной области.
И в том, и в другом случае в результате производится реляционная схема БД в третьей нормальной форме.

моделирование структуры данных, опираясь на смысл этих данных. В качестве

инструмента семантического моделирования используются различные варианты диаграмм сущность-связь (ER - Entity-Relationship).
Первый вариант модели сущность-связь был предложен в 1976 г. Питером Пин-Шэн Ченом . В дальнейшем многими авторами были разработаны свои варианты подобных моделей (нотация Мартина, нотация IDEF1X, нотация Баркера и др. По сути, все варианты диаграмм сущность-связь исходят из одной идеи - рисунок всегда нагляднее текстового описания. Все такие диаграммы используют графическое изображение сущностей предметной области, их свойств (атрибутов), и взаимосвязей между сущностями.
Прежде, чем мы коротко рассмотрим особенности одной из распространенных семантических моделей, остановимся на их возможных применениях:
1. Наиболее часто на практике семантическое моделирование используется на первой стадии проектирования базы данных. При этом в терминах семантической модели производится концептуальная схема базы данных, которая затем вручную преобразуется к реляционной (или какой-либо другой) схеме. Этот процесс выполняется под управлением методик, в которых достаточно четко оговорены все этапы такого преобразования.
2. Реализуется автоматизированная компиляция концептуальной CASE-схемы в реляционную. При этом известны два подхода:
на основе явного представления концептуальной схемы как исходной информации для компилятора;
построения интегрированных систем проектирования с автоматизированным созданием концептуальной схемы на основе интервью с экспертами предметной области.
И в том, и в другом случае в результате производится реляционная схема БД в третьей нормальной форме.

нормализованные модели данных хорошо подходят для так называемых OLTP-приложений (On-Line

Transaction Processing - оперативная обработка транзакций).
Типичными примерами OLTP-приложений являются:
системы складского учета,
системы заказов билетов,
банковские системы, выполняющие операции по переводу денег,
системы отслеживания компонентов во время сборки конечного продукта на производстве и т.п.
Основная функция подобных систем заключается в выполнении большого количества коротких транзакций.
Сами транзакции выглядят относительно просто, например, «снять сумму денег со счета А, добавить эту сумму на счет В». Время ожидания типичных запросов в таких системах не должна превышать нескольких секунд.

организации БД, при котором система работает с небольшими по размерам транзакциями, но

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

OLTP-систем заключается в том, что:
транзакций очень много;
выполняются они одновременно (к

системе может быть подключено несколько тысяч одновременно работающих пользователей);
при возникновении ошибки, транзакция должна целиком откатиться и вернуть систему к состоянию, которое было до начала транзакции (не должно быть ситуации, когда деньги сняты со счета А, но не поступили на счет В).
Практически все запросы к базе данных в OLTP-приложениях состоят из команд вставки, обновления, удаления.
Запросы на выборку в основном предназначены для предоставления пользователям возможности выбора из различных справочников. Большая часть запросов, таким образом, известна заранее еще на этапе проектирования системы. Пример запроса: «есть ли свободные места в купе поезда Москва-Сочи, отправляющегося 20 августа в 23:15».
Критическим для OLTP-приложений является скорость и надежность выполнения коротких операций обновления данных. Чем выше уровень нормализации данных в OLTP-приложении, тем оно, как правило, быстрее и надежнее.
OLTP-системы требуют защиты от несанкционированного доступа, от нарушения целостности, аппаратных и программных сбоев
.
.

analytical processing, аналитическая обработка в реальном времени) — набор технологий для

оперативной обработки информации, включающих динамическое построение отчётов в различных разрезах, анализ данных, мониторинг и прогнозирование ключевых показателей бизнеса. В основе OLAP-технологий лежит представление информации в виде OLAP-кубов.
Реализации технологии OLAP являются компонентами программных решений класса Business Intelligence.
Основоположник термина OLAP — Эдгар Кодд, предложил в 1993 году «12 законов аналитической обработки в реальном времени» -многомерность, прозрачность, доступность, постоянная производительность при разработке отчетов, клиент- серверная архитектура, равноправие измерений, динамическое управление разреженными матрицами, поддержка многопользовательского режима, неограниченные перекрестные операции, интуитивная манипуляция данными, гибкие возможности получения отчетов, неограниченная размерность и число уровней агрегации.
.

(On-Line Analitical Processing - оперативная аналитическая обработка данных). Это обобщенный

термин, характеризующий принципы построения систем поддержки принятия решений (СППР) (Decision Support System - DSS), хранилищ данных (Data Warehouse), систем интеллектуального анализа данных (Data Mining). Такие системы предназначены для нахождения зависимостей между различными данными.
Приведем примеры запросов:
«как связан объем продаж товаров с характеристиками потенциальных покупателей»;
«каким будет объем продаж железнодорожных билетов в следующие 3 месяца с учетом сезонных колебаний»),
для проведения анализа "что если…".

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

OLAP-приложений обычно представлены в виде одного или нескольких гиперкубов, измерения

которого представляют собой справочные данные, а в ячейках самого гиперкуба хранятся собственно данные. Например, можно построить гиперкуб, измерениями которого являются: время (в кварталах, годах), тип товара и отделения компании, а в ячейках хранятся объемы продаж. Такой гиперкуб будет содержать данных о продажах различных типов товаров по кварталам и подразделениям. Основываясь на этих данных, можно отвечать на вопросы типа "у какого подразделения самые лучшие объемы продаж в текущем году?", или
"каковы тенденции продаж отделений Юго-Западного региона в текущем году по сравнению с предыдущим годом?"
Физически гиперкуб может быть построен на основе специальной многомерной модели данных (MOLAP - Multidimensional OLAP) или построен средствами реляционной модели данных (ROLAP - Relational OLAP).

счет применения мощной многопроцессорной ВТ, сложных методов анализа и специальных

хранилищ данных, накапливающих информацию из разных источников за большой период времени и обеспечивающих быстрый доступ к ней (Data Warehouse ).
В большинстве случаев сложный аналитический запрос невозможно сформулировать в терминах языка SQL, поэтому приходится применять специализированные языки, ориентированные на аналитическую обработку данных. К их числу можно отнести, например, язык Express 4GL (язык четвертого поколения - 4 Generation Language фирмы Oracle).

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

сети получила название архитектуры «клиент-сервер». Каждый из составляющих эту архитектуру элементов играет свою роль: сервер владеет и распоряжается информационными ресурсами системы (например, БД); клиент имеет возможность пользоваться ими. Для современных СУБД архитектура «клиент-сервер» стала фактическим стандартом.
Если предполагается, что проектируемая ИС будет иметь архитектуру «клиент-сервер», то прикладные программы, реализованные в ее рамках, будут иметь распределенный характер, т.е. часть функций будет реализована в программе-клиенте, а другая – в программе-сервере. Основной принцип технологии «клиент-сервер» заключается в разделении функций стандартного интерактивного приложения на 4 группы:
функции ввода и отображения данных;
прикладные функции, характерные для предметной области (например, открытие счета для банковской системы);
фундаментальные функции хранения и управления информационными ресурсами (БД, файловыми системами);
служебные функции, играющие роль связок между функциями первых трех групп.

может состоять из компонентов (таблица 1).
Таблица 1 – Связь между

компонентами и функциями приложения
№ Функции Логический компонент
1 Ввода и отображения данных Компонент представления (КП)
2 Прикладные Прикладной компонент (ПрК)
3 Хранения и управления Компонент доступа к ресурсам (КДР)
информационными ресурсами

Различия в реализациях технологии «клиент-сервер» определяются четырьмя факторами:
тем, в какие виды программного обеспечения интегрированы каждый из этих компонентов;
тем, какие механизмы программного обеспечения используются для реализации функций первых 3 групп;
как логические компоненты распределяются между компьютерами в сети;
какие механизмы используются для связи компонентов между собой.

(File Server – FS);
модель доступа к удаленным данным

(Remote Data Access - RDA);
модель сервера БД
(Database Server – DBS );
модель сервера приложений
(Application Server - AS)

приложению),
узкий спектр операций манипулирования данными ("данные - это файлы"),

отсутствие адекватных средств безопасности доступа к данным (защита только на уровне файловой системы), т.е. управление параллельной работой, восстановлением и целостностью усложняется, поскольку доступ к одним и тем же файлам могут осуществлять сразу несколько экземпляров СУБД.
проблема «толстого клиента» - Windows, интерфейс, коды приложения и полная копия СУБД могут перегрузить даже мощный компьютер

Технологии и модели архитектуры «клиент-сервер»

унификация интерфейса "клиент-сервер" в виде языка SQL.
Перенос компонента представления

и прикладного компонента на компьютеры-клиенты существенно разгружает сервер БД, сводя к минимуму общее число процессов операционной системы.
Уменьшается загрузка сети, так как по ней передаются от клиента к серверу не запросы на ввод-вывод (как в FS), а запросы на языке SQL, их объем существенно меньше.

SQL-запросов по-прежнему значительно загружает сеть
Удовлетворительное администрирование приложений в RDA-модели практически

невозможно из-за совмещения в одной программе различных по своей природе функций (функции представления и прикладные)

функций
Снижение трафика (вместо SQL-запросов по сети направляются вызовы хранимых

процедур)
Возможность разделения процедуры между несколькими приложениями
Экономия ресурсов компьютера за счет использования единожды созданного плана выполнения процедуры

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

СУБД отсутствуют возможности отладки и тестирования разработанных хранимых процедур.
Современные многопользовательские СУБД опираются на RDA- и DBS-модели, либо используют их разумное сочетание.
Поддержка целостности базы данных и некоторые простейшие прикладные функции поддерживаются хранимыми процедурами (DBS-модель), а более сложные функции реализуются непосредственно в прикладной программе, которая выполняется на компьютере-клиенте (RDA-модель).

приложений для большого числа клиентов при отсутствии унификации в конфигурациях

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

в отношении быстродействия и памяти по разным вычислительным установкам, используется

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

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

изменению данных сервер приложений, как в RDA-модели, обращается к SQL-серверу, направляя ему

вызовы SQL-процедур, и получая, соответственно, от него наборы данных. Как известно, последовательная совокупность операций над данными (SQL-инструкций), имеющая отдельное смысловое значение, называется транзакцией. 
В этом отношении сервер приложений от клиентов системы управляет формированием транзакций, которые выполняет SQL-сервер. Поэтому программный компонент СУБД, инсталлируемый на сервере приложений, еще называют также монитором обработки транзакций (Transaction Processing Monitors — TRM), или просто монитором транзакций

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

RDA-модели, повышает трафик сети.
В еще не устоявшейся до конца терминологии по моделям и технологиям «Клиент-сервер» RDA-модель характеризуют еще как модель с так называемыми «толстыми», а DBS-модель и AS-модель как модели, соответственно, с «тонкими» клиентами. 
По критерию звеньев системы RDA-модель и DBS-модель называютдвухзвенными (двухуровневыми) системами, a AS-модель трехзвенной (трехуровневой) системой.

распределенных баз данных. Особенности функционирования распределенных баз данных
Распределенная база данных: Набор

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

данных по сети.
Способы решения этой задачи:
в каждом узле сети

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

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

располагаются на различных узлах сети компьютеров, и, возможно управляются различными СУБД.
Распределенная БД выглядит с точки зрения пользователей и прикладных программ как обычная локальная база данных. Слово «распределенная» отражает способ организации БД, но не внешнюю ее характеристику («распределенность» БД невидима извне).
Примерами СУБД, обеспечивающих распределенную обработку данных являются: R-Star, Distributed Ingres, Oracle 7, Ingres/Star, Sybase, Informix-OnLine Dynamic Server.

и выполнение функций управления данными в нескольких узлах и передачу

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

Типовые решения, экономическая эффективность и совокупная стоимость владения.
Распределенная БД -

это множество физических баз данных, которые выглядят для пользователя как одна логическая БД. Следующие СУБД:
 - Informix On-Line фирмы Informix Software;
- Ingres Intelligent Database фирмы Ingres Corp;
- Oracle (version 7) фирмы Oracle Corp;
- Sybase System 10 фирмы Sybase Inc.
В большинстве случаев распределенная СУБД состоит из ядра СУБД и набора дополнительных продуктов, покупаемых отдельно, которые обеспечивают работу с распределенной БД. Некоторые фирмы­-разработчики СУБД встраивают средства работы с распределенной БД в ядро СУБД. Кроме того, различные фирмы вкладывают разные понятия в термин "распределенная СУБД" и по разному определяют набор необходимых для такой СУБД функций. Поэтому потенциальным покупателям распределенных СУБД очень непросто сравнивать эти СУБД между собой и делать правильный выбор.
Возникли новые требования к архитектуре корпоративной ИПС и, как следствие, – новые требования к распределенным БД, основные из которых следующие:
– обеспечение доступа ко всем необходимым данным распределенных БД;
–

Типовые решения, экономическая эффективность и совокупная стоимость владения.
- применение наиболее

типовых и перспективных архитектур БД и программных средств: хранилищ данных, оперативной аналитической обработки данных (OLAP), быстрой разработки приложений (RAD) для создания "ИС руководителя" (EIS), средств поддержки принятия решений (DSS) на основе хранилищ данных,
OLAP и RAD/EIS и др.;
– применение методов логического вывода, нейронных сетей, нейрокомпьютеров и др.;
– применение единого интерфейса пользователя для работы с разными компонентами данных и приложений;
– постоянная актуализация понятийной модели для учета новых понятий, возникающих при изменении прикладных задач;
–- динамическое администрирование распределенной корпоративной БД при изменении частоты использования, модификации структуры и изменении размещения данных и др.