63399

СИСТЕМЫ УПРАВЛЕНИЯ БД: ОБЩИЕ СВЕДЕНИЯ

Лекция

Информатика, кибернетика и программирование

Общие сведения о СУБД Место БД при различной архитектуре вычислительной системы Модели данных Язык описания данных Язык манипулирования данными для реляционной модели SQL Общие сведения о СУБД Первыми СУБД в России начали пользоваться в конце семидесятых годов.

Русский

2014-06-19

683 KB

2 чел.

PAGE   \* MERGEFORMAT 87

V. СИСТЕМЫ УПРАВЛЕНИЯ БД: ОБЩИЕ СВЕДЕНИЯ

Общие сведения о СУБД

Место БД при различной архитектуре вычислительной системы

Модели данных

Язык описания данных

Язык манипулирования данными для реляционной модели – SQL

Общие сведения о СУБД

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

Создавая БД, пользователь стремится упорядочить информацию по различным признакам и быстро извлекать данные с произвольным сочетанием признаков. Сделать это очень трудно, если данные плохо формализованы или не структурированы. Неструктурированными называют данные, записанные, например, в текстовом файле. Формализованные данные – это структурированные данные, представленные, например, в закодированном виде с помощью классификаторов или без них, но записываемых по каким-либо правилам (например, есть, нет).

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

