Информационные системы. Основные функции и области применения.

История развития СУБД.

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

В середине 60-х гг. корпорация IBM разработала первую СУБД, иерархическуюсистему IMS (Information Management System). Несмотря на то, что это СУБД является самой первой из всех коммерческих СУБД, она до сих пор остается основной иерархической СУБД используемой на большинстве крупных мэйкфрэймов.

Другим заметным достижением середины 60-х гг. было появление системы IDS (IntegratedDataStore) фирмы GeneralElectric. Развитие этой системы привело к созданию нового типа СУБД – сетевых СУБД, что оказало существенное влияние на ИС того поколения.

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

Полный вариант отчета был опубликован в 1971 году, и содержал следующие утверждения:

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

2) Подсказка – часть БД видимая конкретными пользователями и приложениями.

3) Языки управления данными – инструмент для определения характеристик и структуры данных, а также для управления ими.

4) Язык определения данных для схемы, который позволяет описать ее.

5) Язык определения данных для подсистем, который позволяет определить в приложениях те части БД, доступ к которым будет необходим.

6) Язык манипулирования данными. DML –язык манипулирования данными, DDL – язык определения данных

В 1970 году Эдгар Кодд, работавший в IBM опубликовал статью о реляционной модели данных, позволявшей устранить недостатки прежних моделей. Вслед за этим появилось множество экспериментальных реляционных СУБД, а первые коммерческие продукты появились в конце 70-х – начале 80-х гг.

Следует отметить проект SystemR, разрабатываемый IBM в конце 70-х гг. Этот проект был задуман с целью доказать практичность реляционной модели, что достигалось посредством реализации предусмотренных его структур данных и требуемых функциональных возможностей. Был разработан структурированный язык запросов – SQL, который стал стандартным языком реляционных СУБД.

В 80-х гг. были созданы различные коммерческие реляционные СУБД, например, Oracle, DB2, SQL\DS.

В настоящее время существует несколько сотен различных реляционных СУБД для мэйфрэймов и ПЭВМ. Примерами реляционных СУБД для ПК являются: Access, FoxPro, Paradox, dBase.

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

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

В ответ на возрастающую сложность приложений БД появились 2 новые системы:

1) ООСУБД

2) Объектно-реляционный СУБД

Такие СУБД представляют СУБД 3-го поколения.

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

Информационные системы. Основные функции и области применения.

В основе решения многих задач лежит обработка информации. Для облегчения обработки информации создаются информационные системы (ИС).

Автоматизированными наз. ИС, в которых применяются технические средства.

В широком смысле под определение ИС попадает любая система обработки информации.

По области применения ИС делятся на системы, используемые в:

- социальной системе;

- сельской деятельности;

- промышленности;

- военной отрасли и т.п.

По целевым функциям ИС делятся на:

1. управляющие,

2. информационно-справочные,

3. поддержки принятия решений.

ИС– это аппаратно-программные средства, задействованные для решения некоторой прикладной задачи.

 

 

Банк данных и его компоненты.

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

Банк данных в общем случае состоит из следующих компонентов:

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

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

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

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

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

6 вычислительной системы ( представляет собой совокупность взаимосвязей и согласованно действующей ПЭВМ в процессорах и других устройствах, обеспечивающих автоматизацию процессов приёма, обработки и выдачи информации потребителю).

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

 

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

Данные, хранимые в БД, описываются на основе некоторой модели представления данных, которая поддерживает конкретную СУБД.

Модель данных – совокупность разрешенных типов структур данных, записей, групповых отношений (связей) между экземплярами записей и операций по их обработке.

К классическим относят следующие модели данных:

- иерархическую;

- сетевую;

- реляционную.

- постреляционная;

- многомерная;

- объектно-ориентированная.

Разрабатываются также всевозможные системы, основанные на других моделях данных. В их числе можно назвать: объектно-реляционные, дедуктивно-объектно-реляционные, семантические, концептуальные, ориентированные.

