Вводная лекция по INFORMIX. Конспект. < Учебно-справочное пособие по СУБД INFORMIX < Базы данных

Новые книги

Внедрение SAP R/3: Руководство для менеджеров и инженеров
Implementing Sap R/3: The Guide for Business and Technology Managers

Это практическое всеобъемлющие руководство было написано специально для тех, кто выбирает стратегию внедрения SAP в организации. «Внедрение SAP R/3: руководство для менеджеров и инженеров» объясняет, что означает понятие «эпоха ERP», почему информация является одним из ключевых ресурсов предприятия, как SAP способствует росту конкурентоспособности компании, а также преимущества методологии ASAP в планировании и использовании ресурсов при внедрении SAP. Подход к ERP-системам, используемый в данной книге, будет крайне полезен менеджерам и специалистам, которым необходимо представить высшему руководству своих компаний основания для внедрения SAP; кроме того, данная книга будет весьма полезной тем, кто занимается проектами SAP или планирует такой проект в ближайшем будущем. Для тех читателей, кто непосредственно занят в проектах SAP, эта книга станет надежным руководством и поможет внести существенный вклад в развитие проекта.

Яндекс.Книга

Это захватывающая и практически полная история крупнейшей IT-компании России, основанная на десятках авторских интервью с теми, кто строил главный поисковик Рунета начиная с 90-х и заканчивая сегодняшним днем.

Вводная лекция по INFORMIX. Конспект.

Версия для печати

Вводная лекция по INFORMIX. Конспект.

Для начала несколько определений, которые, впрочем, всем известны и ничего не определяют. Понятие "Система Управления Базами Данных" (СУБД), она же DBMS (DataBase Managment System) может означать, по большому счету, все что угодно.
В самом общем случае это собственно база данных, которая предполагает какой либо метод сохранения информации на диске и возможности доступа и манипуляции с нею, и набор программных продуктов, предоставляющий пользователю все допустимые в базе средства работы с данными.
Набор программных средств манипуляции данными СУБД удовлетворяет свойствам полноты (консистентности). Полагаю, что коммерческие варианты СУБД стремятся быть еще и замкнутыми, т.е. самодостаточными, не требующими и не поддающимися расширению.

Архитектура Клиент-Сервер.

Очень многие СУБД разделяют свою работу на два уровня по системе "Клиент-Сервер". Хитрость состоит в том, что не только пользователь, но и программист этого не замечает. Разделение функций его задачи выполняется автоматически системой.

Итак, двухуровневая система "Клиент-Сервер" это:

Клиент - Программа обработки, она же пользовательская, она же прикладная программа. Занимается обычно интерфейсом с пользователем, а всю фактическую работу с базой данных возлагает на плечи БД-сервера.
Сервер Базы Данных - базис (database engine), он же ядро базы данных. Отдельная программа, выполняемая как отдельный процесс. Передает выбранную из базы информацию по межпроцессному каналу клиенту. Именно он, и только он фактически работает с данными, занимается их размещением на диске.
В первый момент может возникнуть вопрос, а зачем такие сложности? Вот несколько соображений в пользу такого подхода.
Представьте, вы работаете в сети, ваша программа обработки идет на одном компьютере, а сама база данных хранится на другом. Тут разделение выглядит совершенно естественным: клиент - ваша программа (точнее, та ее часть, которая отвечает за интерфейс с вами), гонит по сети запросы на обработку самих данных на другой компьютер, а там БД-сервер их прочитывает, выполняет требуемое, и по сети гонит ответы вам. При этом по сети передается только полезная информация.
Другое соображение: постоянно идет работа по совершенствованию самого метода хранения и обработки информации, и если его реализация (т.е. БД-сервер) сменилась, та вам не потребуется перелопачивать и перекомпилировать с новыми библиотеками все свои разработанные программы, а достаточно будет инсталлировать новый БД-сервер взамен старого и перевести свои базы данных в формат нового сервера (применив для этого прилагаемую к нему утилиту). Естественно, все это можно проделать, если новый сервер придерживается тех же правил обмена между ним и пользовательской программой, что и старый, что, впрочем, наверняка имеет место.
Всвязи с СУБД INFORMIX нас, естественно, интересует только одна модель данных - реляционная. Сетевых и иерархических моделей рассматривать здесь я не буду. Можно, конечно, дать строгое определение реляционной модели данных по Э.Ф. Кодду, но ведь ни одну из коммерческих СУБД нельзя назвать реляционной в строгом смысле этого слова.
Основные Объекты Реляционной Базы Данных.

(DATABASE) Реляционная База Данных: это множество прямоугольных таблиц с данными. Никаких дополнительных сведений и ссылок не хранится.

(TABLE) Таблица - прямоугольная таблица, состоящая из СТРОК и СТОЛБЦОВ. Задать таблицу - значит указать, из каких столбцов она состоит. Обращаю внимание поклонников DBase - то, что в DBase называлось базой данных, в INFORMIX называется таблицей.

(ROW) Строка - запись, состоящая из полей - столбцов. В каждом поле сидит его значение, либо значение NULL - "пусто". Строк в таблице может быть сколько угодно. Физический порядок их расположения друг относительно друга не определен.

(COLUMN) Столбец - Каждый столбец в таблице имеет собственные имя и тип.