Определим основные понятия, необходимые для построения концептуальной модели БД [http://ru.wikipedia.org/wiki/%D0%91%D0%B0%D0%B7%D0%B0_%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85].

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

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

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

DDL (Data Definition Language) – язык описания данных (ЯОД) позволяет описать базу данных в терминах, принятых в конкретной СУБД.

DML (Data Manipulation Language) – язык манипулирования данными (ЯМД) позволяет управлять данными (выбирать, сортировать, создавать и др.).

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

Модель данных - совокупность структур данных и операций их обработки.

Таблица – основная единица хранения данных БД, состоит из имени таблицы, строк и столбцов.

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

Схема – коллекция объектов БД, содержащая таблицы, индексы, кластеры, представления (виды), журналы репликации, линки, последовательности, синонимы, пакеты, хранимые процедуры, функции, триггеры, библиотеки внешних процедур.

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

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

Атрибут - это столбец с заголовком (именем) и значениями, превращающийся в последующем в поле БД, имеющий имя, тип и другие свойства.

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

Кортеж – строка таблицы, превращающаяся в последующем в запись файла БД.

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

Процедура – это набор SQL команд, который выполняет определенную задачу.

Репликация - процесс синхронизации в распределенной БД таблиц и представлений, на основе которых они созданы.

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

Триггер – блок инструкций SQL в виде процедур, которые могут автоматически запускаться при выполнении команд INSERT, UPDATE или DELETE.

Функция – это совокупность SQL или PL/SQL-команд, которая реализует определенную задачу (например, статистические функции).

Хранимая процедура – это предопределенный SQL-запрос, хранимый в системе.

Атрибут - элементарная единица логической организации данных. Для описания атрибута используются следующие характеристики:

имя – формализованное обозначение атрибута;

тип - формат хранения атрибута (символьный, числовой, дата);

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

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

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

Запись - совокупность логически связанных атрибутов.

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

Индекс - это упорядоченный список значений и ссылок на записи, в которых хранятся эти значения. 

Таблица - совокупность экземпляров записей одной структуры.

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

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

Таблица 1 - Описание логической структуры записи файла БД

Имя файла

Атрибут

Признак ключа

Формат атрибута

Имя (обозначение)

Наименование

Тип

Длина

Точность

name

Краткое название организации

ПК

char

15

0

Имя n

…..

…..

….

….

Создание БД на основе СУБД включает:

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

Место БД при различной архитектуре вычислительной системы

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

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

Клиент

Клиент

  1.  

Рисунок 1 - Централизованный вариант (персональный)

Файл-сервер. При такой архитектуре предполагается выделение одной из машин сети для хранения БД (сервер файлов), которая совместно используется всеми пользователями. Все другие машины сети выполняют функции рабочих станций, с помощью которых поддерживается доступ пользователей к БД. Файлы БД в соответствии с пользовательскими запросами передаются на рабочие станции, где в основном и производится обработка. Пользователи могут создавать также на рабочих станциях локальные БД, которые используются ими монопольно. Концепция файл-сервер условно отображена на рис.2. Ярким примером такой архитектуры является возможность хранения БД ACCESS на файле сервере. Производительность такой архитектуры зависит от компьютера пользователя, значительно загружается сеть для передачи данных. При большой интенсивности доступа к одним и тем же данным производительность информационной системы падает.


Рисунок 2 - Архитектура файл - сервер

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

Рисунок 3 - Клиент серверная архитектура

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

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

Рисунок 4 - Трехуровневая архитектура

  1.  Модели данных

Основными моделями данных являются иерархическая, сетевая, реляционная, постреляционная, многомерная модели данных или комбинация этих моделей. Модель данных представляет собой множество структур данных, ограничений целостности и операций манипулирования данными [1,2,4]. С помощью модели данных могут быть представлены объекты предметной области и взаимосвязи между ними.

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

Иерархическая модель данных стала применяться в шестидесятых годах, строится по принципу иерархии типов объектов, т. е. один тип объекта является главным, а остальные, находящиеся на низших уровнях иерархии,— подчиненными. Иерархическая модель данных организует данные в виде иерархической древовидной структуры. Эта структура строится из узлов и ветвей. Узел представляет собой совокупность атрибутов данных, описывающих некоторый объект. Наивысший узел в иерархической древовидной структуре называется корнем. Зависимые узлы располагаются на более низких уровнях дерева. Зависимые узлы могут добавляться как в вертикальном, так и в горизонтальном направлении без всяких ограничений. Связи (соединения) между узлами уникальны, Поэтому иерархическая модель данных обеспечивает только линейные пути доступа к данным и между главными и подчиненными типами объекта устанавливается линейная взаимосвязь “один ко многим». Каждый экземпляр корневого узла образует начало записи логической БД, т.е. иерархическая БД состоит из нескольких деревьев. Примером такой модели данных является описание комплектующих автомобиля (ручки, окна, болты, др.), рис.5. Примером иерархической СУБД является СУБД «Ока».

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

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

Рисунок 5 - Фрагмент иерархической модели данных

В сетевой модели данных (рис.6), которая начала применяться в начале восьмидесятых годов, понятия главного и подчиненных объектов несколько расширены. Любой объект может быть и главным, и подчиненным (в сетевой модели главный объект обозначается термином «владелец набора», а подчиненный — термином «член набора»). Один и тот же объект может одновременно, выступать и в роли владельца, и в роли члена набора. Это означает, что каждый объект может участвовать в любом числе взаимосвязей. БД состоит из нескольких областей. Область содержит записи. В свою очередь запись состоит из полей, а набор, который объединяет записи, может размещаться в одной или нескольких областях. Достоинство сетевой модели это простота реализации часто встречающихся в реальном мире взаимосвязей, закладываемых в БД. Основной недостаток сетевой модели состоит в сложности управления данными, в т.ч и возможная потеря независимости данных при реорганизации БД. Сетевая модель использовалась в СУБД СЕТОР.

Рисунок 6 - Фрагмент сетевой БД

Реляционная модель была предложена в семидесятых годах, но получила широкое распространение только в середине восьмидесятых годов. В реляционной модели данных (рис.7) объекты и взаимосвязи между ними представляются с помощью таблиц. Взаимосвязи рассматриваются в качестве объектов (таблиц связей). Каждая таблица представляет один объект. В терминологии реляционной модели таблица называется отношением. Каждый столбец в таблице является атрибутом. Объекты (сущности) предметной области отображаются двумерной таблицей с заголовками, состоящими из имени и типа сущности. Строки такой таблицы представляют собой перечень атрибутов сущности. Назначается один или несколько атрибутов первичным ключом для поиска информации. Значения в столбце выделяются из домена, т.е. домен суть множество значений, которые может принимать некоторый атрибут. Для каждого атрибута всех таблиц фиксирован тип и длина данных. Соединение данных из разных таблиц обеспечивается операторами языка SQL.

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

Рисунок 7 – Фрагмент реляционной БД

Реляционными СУБД являются DB2, Oracle, Paradox, Access, MySQL и др.

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

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

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

Правила Кодда, которые необходимо использовать при создании реляционной БД:

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

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

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

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

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

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

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

Пример нормализации в 1НФ. Перечень возможных атрибутов, характеризующих заказ, включает дату заказа, ФИО клиента, телефон клиента, номер счета, название товара, цена, производитель, индекс фирмы производителя, адрес, количество товара, оплата. Поскольку один клиент может в течение одного дня сделать несколько заказов, таблица может содержать одинаковые строки. На один и тот же товар может поступить несколько заказов, и, наконец, фирма производитель может поставлять несколько товаров. Таблицы могут содержать следующие данные, табл.2, 3:

Таблица 2 - Описание заказа

Дата заказа

ФИО

Телефон

Счет

Наименование товара

01-08-2009

Иванов И.И.

1234567

1234567890123456789

Часы

01-08-2009

Сидоров И.И.

7654321

2345678901234567890

Ручки

02-08-2009

Петров П.П.

2345678

3456789012345678901

Карандаши

03-08-2009

Владимиров В.В.

3456789

4567890123456789012

Тетрадки  

Таблица 3 - Описание товара

Цена

Производитель

Почтовый индекс

Адрес

Количество

Оплата

350.00

«Восток»

123456

Королева, 6

85

Да

15.00

«Канцтовары»

234567

Гагарина, 24

74

5.00

«Канцтовары»

234567

Гагарина, 24

25

25.00

«Канцтовары»

234567

Гагарина, 24

36

Да

Приведем таблицу к 1НФ. Выделим следующие сущности: заказы, клиенты, товары, производители. Добавим в таблицу «Заказ» поле «Номер заказа», что позволит однозначно идентифицировать каждый из заказов. Таблица содержит три группы повторяющихся атрибутов. Атрибуты, характеризующие клиента «ФИО», «Телефон», «Счет», вынесем в таблицу «Клиенты». Атрибуты, характеризующие товар «Наименование товара» и «Цена», вынесем в таблицу «Товары». Атрибуты, характеризующие производителя «Производитель», «Почтовый индекс», «Адрес» вынесем в таблицу «Производители».

В таблицу «Клиенты» добавим новый атрибуте «Номер клиента», который будет однозначно идентифицировать каждую запись таблицы, в таблицу «Товары» - «Номер товара», в таблицу «Производители» - «Номер производителя».

Для организации связи между таблицами по совпадающим атрибутам, добавим в таблицу «Заказы» поля «Номер клиента» и «Номер товара», а в таблицу «Товары» - «Номер производителя» для организации связи.

Таким образом, данные из таблиц 2 и 3 примут следующий вид - таблицы 4-7.

Таблица 4 – Описание заказа

Заказ

Дата

Идентификатор клиента

Идентификатор товара

Идентификатор производителя

Количество товаров

Оплата

1

01-08-2009

1

1

1

85

Да

2

01-08-2009

1

2

2

74

3

02-08-2009

2

3

2

25

4

03-08-2009

3

4

2

36

Да

Таблица 5 – Описание клиентов

Идентификатор клиента

ФИО

Телефон

Счет

1

Иванов И.И.

1234567

1234567890123456789

2

Сидоров И.И.

7654321

2345678901234567890

3

Петров П.П.

2345678

3456789012345678901

4

Владимиров В.В.

3456789

4567890123456789012

Таблица 6 – Описание товара

Идентификатор товара

Наименование товара

Цена

Идентификатор производителя

1

Часы

350.00

1

2

Ручки

15.00

2

3

Карандаши

5.00

2

4

Тетрадки  

25.00

2

Таблица 7 – Описание производителей

Идентификатор производителя

Производитель

Почтовый индекс

Адрес

1

«Восток»

123456

Королева, 6

2

«Канцтовары»

234567

Гагарина, 24

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

Пример нормализации во 2НФ. Перечень возможных атрибутов, характеризующих проекты, включает название и код проекта, цель проекта, дата начала и окончания проекта, руководитель, телефон. Пусть таблица имеет составной ключ, который формируется по двум атрибутам: «Код проекта», «Код руководителя проекта». Атрибуты «Название», «Цель», «Дата начала, окончания», «Руководитель», «Телефон» являются частично зависимыми. Атрибуты «Название», «Цель», «Дата начала и окончания» зависят только от «Проекта», но не зависят от «Руководителя», т.е. однозначно идентифицируется частью ключа, а не полным набором ключевых полей. Аналогично поля «Руководитель» и «Телефон» зависят только от «Руководителя». Для приведения к 2НФ необходимо вынести все частично зависимые поля в отдельную таблицу; определить ключевые поля; установить отношения между таблицами 8 и 9.

Таблица 8 – Сведения о проектах

Код проекта

Название

Цель

Дата начала

Дата окончания

Руководитель

1

Балтика

Исследование климата

01-01-1990

31-12-1995

1

2

Баренц

Проводка судов

01-01-1996

31-12-1999

2

Таблица 9 – Сведения о руководителях проектов

Код руководителя

ФИО

Телефон

1

Иванов И.И.

1234567

2

Петров П.П.

2345678

Третья нормальная форма (3НФ). Таблица, находящаяся в третьей нормальной форме должна отвечать всем требованиям 2НФ, а также ни одно из не ключевых полей не идентифицируется при помощи другого не ключевого поля. Другими словами в таблице нет полей, которые не зависят от ключа. Рассмотрим пример нормализации в 3НФ, перечень возможных атрибутов, характеризующих заказы и менеджеров, включает код заказа, покупатель, дата продажи, менеджер (табл.10).

Таблица 10 – Сведения о заказах

Код заказа

Покупатель

Дата продажи

Менеджер

Код менеджера

1

Иванов И.И.

01-11-2007

Сидоров С.С,

1

2

Петров П.П.

01-11-2007

Михайлов М.М.

2

Таблица не находится в 3НФ, т.к. не ключевое поле «Менеджер» зависит от другого не ключевого поля «Код менеджера». Для приведения к 3НФ необходимо поле «Менеджер» вынести в отдельную таблицу. Таким образом, в результате создается две таблицы 11 и 12.

Таблица 11 – Сведения о заказах

Код заказа

Покупатель

Дата продажи

Код Менеджера

1

Иванов И.И.

01-11-2007

1

2

Петров П.П.

01-11-2007

2

Таблица 12 – Сведения о менеджерах

Код Менеджера

Менеджер

1

Сидоров С.С,

2

Михайлов М.М.

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

  •  один к одному (1:1);
  •  один ко многим (1:М);
  •  многие ко многим (М:М).

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

СТУДЕНТЫ (Номер, Фамилия, Имя, Отчество, Пол, Дата рождения. Группа)

СЕССИЯ (Номер, Оценка_1, Оценка_2, Оценка_З, Оценка_4, Результат)

СТИПЕНДИЯ (Результат, Процент)

ПРЕПОДАВАТЕЛЬ (Код преподавателя, Фамилия, Имя, Отчество)

Связь о один к одному (1:1) предполагает, что в каждый момент времени одному экземпляру информационного объекта А соответствует не более одного экземпляра информационного объекта В и наоборот.

А1  В1

А2 В2

А3 В3

Примером связи 1:1 может служить связь между информационными объектами СТУДЕНТ (ФИО, группа, курс, др.) и СЕССИЯ (ФИО, Номер семестра, Предмет_1, Предмет_2, …). Каждый студент имеет определенный набор экзаменационных оценок в сессию.

При связи один ко многим (1:М) одному экземпляру информационного объекта А соответствует 0, 1 или более экземпляров объекта В, но каждый экземпляр объекта В связан не более чем с 1 экземпляром объекта А.

А1 В1, B2

А2 В3

А3 В4, B5

Примером связи 1:М служит связь между информационными объектами «СТИПЕНДИЯ» (ФИО, Размер) и «СЕССИЯ» (ФИО, Номер семестра, Предмет_1, Предмет_2, …, Сумма баллов). Установленный размер стипендий по результатам сдачи сессии может повторяться многократно для различных студентов.

Связь многие ко многим (М:М) предполагает, что в каждый момент времени одному экземпляру информационного объекта А соответствует 0, 1 или более экземпляров объекта В и наоборот.

А1 <  В1

А2 < В2

А3< В3

Примером данного отношения служит связь между информационными объектами «СТУДЕНТ» и «ПРЕПОДАВАТЕЛЬ». Один студент обучается у многих преподавателей, один преподаватель обучает многих студентов.

Все связи должны быть описаны. Если число связанных таблиц превышает три, то следует внимательно посмотреть на схему БД и по возможности постараться уменьшить число связанных таблиц до трех.

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

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

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

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

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

Эта модель используются в СУБД Oracle, Informix, PostgreSQL.

Многомерная модель, рис.8. Моделью данных является многомерный куб, где на измерениях определены некоторые иерархии, а в клетках этого куба находятся числовые значения. Операции извлечения данных из такого куба описываются в терминах поворотов, срезов, и иерархического "схлопывания" измерений с агрегированием значений (суммирование, взятие среднего и др.). Эта схема хорошо ложится на табличную организацию данных. Наиболее известный программный продукт этого класса - это Oracle Express Server.

Рисунок 8 – Схема перехода от реляционной модели к многомерной

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

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

Slice and Dice (нарезка на кубики и ломтики) - это термин, использующийся для описания функции сложного анализа данных, обеспечиваемой средствами OLAP выборка данных (продольные и поперечные, плоскостные и объемные срезы) из многомерного куба с заданными значениями и заданным взаимным расположением измерений, при котором пользователь обычно использует операции вращения концептуального куба данных и детализации/агрегирования данных.

Изменение порядка представления измерений, применяемое при двухмерном представлении данных, называется вращением (Rotate, Pivot, пивотинг). Эта операция обеспечивает возможность визуализации данных в форме, наиболее комфортной для их восприятия. Операция вращения может заключаться в перестановке местами строк и столбцов таблицы или перемещении интересующих измерений в столбцы или строки создаваемого отчета, что позволяет придавать ему желаемый вид. Кроме того, вращением куба данных является перемещение вне табличных измерений на место измерений, представленных на отображаемой странице, и, наоборот (при этом вне табличное измерение становится новым измерением строки или измерением столбца). Вращением можно изменить отчета с расположенным по горизонтали измерением "Время" и измерением "Компьютеры", расположенным по вертикали, в отчет, у которого по горизонтали представлено измерение "Время", а по вертикали - измерение "География".

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

В процессе анализа пользователь не только работает с различными срезами данных и выполняет их вращение. Одним из часто встречающихся способов манипулирования данными является операция агрегации (Drill Up) -переход от детализированных к агрегированным данным. С точки зрения пользователя, Подразделение, Фирма, Регион, Страна являются точно такими же измерениями, как и Время. Но каждое из них соответствует новому, более высокому уровню агрегации значений показателя Объем продаж.  

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

Достоинствами многомерной модели данных является возможность сведения близких сущностей в одну таблицу, например, сведения о комплектующих компьютера, БД классификаторов и др. Примеры многомерных структур для хранения кодификаторов даны в табл.16 (исходные таблицы – табл.14-15), табл.16 – многомерная структура, временных рядов – табл.17-18, сеточных данных – табл.19-21.

Таблица 13 - Страны                         Таблица 14 - Ведомства                       Таблица 15 - Организации

Код

Значение

Код

Значение

Код

Значение

RU

Россия

1

МИД

НЦУКС

Нац. центр управл.

BU

Болгария

2

МЧС

ВНИИГОЧС

Ин-т ГО и ЧС

….

….

….

….

….

……………

Таблица 16 - Многомерная структура хранения классификаторов

Идентификатор классификатора

Код

Значение

1

RU

Россия

1

BU

Болгария

2

1

МИД

2

2

МЧС

3

НЦУКС

Национальный центр управления в кризисных ситуациях

3

ВНИИГОЧС

Ин-т ГО и ЧС

Таблица 17 - Сведения о временном ряде

ID_временного ряда

Широта

Долгота

Дата начала ряда

Дата окончания ряда

Модель

Параметр

Автор

Таблица 18 - Временной ряд (матрица)

ID_временного ряда

Дата

Значение

Таблица 19 - Сведения о сетке

ID_сетки

Широта

Долгота

Широта

Долгота

Дата начала

Дата окончания

Автор

Модель

Таблица 20 - Сведения о поле

ID_сетки

ID_поля

Дата

Время

Параметр

Таблица 21 - Поле

ID_сетки

ID_поля

Широта

Долгота

Значение

На основе многомерной модели данных можно создать универсальную модель данных (УМД). Эта модель рассмотрена в разделе «Оптимизация». Основная идея создания УМД заключается в том, что все таблицы БД имеют одинаковую структуру данных (трипл) – идентификатор записи, имя атрибута и значение. То есть атомарной единицей хранения данных здесь является значение отдельного атрибута. Для упрощения структуры данных каждый выделенный объект БД представляется в виде метаданных – сведений об объекте и сведений о его жизненном цикле.

Язык описания данных

Во всех СУБД имеются средства описания данных. В настоящее время в большинстве СУБД эти средства включаются в язык SQL. В некоторых СУБД язык описания данных существует отдельно. Например, в ГУ «ВНИИГМИ-МЦД» на основе концепций и предложений КОДАСИЛ (Ассоциация по языкам систем обработки данных) [3] разработан и применяется уже почти 35 лет Язык описания гидрометеорологических данных (ЯОД).

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

- Элементы - наименьшие неделимые единицы данных;

- Группы - совокупность нескольких элементов или других (внутренних) групп.

Имеются следующие типы групп:

GRE - простая неповторяющаяся группа элементов;

GRP - повторяющаяся группа с индексами и с фиксированным числом экземпляров;

GRV - повторяющаяся группа с одним индексом и с переменным числом экземпляров;

GRK - повторяющаяся группа с ключами и с переменным числом экземпляров;

GRR - неповторяющаяся группа, состоящая из переменного числа элементов из некоторого полного списка элементов, причем имя элемента идентифицируются ссылками на этот список.

Элементы бывают следующих типов:

KEY - ключ записи или группы;

IND - индекс записи или группы;

MRC - вид записи;

MIT - основной элемент;

CHA - характеристика основного элемента;

CNT - счетчик экземпляров группы GRK, GRV;

LNG - длина экземпляра записи, группы GRK, GRR;

REF - ссылка на список элементов группы GRR.

Язык выполняет три основных функции:

  •  служит стандартом хранения данных на сменных носителях в Государственном фонде данных по гидрометеорологии. Использование ЯОД как средства конструирования и описания форматов данных позволяет достичь единства в собрании разнообразных данных весьма большого объема, что очень важно как при обслуживании пользователей, так и долговременном (бессрочном) хранении. При появлении новых технических носителей данные в форматах ЯОД переписываются на новые носители с меньшими затратами труда;
  •  используется в качестве средства обмена данными. Наличие формализованного описания структуры данных позволяет достичь большего взаимопонимания между участниками обмена и избежать различных недоразумений. Хранение отдельного файла с описанием данных позволяет пользователям заранее ознакомиться с обменными структурами данных.
  •  является входным языком системы управления данными АИСОРИ, которая имеет разнообразные средства работы с данными в форматах ЯОД для различных пользователей - разработчиков БД, прикладных программистов и конечных пользователей.
  1.  Язык манипулирования данными для реляционной модели – SQL

Для манипулирования данными созданы специальные языки, позволяющие реализовать все операции реляционной алгебры. Среди них наиболее распространенным является язык SQL (Structured Query Language – структурированный язык запросов) [2]. Язык SQL ориентирован на реляционные БД. Это язык высокого уровня, позволяющий с помощью единственного запроса соединять несколько таблиц в одну временную таблицу, вырезать требуемые строки и столбцы, т.е. выполнять операции селекции и проекции данных. Язык запросов SQL в стандарте ANSI 92 имеет множество расширений к этому стандарту. Не все СУБД поддерживают этот стандарт в полном объеме.

Команды SQL бывают интерактивными и вложенными. Интерактивный SQL используется для функционирования непосредственно в БД. Вложенный SQL состоит из команд SQL, помещённых внутри программ, которые обычно написаны на алгоритмических языках (типа Си, ПАСКАЛЬ, Java, др.). Это делает такие программы более мощными и эффективными.

Интерактивный и вложенный SQL имеют разделы:

DDL (Язык Определения Данных) - так называемый Язык Описания Схемы в ANSI - состоит из команд, которые создают объекты (таблицы, индексы, просмотры и так далее) в БД.

DML (Язык Манипулирования Данными) это набор команд, которые определяют, какие значения представлены в таблицах в любой момент времени.

DCD (Язык Управления Данными) состоит из средств, которые определяют, разрешить ли пользователю выполнять определённые действия или нет.

Определение типов данных является основной областью, в которой большинство коммерческих программ БД и официальный стандарт SQL не всегда совпадают. ANSI SQL-стандарт распознаёт только форматы типа text и number, в то время как большинство коммерческих программ используют и специальные типы, такие как DATA и TIME.

Поле типа CHAR имеет длину, определяемую максимальным числом символов, которые могут быть введены в это поле. Большая часть СУБД также имеют нестандартный тип, называемый VARCHAR, который является текстовой строкой и может иметь любую длину до определённого реализацией максимума (обычно 254 символа). Значения CHARACTER и VARCHAR включаются в одиночные кавычки как 'текст'. Различие между CHAR и VARCHAR в том, что CHAR должен резервировать достаточное количество памяти для максимальной длины строки, а VARCHAR распределяет память по мере необходимости. Символьные типы состоят из всех печатных символов, включая числа. Символьные значения сохраняются в компьютере как двоичные значения, но показываются пользователю как печатный текст. Преобразование выполняется по формату, определяемому СУБД.

Некоторые СУБД поддерживают такие типы как, например, MONEY и BINARY. В табл. 22 представлены типы данных, поддерживаемые сервером MS SQL.

Таблица 22 - Типы данных MS SQL Server

Типы данных

Описание

Bigint (int 8)

Целый

Binary (n)

Двоичный

Bit

Битовый

Character (синоним char)

Текстовой  

Character varying (синоним varchar)

Текстовой, на который отводится число хранимых байт по необходимости

Datetime

Дата время

Decimal (numeric, dec)

Числовой

Double precision

С двойной точностью

Float

С плавающей точкой

Image

Изображение

Integer (int 4) (синоним:int)

Целый

Money

Денежный

National character (синоним: nchar)

Национальные  символы

national character varying (синоним: nvarchar)

национальные символы

Smalldatetime

Дата, время

Smallint (int 2)

Целый

Smallmoney

Денежный

Uniqueidentifier

Уникальный идентификатор

Varbinary (n)

Для хранения двоичных файлов

Команды состоят из одной или более логических частей, называемых предложениями. Предложения состоят из ключевых слов и аргументов. Например, предложения, "FROM Salespeope" и "WHERE city = London". Аргументы завершают или изменяют значение предложения. В примерах выше, Salespeople - аргумент, а FROM - ключевое слово. Аналогично " city = London " - аргумент предложения WHERE.

Объекты это структуры БД, которым даны имена и которые сохраняются в памяти. Сюда относятся базовые таблицы, представления и индексы.

Квадратные скобки ( [ ] ) указывают части, которые могут не использоваться, а многоточия (...) указывают, что всё предшествующее может повторяться любое число раз.

Операторы SQL для управления соединениями. В эту группу входят операторы CONNECT, SET CONNECTION и DISCONNECT.

Оператор CONNECT определяется следующими синтаксическими правилами:

CONNECT TO connection_target

connection_target ::= SQL_server_name

                       [ AS connection_name ]

                       [ USER connection_user_name ]

                  DEFAULT

Здесь SQL_server_name - это литерально заданная символьная строка, идентифицирующая сервер, к которому требуется подключиться. В необязательном разделе AS указываемое имя (connection_name) выступает в роли временного имени соединения, которое впоследствии может быть использовано в операторах SET CONNECTION и DISCONNECT. Если в операторе CONNECT раздел AS не содержится, то по умолчанию connection_name совпадает с SQL_server_name.

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

Определение схемы:

Create Schema <DDD>

Authorization - <Name>

Определение таблиц включает:

  •  присвоение имени;
  •  определение типа данных (Integer - целое; Numeric - число; Decimal - десятичное; Real - действительное; Float - с плавающей запятой; Character; Character varying - символьное; Bit - двоичное; Date - дата);
  •  определение полей с ограничительными условиями;
  •  определение ограничительных условий на таблицу.

Создание таблицы:

Create TABLE Name_table1 (

Worker_ID  Int (5)  Primary key

Worker_name  Character (12)

City   Character (12)

birth_day   Date

)

Create TABLE Name_table2  (……)

Команда SELECT – выборка, самая часто используемая команда, с помощью её идет выбор данных из таблицы. Запроса с применением SELECT выглядит с.о.:

SELECT Worker_ID, Worker_name, city, birth_day FROM Name_table1;

Такой запрос выведет из таблицы Name_table1 все значения столбцов указанных через запятую после команды SELECT. Также, можно выводить все столбцы одним символом - (*), т.е. запрос SELECT * FROM Name_table1;  выведет все данные из таблицы.

Структура команды SELECT следующая:

SELECT {Имена столбцов, которые необходимо вывести в запросе, записываются через запятую} FROM {имя таблицы в базе данных} - это простейший вид запроса. Существуют дополнительные команды для удобства извлечения данных.

SELECT name_1 FROM Name_table1 WHERE name_2 = 'XXXX'

Операторы сравнения: =, >, <, <=, >=

Булевы операции: AND, OR, NOT

WERE name_3 BETWEEN 10 and 15

WERE name_4 LIKE (''AAA%')

N_date + interval '14' DAY

N_date + interval '7' * Num_weeks    (дата = текущая дата плюс 7 умноженное на число недель)

Многотабличные запросы:

SELECT name_поля FROM Name_table1, Name_table2  WHERE Name_table1.Worker_ID = Name_table2.Worker_ID  Name_Id=435

Результат: объединение полей двух таблиц при условии Name_Id = 435.

Встроенные функции: SUM, AVG, COUNT, MAX, МIN

SELECT max (Name_1), Min (Name_2)

From Name_table1

Where Name_3=15

Подзапросы:

SELECT Name_1 FROM Name_table1  WHERE Name_3 = or > 

(SELECT max (Name_2)

From Name_table1)

Операции реляционной алгебры:

UNION – объединение таблиц,

INTERSECT - пересечение,

EXCEPT - разница.

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

(SELECT * FROM (TABLE Name_table1 UNION TABLE Name_table2)

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

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

INSERT – вставка;

UPDATE - обновление, модификация;

DELETEудаление.

INSERT INTO users_base (user_name, city, birth_day) VALUES (‘Александр’, ‘Ростов’, ’20.06.1991’);

Команду INSERT можно использовать для вставки данных из другой таблицы:

INSERT INTO Name_Table_2  

 SELECT Name_1, Name_3, Name_4

From Name_Table_1

 WERE Name_5=3

UPDATE users_base SET user_name = ‘Алексей’;

Кавычки в значении редактируемого атрибута ставятся в том случае если значение имеет string формат, если это числовое значение и столбец не привязан к типу данных varchar и любых других строковых типов, то кавычки не имеют смысла.

DELETE FROM users_base WHERE user_name = ‘Василий’;

Команда DELETE удаляет строку целиком, определяет строку по ключевому слову WHERE. Этот запрос удалит все строки, в которых значение столбца user_name=Василий.

Совместное использование SQL c традиционными языками программирования (Си, Паскаль, др.)

OPEN File_1

EXEC SQL

DECLARE File_1

FOR

SELECT *

FROM Table_1

 WERE Name_2= nn

END-EXEC

CLOSE File_1

Выполнение запроса можно разделить на три фазы. Первая фаза это компиляция или разбор (parse) запроса, вторая - подстановка значений переменных (bind), и третья выборка результатов (fetch). Во время компиляции SQL запрос преобразуется во внутреннее представление в те коды, которые воспринимаются СУБД. СУБД выполняет следующие действия:

  •  просматривает словарь данных и выполняет проверку прав доступа. Для этого СУБД генерирует несколько SQL запросов, которые называются рекурсивными запросами (recursive queries), с помощью который проверяет, имеет ли данный пользователь право доступа к указанному столбцу и т.д.
  •  оптимизирует запрос. Здесь выполняется та оптимизация, которая вызвана обращением к представлениям (view) и выполнением подзапросов.

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

Вторая фаза, фаза подстановки (bind), выполняется после компиляции запроса. Во время этой фазы выполняется подстановка значения переменных в запрос. Например, при обработке запроса:

SELECT 'x' FROM person WHERE name = :1

значение некоей переменной 1 будет подставлено в запрос по адресу, зарезервированному указателем :1.

Определения представления данных - окно, через которое видна часть БД (из одной или нескольких таблиц)

CREATE VIEW Table_V

AS SELECT Name_2, Name_3, Name_4, Name_5

FROM Table_1

Критерии, функции, условия

WHERE- предложение команды SELECT и других команд, которое позволяет устанавливать предикаты, условие которых может быть или верным или неверным для любой строки таблицы. Команда извлекает только те строки из таблицы, для которых такое утверждение верно. Пример:

SELECT id, city, birth_day FROM users_base WHERE user_name = ‘Алексей’;

такой запрос выведет только те строки, которые будут соответствовать условию WHERE.

ORDER BY - условие для сортировки выбранных строк. Имеет два критерия ASC и DESC. ASC (сортировка от А до Я или от 0 до 9). DESC (противоположно от ASC). Пример:

SELECT id, city, birth_day FROM users_base ORDER BY user_name ASC;

Это условие можно использовать совместно с условием WHERE. Пример:

SELECT id, city, birth_day FROM users_base WHERE user_name = ‘АлексейORDER BY id ASC;

DISTINCT - аргумент, который устраняет двойные значения из предложения SELECT. То есть если имеются повторяющиеся значения в столбце, допустим, user_name, то DISTINCT выведет только одно, например, если в БД есть два человека по имени ‘Алексей’, то запрос с использованием функции DISTINCT выведет только одно значение, которое встретит первым. Пример:

SELECT DISTINCT user_name FROM users_base;

AND - берет два Буля (в форме A AND B) как аргументы и оценивает их по отношению к истине, верны ли они оба. Пример:

SELECT * FROM users_base WHERE city = ‘Ростов’ AND user_name = ‘Александр’;

OR - берет два Буля (в форме A OR B) как аргументы и оценивает на правильность, верен ли один из них. Пример:

SELECT * FROM users_base WHERE city = ‘Ростов’ OR user_name = ‘Александр’;

NOT - берет одиночный Булев (в форме NOT A) как аргументы и заменяет его значение с неверного на верное или верное на неверное. Пример:

SELECT * FROM users_base WHERE city = ‘Ростов’ OR NOT user_name = ‘Александр’;

IN - определяет набор значений, в которое данное значение может или не может быть включено. Пример:

SELECT * FROM users_base WHERE city IN (‘Владивосток’, ‘Ростов’);

Between - похож на оператор IN, определяет диапазон, значения которого должны уменьшаться, что делает предикат верным. Пример:

SELECT * FROM users_base  WHERE id BETWEEN 1 AND 10;

COUNTвыводит количество строк. Пример:

SELECT COUNT (*) FROM users_base ;

SELECT COUNT (DISTINCT user_name) FROM users_base;

SUM - производит арифметическую сумму всех выбранных значений данного поля.
SELECT SUM (id) FROM users_base.

AVG - производит усреднение всех выбранных значений данного поля. Пример:

SELECT AVG (id) FROM users_base ;

MAX - производит наибольшее из всех выбранных значений данного поля.

MIN - производит наименьшее из всех выбранных значений данного поля.

Оператор EXISTS может быть полезен для вовлечения внешних ключей (foreign keys). В следующем примере идет проверка, имеет ли значение атрибута 'fred the 45' какое-либо задание. Первый вариант:

SELECT distinct 'x' FROM job WHERE name = 'fred the 45'

Во втором варианте используем оператор EXISTS и получаем уменьшение времени обработки почти в два раза.

SELECT 'x' FROM dual WHERE exists
(
SELECT 'x' FROM job where name = 'fred the 45')

Причина ускорения обработки состоит в том, что ядро СУБД остановится после того, как найдено хотя бы одно совпадение name = 'fred the 45'. Поэтому СУБД не будет просматривать всю таблицу целиком.

Эффективность операторов EXISTS и IN зависит от количества данных в каждой из таблиц, задействованных в запросе. В запросе с использованием IN управляющей таблицей является подзапрос, указанный в IN(), основной запрос повторяется для каждой строки возвращаемой подзапросом в IN(). В запросе с использованием EXISTS наоборот, управляющим является основной запрос, и подзапрос, указанный в EXISTS() повторяется для каждой строки, выбираемой в основном запросе. Таким образом, если подзапрос возвращает малое количество строк, а основной запрос возвращает большое количество строк, причем для каждой из строк полученных в подзапросе, то следует использовать оператор IN.

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

Ключевые слова следует писать ПРОПИСНЫМИ БУКВАМИ. Перечисленные ниже ключевые слова следует писать с новой строки с одной и той же позиции:

         SELECT
         INTO
         FROM
         WHERE
         AND/OR
         GROUP BY
         HAVING
         CONNECT BY
         FOR UPDATE OF
         ORDER BY

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

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

Выводы

Рассмотрены возможные варианты эксплуатации БД при различной архитектуре вычислительной системы. Представлено описание основных моделей данных (иерархическая, сетевая, реляционная, объектно-ориентированная, многомерная). Дано описание основных команд языка манипулирования данными для реляционной модели – SQL.

Список литературы

  1.  Когаловский М.Р.Технология баз данных на персональных ЭВМ. - М.: Финансы и статистика, 1992. - 224с.
  2.  Кренке Д. Теория и практика построения БД. — Изд. 9-е Спб.: Питер, 2004. — 864 с.
  3.  Олле Т. Предложения КОДАСИЛ по управлению БД. - М.: Мир, 1981. – 286 с.
  4.  Системы управления базами данных и знаний: Справ. изд./А.Н.Наумов, А.М.Вендров, В.К.Иванов и др., Под ред. А.Н.Наумова - М.: финансы и статистика, 1991 - 352 с.

Перечень вопросов для самопроверки

  1.  Какие СУБД Вы знаете?
  2.  Какие команды SQL Вы знаете?
  3.  Нарисуйте место БД в различных архитектурах вычислительных систем.
  4.  Какие модели данных Вы знаете?
  5.  Назовите основные способы описания данных.


 

А также другие работы, которые могут Вас заинтересовать

10515. Схема коммерческих отношений в трамповом судоходстве 52.5 KB
  Схема коммерческих отношений в трамповом судоходстве. Общая схема: Стивидорная компания чаще называется оператор терминала. Договор со стивидорной компанией заключает продавец лучше знает свойства груза. Договор с агентом заключается судовладе...
10516. Особенности работы агента в трамповом судоходстве 51 KB
  На капитана возложен контроль за качеством агентского обслуживания судна. Во всех спорных случаях право окончательного решения принадлежит капитану. Судовладелец вправе требовать от агента услуг и выполнения работ только в рамках законов правил и обычаев страны пр
10517. Коммерческое значение порта 45 KB
  Коммерческое значение порта. Порт это либо понятие географическое либо административно-управленческое. Соотношение портовых властей и коммерческих предприятий: такие как город и мэрия. За рубежом порт управляется общественным советом. Сюда входят представите...
10518. Буксирная помощь 36 KB
  Буксирная помощь. Как правило частные буксирные компании. С буксирными компаниями можно заключить отдельный долгосрочный договор тогда судовладелец обязан обращаться только к этой компании. Буксировка: внутрипортовая: содействие в маневрировании судна в пор
10519. Способы оплаты в морском бизнесе 42.5 KB
  Способы оплаты в морском бизнесе. оплата наличными: это только оплата. Предусматривает что получатель платежа может беспрепятственно и немедленно получить платеж в банке в день согласованного платежа. Так оплачиваются: фрахт, демеридж, мертвый фрахт...
10520. Согласование фрахтовой ставки 38.5 KB
  Согласование фрахтовой ставки. Надо согласовать 11 пунктов. ставка фрахта: арифметическая величина; валюта фрахта: доллары валюта в которой выражена фрахтовая ставка; фрахтовая единица: физическая единица на которой установлена ставка фрахта. Единица: ...
10521. От чего зависит оборачиваемость коносамента 38 KB
  Оборотные документы имеют два свойства: Освобождение правомерного держателя от каких бы то ни было возражений в платеже со стороны плательщика. Коносамент является носителем обязательного права. Что делать кредитору если не платят по векселю Можно обратиться к ка
10522. Выдача коносамента. Коносамент как расписка в приеме груз 58.5 KB
  Выдача коносамента. I этап: возникновение коносамента продолжение: Коносамент выдается на основании штурманской расписки. Выдавать коносамент транспортному агенту номинированному фрахтователем - опасно. Об...
10523. Международно-правовое регулирование ответственности морского перевозчика за не сохранность груза 29 KB
  Международноправовое регулирование ответственности морского перевозчика за не сохранность груза. Основные принципы: полная реституция; ответственность за действия своих служащих как за свои собственные; в свободном контракте может быть установлено ус...