Некоторые из этих моделей служат для интеграции БД и ЯП. В некоторых СУБД поддерживается одновременно несколько моделей данных.

Классификация программ СУБД

К СУБД относятся следующие основные виды программ:

1. Полнофункциональные СУБД;

2. Серверы БД;

3. Клиенты БД;

4. Средства разработки программ работы с БД.

Полнофункциональные СУБД представляют собой традиционные СУБД, которые сначала появились для больших машин, затем для минимашин и для ПЭВМ. К ним относятся такие пакеты, как: Clarion Database Developer, DataEase, DataFlex, dBaseIV, Microsoft Access, FoxPro, Paradox. Обычно полнофункциональные СУБД имеют развитый интерфейс, позволяющий с помощью команд меню выполнять основные действия с БД: создавать и модифицировать структуры таблиц, вводить данные, формировать запросы, разрабатывать отчеты, выводить их на печать и т.п. Многие полнофункциональные СУБД включают средства программирования для профессиональных разработчиков. Некоторые системы имеют в качестве вспомогательных и дополнительные средства проектирования схем БД. Для обеспечения доступа к другим БД или к данным SAL-серверов полнофункциональные СУБД имеют специальные библиотеки функций.

Серверы БД предназначены для организации центров обработки данных в сетях ЭВМ. Серверы БД реализуют функции управления базами данных, запрашиваемые другими (клиентскими) программами обычно с помощью операторов SQL. Примеры серверов БД: MS SQL Server (Microsoft), InterBase (Borland), Intelligent Database (Ingress). В роли клиентских программ для серверов БД могут использоваться различные программы: полнофункциональные СУБД, программы электронной почты и т.д. При этом элементы пары «клиент-сервер» могут принадлежать одному или разным производителям программного обеспечения.

Средства разработки программ работы с БД могут использоваться для создания разновидностей следующих программ:

· клиентских программ;

· серверов БД и их отдельных компонентов;

· пользовательских приложений.

Программы первого и второго вида предназначены, главным образом, для программистов. К средствам разработки пользовательских приложений относятся системы программирования, например, Clipper, разнообразные библиотеки программ для различных языков программирования, а также пакеты автоматизации разработок. Наиболее распространенными являются следующие инструментальные системы: Delphi и Power Builder (Borland), Visual Basic (Microsoft), SILVERRUN (Computer Advisers Inc.), Erwin (LogicWorks).

8. Общие понятия реляционного подхода к организации баз данных. Основные концепции и термины

Реляционная модель была предложена в 1970 г Э.Коддом и основывается на понятии «отношение».

Отношение представляет собой 2-х мерную таблицу, содержащую некоторые данные.

Сущность – объект любой природы, данные о котором хранятся в БД.

Атрибут – свойство хранящее сущность. В структуре таблицы каждый атрибут именуется и ему в соответствие ставится заголовок некоторого столбца таблицы.

Домен – множество всех возможных значений определенного атрибута отношений.

Схема отношений – список имен атрибутов.

Кортеж – ему соответствует строка таблицы. Множество кортежей – содержимое отношения.

ФИО	Отдел	Должность
Иванов		Начальник
Петров		Инженер

Отношения – вся таблица, атрибуты – 1. ФИО, Иванов, Петров, 2.Отдел, 001, 002, 3. Должность, начальник, инженер, кортежи – 1. Иванов, 001, начальник, 2. Петров, 002, инженер, домены – 1. Иванов, Петров, 2.001, 002, 3. Начальник, инженер, Сущность – все домены, схема отношений – строка заголовков.

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

Реляционное исчисление

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

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

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

В построении запросов на языке реляционного исчисления принято использовать квант существования и квант всеобщности.

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

Квант всеобщности – это выражение, которое означает, что некоторое условие применяется ко всем строкам некоторого типа.

 

Журнализация изменений БД

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