В INFORMIX допустимы следующие типы столбцов:
```
    INTEGER     SERIAL - автоматический счетчик
    SMALLINT    CHAR(n)        DATE
    FLOAT       DECIMAL(m,n)   DATETIME qualif1 TO qualif2
    REAL        MONEY(m,n)     INTERVAL qualif1 TO qualif2
```
где qualif \in {YEAR,MONTH,DAY,HOUR,MINUTE,SECOND,FRACTION(n)}, возможны и другие типы, в зависимости от реализаций.
Реляционная модель идейно проста - основной ее принцип - "База Данных обеспечивает хранение и выдачу информации из своих прямоугольных таблиц, и ничего не желает знать о логической структуре данных, которую на ней реализовывают." Все логические отношения и связи между разными таблицами вынесены наружу "Исполнителя База Данных" и отданы на откуп программисту. Такой подход позволяет просто и эффективно реализовывать саму базу данных, соответственно и быстродействие и мощность реляционных баз удается держать на весьма высоком уровне.
Физическую целостность базы данных обычно поддерживает сам метод доступа, сервер базы.
Но логическая (внешняя) структура пользовательской базы может быть весьма сложной. Для поддержания целостности логической структуры базы данных в реляционной базе имеется механизм транзакций. Транзакция - это объединение нескольких простых операторов манипулирования данными, которые должны быть выполнены только вместе, а если это не удается, то база вернется в состояние, предшествующее выполнению самого первого из них.

Понятия, Связанные с Реляционной Базой Данных.

Реляционные Методы Манипулирования Таблицами.

Запросы на поиск. Соединение таблиц. Внешнее соединение таблиц.

Представьте, что вам нужно в таблице "КАДРЫ" хранить данные о личном составе предприятия. О каждом человеке желательно помнить его фамилию, зарплату, пол, и т.д., а также название подразделения, в котором он работает. Но название подразделения длинно, самих подразделений немного, зато строк в таблице "КАДРЫ" много. Для экономии места применяется стандартный реляционный метод: в таблице "КАДРЫ" хранится не само название, а только его короткий код, и создается еще одна таблица, с помощью которой мы будем определять название подразделения по его коду. Табличку эту мы, естественно, назовем "ПОДРАЗДЕЛЕНИЯ", и будет в ней всего два столбца: столбец "КОД" и второй "название подразделения". И вот мы подошли к самому главному, что есть в реляционной базе, к "СОЕДИНЕНИЮ ТАБЛИЦ" по значению столбца (оно же соединение по ключу, по коду). Когда нам потребуются данные о человеке по фамилии Иванов, мы захотим увидеть название подразделения в котором он работает, а не малопонятный код. Значит поиск данных об Иванове нужно вести в двух таблицах. Сперва мы найдем в таблице "КАДРЫ" строчку, в которой в столбце ФАМИЛИЯ стоит значение "Иванов", мы возьмем в этой строчке значение кода подразделения, и будем искать в таблице "ПОДРАЗДЕЛЕНИЯ" строку, со значением в столбце КОД равным коду из строки с Ивановым. А найдя мы соединим данные из строки с Ивановым из первой таблицы и из строки с кодом из второй, получив одну, общую строку.

Индексация

Индекс таблицы - это вспомогательный файл, который создается для того, чтобы ускорить выполнение реляционных операций с участием этой таблицы. Индекс строится для определенного столбца (или совокупности столбцов) таблицы. Он состоит из пар вида {Значение столбца, физический адрес соответствующей строки на диске} и отсортирован по значению столбца в порядке возрастания или убывания. Для одной и той же таблицы может существовать несколько индексов. Не следует путать индекс, построенный для совокупности нескольких столбцов таблицы, и несколько различных индексов, построенных для отдельных столбцов.
Если индекс создан, то при выполнении операций с таблицей система будет пользоваться им автоматически.
Перечислим коротко ряд рекомендаций по индексации таблиц.
Индексы бывают уникальные и неуникальные. Если вы создаете уникальный индекс по некоторому столбцу, то система гарантирует, что в данном столбце не будет повторяющихся значений.
Выделяется кластеризованные индексы. При построении таких индексов данные таблицы физически упорядочиваются на диске в соответствии с упорядоченностью строк индекса. Поскольку операционная система поддерживает буферизацию дискового обмена, физически упорядоченные данные оказываются в буферном кэше вместе, можно сказать, "автоматически". Следовательно, скорость обработки запросов возрастает. Для каждой таблицы может существовать только один кластеризованный индекс, что следует из его определения.

Системный Журнал (logfile), он же журнал транзакций.

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

Многопользовательский Режим Обработки Базы Данных.

Блокирование (locking), оно же запирание.

Сервер базы блокирует строки и таблицы во избежание коллизий при записи в одну и ту же строку. Строки блокируются автоматически (неявно). В блокированную строку нельзя писать, но можно смотреть. На время выполнения транзакции все измененные в ней строки блокируются. Можно заблокировать всю таблицу целиком явной командой блокировки. Таблицы можно блокировать не только от записи, но и от просмотра. Программе можно задавать режим:
ждать/ не ждать блокированных строк оператором SET LOCK MODE.

Права Доступа в Базе Данных, которые могут иметь пользователи. На уровне базы данных определены следующие уровни прав:
На уровне таблиц можно давать пользователям (и отбирать у них) следующие привилегии:
SQL - Структурный Язык Запросов.

ANSI (American National Standart Institute) разработал Структурный Язык Запросов (SQL) - Structured Query Language для определения, манипуляции и контролирования данных. Содержит 4 группы операторов.
В SQL выделяются следующие группы операторов:
Язык Программирования 4-го Поколения 4GL.

Включает следующие возможности:
Продукты INFORMIX для Обработки Баз Данных.

Программное обеспечение INFORMIX содержит следующие компоненты:
Оглавление || Вперед