Восстановление БД может производиться в следующих случаях:

1. Индивидуальный откат транзакции. Индивидуальный откат транзакции может быть инициирован либо самой транзакцией путем подачи команды Roll Back, либо системой. СУБД может инициировать откат транзакции в случае возникновения какой-нибудь ошибки либо, если эта транзакция выбрана в качестве жертвы при разрешении тупика.

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

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

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

Поддерживается 2 вида буферов:

1. Буферы страниц БД;

Буферы журнала транзакции;

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

Имеются 2 причины для периодического выталкивания страниц во внешнюю память:

1. Недостаток ОП;

2. Возможность сбоев;

Основным принципом согласованной политики выталкивания буфера журнала и буфера страниц БД является то, что запись об изменении объекта БД должна попадать во внешнюю память журнала раньше, чем измененный объект оказывается во внешней памяти БД. Соответствующий протокол журнализации называется WHL (write a head lock - пиши сначала в журнал) и состоит в том, что, если требуется вытолкнуть во внешнюю память измененный объект БД, то перед этим нужно гарантировать выталкивание во внешнюю память журнала записи об его изменении.

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

Синхронизационные захваты

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

Основными режимами синхронизационных захватов являются:

Ä совместный режим - S (Shared), означающий разделяемый захват объекта и требуемый для выполнения операции чтения объекта;

Ä монопольный режим - X (eXclusive), означающий монопольный захват объекта и требуемый для выполнения операций занесения, удаления и модификации.

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

Для обеспечения сериализации транзакций (третьего уровня изолированности) синхронизационные захваты объектов, произведенные по инициативе транзакции, можно снимать только при ее завершении. Это требование порождает двухфазный протокол синхронизационных захватов - 2PL. В соответствии с этим протоколом выполнение транзакции разбивается на две фазы:

· первая фаза транзакции - накопление захватов;

· вторая фаза (фиксация или откат) - освобождение захватов.

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

Метод временных меток

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

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

Для этого каждой транзакции T предписывается временная метка t, соответствующая времени начала T. При выполнении операции над объектом r транзакция T помечает его своей временной меткой и типом операции (чтение или изменение).

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

· Проверяет, не закончилась ли транзакция T, пометившая этот объект. Если T закончилась, T1 помечает объект r и выполняет свою операцию.

· Если транзакция T не завершилась, то T1 проверяет конфликтность операций. Если операции неконфликтны, при объекте r остается или проставляется временная метка с меньшим значением, и транзакция T1 выполняет свою операцию.

· Если операции T1 и T конфликтуют, то если t(T) > t(T1) (т.е. транзакция T1 является более "молодой", чем T), производится откат T и T1 продолжает работу.

· Если же t(T) < t(T1) (T "старше" T1), то T1 получает новую временную метку и начинается заново.

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

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

Типы данных SQL

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

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

Числовые типы данных

Ü INTEGER – используется для представления целых чисел в диапазоне от -2³¹ до +2³¹

Ü SMALLINT - используется для представления целых чисел в диапазоне от -2¹⁵ до +2¹⁵

Ü DECIMAL (точность [, масштаб]) – десятичное число с фиксированной точкой, точность определяет количество значащих цифр в числе. Масштаб указывает максимальное число цифр справа от точки.

Ü NUMERIC (точность [, масштаб]) - – десятичное число с фиксированной точкой, такое же как и DECIMAL

Ü FLOAT [(точность)] – число с плавающей точкой и указанной минимальной точностью.

Ü REAL – число с плавающей точкой, точность определена по умолчанию.

Ü DOUBLE PRECISION – число аналогично REАL, но точность в два раза выше точности REAL.

Дата и время

Тип данных для представления даты и времени является нестандартным и определяется конкретной реализацией SQL. В наиболее общем случае поддерживается тип DATE и тип TIME для представления даты и времени соответственно.

DELETE

FROM STUDENT

WHERE UNIV_ID IN

(SELECT UNIV_ID

FROM UNIVERSITY

WHERE CITY = ‘ВОРОНЕЖ’); (33.16)

В предикате предложения FROM (подзапроса) нельзя ссылаться на таблицу, из которой осуществляется удаление. Однако можно ссылаться на текущую строку из таблицы, являющуюся кандидатом на удаление, то есть на строку, которая в настоящее время проверяется в основном предикате.

Пример. Удалить данные о студентах, которые учатся в университетах, имеющих рейтинг 401

DELETE

FROM STUDENT

WHERE EXISTS

(SELECT *

FROM UNIVERSITY

WHERE RATTING = 401

AND STUDENT.UNIV_ID = UNIVERSITY.UNIV_ID); (33.17)

 

Второй способ решения этой задачи.

DELETE

FROM STUDENT

WHERE 401 IN

(SELECT RATTING

FROM UNIVERSITY

WHERE STUDENT.UNIV_ID = UNIVERSITY.UNIV_ID); (33.18)

Синтаксис описания домена.

CREATE DOMEN <name – domain> -> имя домена

[AS] <data-type>-> тип домена (любой допустимый)

[DEFAULT { LITERAL |NULL| USER}] -> значение по умолчанию

[NOT NULL] [CHECK (<domain-condition>)];

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

LITERAL – указывает значение явно

NULL – оставляет значение пустым

USER – имя пользователя, создающего запись

Для полей типа Date можно указать Now (текущая дата)

NOT NULL- запрещает ввод пустых значений

CHECH (<dom.condition>) – задаёт ограничения (описание контроля данных при вводе и изменении)

Для задания условия используются следующие ключевые слова:

VALUE - подразумевает значение, вводимое в поле

IS NULL, IS NOT NULL, BETWEEN…AND…, LIKE, IN,

а также арифметические операторы.

Значение домена создаются независимо друг от друга, и, тем более, от других таблиц. Следовательно, CHECH в домене не может ссылаться ни на какой другой домен или столбец таблицы. Домен может иметь только одну конструкцию CHECH. Конструкция CHECH не может быть переопределена при описании атрибута таблицы. Если при описании поля в таблице, ссылающегося на домен, имеющий CHECH, указано своё ограничение, то действовать будут оба ограничения.

Пример.

CREATE DOMAIN USER_NAME

AS VARCHAR(20)

DEFAULT USER;

 

CREATE DOMAIN MONTH

AS SMALLINT

CHECH (VALUE BETWEEN 1 AND 12);

 

CREATE DOMAIN D_ELEM

AS CHAR (2)

CHECH (VALUE IN (‘Au’, ‘Ag’, ‘Pf ’, ‘Pd’, ‘Os’));

Создание доменов

Перед тем, как создавать таблицы, которые ссылаются на домены, необходимо задать описания доменов при использовании команды CREATE DOMAIN. В результате ее выполнения создается шаблон, на который можно ссылаться в командах создания и модификации таблиц.

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

CREATE DOMAIN <name_domain> [ AS ] <data_type>

[ DEFAULT { literal | NULL | USER }]

[ NOT NULL ] [ CHECK (<dom_condition>)];

<name_domain> - имя создаваемого домена; <data_type> - любой допустимый тип данных;

[ DEFAULT { literal | NULL | USER }] – задание значения по умолчанию. Значение по умолчанию присваивается соответствующему атрибуту при создании новой строки в таблице, если его значение не указано явно. Literal – указывает значение явно; NULL – оставляет значение пустым; USER – имя пользователя, создавшего запись. Для полей типа дата можно указывать NOW – вводится текущая дата.

NOT NULL – запрещает ввод пустых значений.

CHECK (<dom_condition>) – задает ограничение (описание контроля данных при вводе и изменении). Для задания условия используются следующие ключевые слова:

VALUE – подразумевает значение, вводимое в поле;

IS NULL, IS NOT NULL;

BETWEEN…AND; LIKE, IN;

А также все арифметические и логические операторы.

Изменение доменов осуществляется командой ALTER DOMAIN. С помощью данной команды можно изменить любые характеристики домена, кроме типа данных и установок NOT NULL. Сделанные изменения воздействуют на атрибуты всех таблиц, где использовался измененный домен.

Команду ALTER DOMAIN может выдать либо создатель домена, либо пользователь с правами системного администратора.

Для изменения типа поля или установки NOT NULL необходимо удалить домен, если это возможно (если домен используется для описания столбцов каких-либо таблиц, то удалить его нельзя), а затем создать его снова с требуемыми характеристиками.

Синтаксис команды изменения домена:

ALTER DOMAIN name_domain {

[SET DEFAULT { literal| NULL | USER}]

[DROP DEFAULT]

[ADD [CONSTRAINT] CHECK (< dom_condition >)]

[DROP CONSTRAINT]

};

[DROP DEFAULT] – удалить значение по умолчанию;

[ADD [CONSTRAINT] CHECK (<dom_condition>)] – добавить ограничение;

[ DROP CONSTRAINT ] – удалить ограничение.

Удаление доменов осуществляется командой DROP DOMAIN. Если домен используется в каких-либо таблицах, то удалить его нельзя.

Синтаксис команды:

DROP DOMAIN name_domain;

Модификация таблицы

Для изменения структуры уже существующей таблицы предназначена команда ALTER TABLE, которая позволяет:

ü Добавить в таблицу новый столбец;

ü Удалить уже существующий столбец;

ü Добавить в таблицу или удалить из нее ограничение на столбец или таблицу в целом.

В одной команде ALTER TABLE можно задать любое число изменений. Внесение изменений разрешено создателю таблицы или системному администратору.

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

Удаление столбца из таблицы

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

Изменение формата столбца

Стандартный синтаксис команды ALTER TABLE не предполагает возможности изменения столбца. Поэтому изменение предполагает как минимум две команды ALTER TABLE. Первая из них удаляет столбец, а вторая – добавляет новый столбец с новыми ограничениями.

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

v Добавить новый столбец с тем же типом данных, что и в изменяемом столбце;

v Скопировать данные из существующего столбца в новый (UPDATE);

v Удалить ограничения на изменяемый столбец;

v Выполнить удаление существующего столбца;

v Создать столбец с именем удаленного и новыми характеристиками;

v Скопировать данные из столбца-копии в новый столбец;

v Удалить столбец-копию;

v Выполнить операции по восстановлению ограничений, удаленных в процессе этапа (3).

Добавление ограничений

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

Удаление ограничений

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

Синтаксис команды ALTER TABLE

ALTER TABLE <имя таблицы>

ADD <имя столбца>

ADD <ограничение>

DROP <имя столбца>

DROP CONSTRAINT <ограничение>

ADD <имя столбца> и ADD <ограничение> - имеют такой же синтаксис, что и при создании таблицы;

3.3 Удаление таблиц. Для удаления таблицы предназначена команда DROP TABLE после которой указывается имя удаляемой таблицы.

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

Создание индексов

Индексы создаются либо пользователем с помощью команды CREATE INDEX, либо автоматически при выполнении команды CREATE TABLE.

Для просмотра индексов, определенных для текущей базы данных, используется команда SHOW INDEX, после которой можно указывать имя таблицы – тогда индексы просматриваются для указанной таблицы. Для просмотра конкретного индекса используют команду SHOW INDEX <имя_индекса>.

InterBase автоматически генерирует индексы системного уровня по столбцу или набору столбцов, когда таблицы определяются с конструкцией ограничения PRIMARY KEY, FOREIGN KEY или UNIQUE.

Команда CREATE INDEX создает индекс на одном или нескольких столбцах таблицы.

CREATE [UNIQUE] [ASC][DESC]

INDEX <имя_индекса> ON <название таблицы> (<список полей>);

ASC и DESC задают способ упорядочения данных по возрастанию или по убыванию соответственно.

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

Пример. Создание уникального индекса по идентификатору студента для таблицы student

CREATE UNIQUE ASC

INDEX OD_IND ON STUDENT (STUDENT_ID);

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

4.2 Изменение индекса осуществляется командой

ALTER INDEX <имя индекса> { ACTIVE|INACTIVE }

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

На использование команды ALTER INDEX накладываются некоторые ограничения:

¯ Нельзя выполнить команду ALTER INDEX, если изменяемый индекс используется в данный момент (например командами изменения или выборки);

¯ Для выполнения команды необходимо обладать соответствующими правами.

¯ Команда ALTER INDEX неприменима к индексам, используемым в качестве ограничений логической целостности, определенным, как UNIQUE, PRIMARY KEY, FOREIGN KEY.

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

Восстановление индекса

SET STATISTICS INDEX <имя индекса>;

В таблицах, где число повторений значений ключа индекса значительно меняется (возрастает или уменьшается), периодическая перекомпиляция индекса может значительно ускорить время обработки. Команда SET STATISTICS повторно вычисляет селективность индекса. Индексная селективность рассчитывается исходя из количества различных значений ключа. Результаты размещаются в памяти и используются оптимизатором InterBase для построения плана обработки запроса. Сам индекс при этом не перестраивается.

Удаление индекса

DROP INDEX <имя индекса>;

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

Изменение исключения

ALTER EXCEPTION <имя> ‘сообщение об ошибке’;

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

Удаление исключения

DROP EXCEPTION <имя>;

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

Объявление внешней функции

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

Синтаксис объявления внешней функции:

DECLARE EXTERNAL FUNCTION <имя функции>

[<список типов данных входных параметров>]

RETURNS {<тип данных> [ BY VALUE ] | CSTRING (int)}

[ FREE IT ]

ENTRY_POINT ‘имя функции в библиотеке’

MODULE_NAME ‘имя файла библиотеки’;

Синтаксические контсрукции объявления внешних функций:

Конструкция	Описание
имя функции	Имя UDF для использования в командах SQL; может отличаться от имени (в библиотеке) указанной после слова ENTRY_POINT
список типов данных	Может принимать значение либо <тип данных> либо CSTRING (int)
тип данных	Любой разрешенный в InterBase тип данных, кроме массивов и BLOB. Тип данных входного параметра или возвращаемого значения. Все входные параметры передаются в UDF по ссылке. Возвращаемые значения могут передаваться как по ссылке, так и по значению. Использование элементов массивов запрещено.
RETURNS	Определяет возвращаемое функцией значение
BY VALUE	Указывает на то, что параметр возвращается по значению. Если конструкция пропущена, то значение возвращается по ссылке.
CSTRING (int)	Специальный тип для представления строк, представляющий собой последовательность символов, заканчивающуюся двоичным нулем.
FREE IT	Указывает на необходимость освобождения памяти, выделенной UDF для возвращаемого значения, передаваемого по ссылке. Необходимость для такой конструкции вызвана тем, что запрос памяти производится в UDF, а освобождение выполняется в InterBase.
имя функции в библиотеке	Заключенное в кавычки имя имя функции, как оно записано в библиотеке.
имя файла библиотеки	Спецификация файла, идентифицирующая библиотеку, которая содержит UDF. Текс должен заключаться в кавычках. » Библиотека должна постоянно находиться на сервере; путь должен относиться к местоположению на сервере. » На любой платформе модуль может быть указан без имени пути, если он находится в путь_InterBase/ Lib. » Следует использовать полное имя файла библиотеки, включая расширение, даже если имя пути не указано.

 

 

История развития СУБД.

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

В середине 60-х гг. корпорация IBM разработала первую СУБД, иерархическуюсис