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

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

Табличные данные могут быть вставлены, восстановлены, обновлены и удалены. Для пакета этих операций была создана специальная аббревиатура CRUD (Create-Read-Update-Delete).

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

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

Шаг 1. Подготовка данных

Для того чтобы нам было с чем работать, я набрал в твиттере запрос “#databases” и сформировал таблицу из 10 записей:

Таблица 1

full_name username text created_at following_username
Boris Hadjur _DreamLead Scootmedia, MetiersInternet
Gunnar Svalander GunnarSvalander klout, zillow
GE Software GEsoftware DayJobDoc, byosko
Adrian Burch adrianburch CindyCrawford, Arjantim
Andy Ryder AndyRyder5 MichaelDell, Yahoo
Andy Ryder AndyRyder5 MichaelDell, Yahoo
Brett Englebert Brett_Englebert
Brett Englebert Brett_Englebert RealSkipBayless, stephenasmith
Nimbus Data Systems NimbusData dellock6, rohitkilam
SSWUG.ORG SSWUGorg drsql, steam_games

В первую очередь, давайте разберёмся с колонками:

Это реальные данные. Если хотите, вы можете их найти и обновить.

Хорошо. Теперь все наши данные находятся в одном месте. Даёт ли это нам возможность легко осуществить поиск по ним? Не совсем. Данная таблица далека от идеала. Во-первых, в некоторых столбцах у нас есть повторяющиеся записи: к примеру, в х “username” и “following_username”. Также колонка “following_username” нарушает правила реляционных моделей, т.к. её в ячейках присутствует более 1 значения (записи разделены запятыми).

К тому же у нас попадаются дубликаты и в строках.

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

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

Шаг 2. Избавляемся от дубликатов в столбцах

Как было оговорено выше, столбцы “username” и “following_username” содержат дубликаты данных. Они возникли в результате того, что я хотел отобразить отношения между твиттами и пользователями. Давайте улучшим нашу структуру БД, разделив существующую таблицу на две: в одной будем хранить информацию, а в другой - отношения между записями.

Поскольку @Brett_Englebert подписан на @RealSkipBayless, то в таблице “following” отобразим это следующим образом: имя @Brett_Englebert поместим в колонку “from_user”, а @RealSkipBayless в “to_user.” Давайте посмотрим, как будет выглядеть таблица “following” после разделения Таблицы 1 :

Таблица 2. following

from_user to_user
_DreamLead Scootmedia
_DreamLead MetiersInternet
GunnarSvalander klout
GunnarSvalander zillow
GEsoftware DayJobDoc
GEsoftware byosko
adrianburch CindyCrawford
adrianburch Arjantim
AndyRyder MichaelDell
AndyRyder Yahoo
Brett_Englebert RealSkipBayless
Brett_Englebert stephenasmith
NimbusData dellock6
NimbusData rohitkilam
SSWUGorg drsql
SSWUGorg steam_games

Таблица 3. users

full_name username text created_at
Boris Hadjur _DreamLead What do you think about #emailing #campaigns #traffic in #USA? Is it a good market nowadays? do you have #databases? Tue, 12 Feb 2013 08:43:09 +0000
Gunnar Svalander GunnarSvalander Bill Gates Talks Databases, Free Software on Reddit http://t.co/ShX4hZlA #billgates #databases Tue, 12 Feb 2013 07:31:06 +0000
GE Software GEsoftware RT @KirkDBorne: Readings in #Databases: excellent reading list, many categories: http://t.co/S6RBUNxq via @rxin Fascinating. Tue, 12 Feb 2013 07:30:24 +0000
Adrian Burch adrianburch RT @tisakovich: @NimbusData at the @Barclays Big Data conference in San Francisco today, talking #virtualization, #databases, and #flash memory. Tue, 12 Feb 2013 06:58:22 +0000
Andy Ryder AndyRyder5 http://t.co/D3KOJIvF article about Madden 2013 using AI to prodict the super bowl #databases #bus311 Tue, 12 Feb 2013 05:29:41 +0000
Andy Ryder AndyRyder5 http://t.co/rBhBXjma an article about privacy settings and facebook #databases #bus311 Tue, 12 Feb 2013 05:24:17 +0000
Brett Englebert Brett_Englebert #BUS311 University of Minnesota’s NCFPD is creating #databases to prevent “food fraud.” http://t.co/0LsAbKqJ Tue, 12 Feb 2013 01:49:19 +0000
Brett Englebert Brett_Englebert #BUS311 companies might be protecting their production #databases, but what about their backup files? http://t.co/okJjV3Bm Tue, 12 Feb 2013 01:31:52 +0000
Nimbus Data Systems NimbusData @NimbusData CEO @tisakovich @BarclaysOnline Big Data conference in San Francisco today, talking #virtualization, #databases,& #flash memory Mon, 11 Feb 2013 23:15:05 +0000
SSWUG.ORG SSWUGorg Don’t forget to sign up for our FREE expo this Friday: #Databases, #BI, and #Sharepoint: What You Need to Know! http://t.co/Ijrqrz29 Mon, 11 Feb 2013 22:15:37 +0000

Уже лучше. Теперь в таблице “users” (Таблица 3) у нас хранится только информация о твиттах, а в таблице following (Таблица 2) - зависимость пользователей.

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

Шаг 3. Удаление повторений из строк

Теперь мы займёмся устранением других проблем, а именно, избавимся от дубликатов в строках таблицы “users”. Поскольку пользователи @AndyRyder5 и @Brett_Englebert разместили по несколько твиттов, то их имена в таблице “users” (Таблица 3 ) дублируются в колонке full_name. Данная проблема также решается разделением таблицы “users”.

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

Таблица 4. tweets

username text created_at
_DreamLead What do you think about #emailing #campaigns #traffic in #USA? Is it a good market nowadays? do you have #databases? Tue, 12 Feb 2013 08:43:09 +0000
GunnarSvalander Bill Gates Talks Databases, Free Software on Reddit http://t.co/ShX4hZlA #billgates #databases Tue, 12 Feb 2013 07:31:06 +0000
GEsoftware RT @KirkDBorne: Readings in #Databases: excellent reading list, many categories: http://t.co/S6RBUNxq via @rxin Fascinating. Tue, 12 Feb 2013 07:30:24 +0000
adrianburch RT @tisakovich: @NimbusData at the @Barclays Big Data conference in San Francisco today, talking #virtualization, #databases, and #flash memory. Tue, 12 Feb 2013 06:58:22 +0000
AndyRyder5 http://t.co/D3KOJIvF article about Madden 2013 using AI to prodict the super bowl #databases #bus311 Tue, 12 Feb 2013 05:29:41 +0000
AndyRyder5 http://t.co/rBhBXjma an article about privacy settings and facebook #databases #bus311 Tue, 12 Feb 2013 05:24:17 +0000
Brett_Englebert #BUS311 University of Minnesota’s NCFPD is creating #databases to prevent “food fraud.” http://t.co/0LsAbKqJ Tue, 12 Feb 2013 01:49:19 +0000
Brett_Englebert #BUS311 companies might be protecting their production #databases, but what about their backup files? http://t.co/okJjV3Bm Tue, 12 Feb 2013 01:31:52 +0000
NimbusData @NimbusData CEO @tisakovich @BarclaysOnline Big Data conference in San Francisco today, talking #virtualization, #databases,& #flash memory Mon, 11 Feb 2013 23:15:05 +0000
SSWUGorg Don’t forget to sign up for our FREE expo this Friday: #Databases, #BI, and #Sharepoint: What You Need to Know! http://t.co/Ijrqrz29 Mon, 11 Feb 2013 22:15:37 +0000

Таблица 5. users

full_name username
Boris Hadjur _DreamLead
Gunnar Svalander GunnarSvalander
GE Software GEsoftware
Adrian Burch adrianburch
Andy Ryder AndyRyder5
Brett Englebert Brett_Englebert
Nimbus Data Systems NimbusData
SSWUG.ORG SSWUGorg

После разделения в таблице users (Таблица 5 ) у нас присутствуют уникальные (не повторяющиеся) строки.

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

Шаг 4. Объединяем таблицы на основе ключей

Итак, в результате наших действий, Таблица 1 была разбита на 3 части: following (Таблица 2), tweets (Таблица 4), users (Таблица 5). Все дубликаты устранены. Для того чтобы в дальнейшем мы могли с лёгкостью извлекать данные из этой структуры, независимые друг от друга таблицы мы должны связать специальными отношениями, которые будут давать нам информацию о том, какому пользователю принадлежит какой твит, и кто на кого подписан.

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

Вообще говоря, в Таблице 4 и 5 мы уже это сделали. В таблице “users” первичным ключом является колонка “username”, потому что логин пользователя должен быть уникальным значением и не может повторяться. В таблице “tweets” мы используем данный ключ для обозначения связи между пользователем и твитом. Колонка “username” в таблице “tweets” называется внешним ключом.

Если вы когда-то работали с базами данных, то у вас может возникнуть вопрос: можем ли мы использовать колонку “username” в качестве первичного ключа?

С одной стороны, это может упростить процесс поиска, ведь мы не используем никаких числовых ID. С другой стороны, что если пользователь захочет поменять свой логин? Это может привести к огромному количеству проблем. Для того чтобы не попасть в подобную ситуацию, лучше воспользоваться числовыми ID. Всё зависит от вашей системы. Если вы предоставляете вашим пользователям возможность менять логины, то лучше в качестве первичного ключа использовать автоинкрементированное числовое поле ID. В противном случае, колонка “username” вполне подойдёт для этой роли. Я оставлю всё как есть.

Давайте посмотрим на таблицу tweets (Таблица 4). Первичный ключ должен быть уникальным для каждой строки. Какую колонку в данной таблице мы можем выбрать для этой роли? Колонка “created_at” не подойдёт, т.к. в принципе 2 разных пользователя могут в одно и то же время опубликовать запись. С колонкой “text” та же история: два разных пользователя могут создать твит с текстом “Hello World”. Колонка “username” в данной таблице является внешним ключом для обозначения связи между пользователем и твитом. Итак, поскольку все возможные варианты нам не подходят, то лучшим решением будет добавление колонки id, которая будет первичным ключом для данной таблицы.

Таблица 6. tweets с колонкой id

ID username text created_at
1 _DreamLead What do you think about #emailing #campaigns #traffic in #USA? Is it a good market nowadays? do you have #databases? Tue, 12 Feb 2013 08:43:09 +0000
2 GunnarSvalander Bill Gates Talks Databases, Free Software on Reddit http://t.co/ShX4hZlA #billgates #databases Tue, 12 Feb 2013 07:31:06 +0000
3 GEsoftware RT @KirkDBorne: Readings in #Databases: excellent reading list, many categories: http://t.co/S6RBUNxq via @rxin Fascinating. Tue, 12 Feb 2013 07:30:24 +0000
4 adrianburch RT @tisakovich: @NimbusData at the @Barclays Big Data conference in San Francisco today, talking #virtualization, #databases, and #flash memory. Tue, 12 Feb 2013 06:58:22 +0000
5 AndyRyder5 http://t.co/D3KOJIvF article about Madden 2013 using AI to prodict the super bowl #databases #bus311 Tue, 12 Feb 2013 05:29:41 +0000
6 AndyRyder5 http://t.co/rBhBXjma an article about privacy settings and facebook #databases #bus311 Tue, 12 Feb 2013 05:24:17 +0000
7 Brett_Englebert #BUS311 University of Minnesota’s NCFPD is creating #databases to prevent “food fraud.” http://t.co/0LsAbKqJ Tue, 12 Feb 2013 01:49:19 +0000
8 Brett_Englebert #BUS311 companies might be protecting their production #databases, but what about their backup files? http://t.co/okJjV3Bm Tue, 12 Feb 2013 01:31:52 +0000
9 NimbusData @NimbusData CEO @tisakovich @BarclaysOnline Big Data conference in San Francisco today, talking #virtualization, #databases,& #flash memory Mon, 11 Feb 2013 23:15:05 +0000
10 SSWUGorg Don’t forget to sign up for our FREE expo this Friday: #Databases, #BI, and #Sharepoint: What You Need to Know! http://t.co/Ijrqrz29 Mon, 11 Feb 2013 22:15:37 +0000

С таблицей following можем сделать то же самое, т.к. ни одна существующая колонка не подойдёт на роль первичного ключа. Колонки “from_user” и “to_user” являются внешними ключами и обозначают связь между подписками пользователей.

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

Ниже вы можете увидеть схему наших таблиц и связей между ними:

Системы Управления Базами Данных

Теперь, когда у нас есть реляционная БД, каким образом мы можем её имплементировать? Для этого мы можем воспользоваться системами управления базами данных (СУБД). Существует целый набор подобных программ, как платных, так и бесплатных. Среди платных можно выделить Oracle Database , IBM DB2 и Microsoft SQL Server . Бесплатные: MySQL , SQLite и PostgreSQL .

Чаще всего различные компании используют MySQL. Twitter в этом смысле - не исключение.

SQLite чаще используется при разработке приложений для iOS и Android, где хранится различного рода конфиденциальная информация. Браузер Google Chrome использует SQLite для хранения истории просмотров, кукисов, изображений...

PostgreSQL используется реже. Для неё существует полезное расширение PostGIS, которое делает данную СУБД удобной для хранения геолокационных данных. К примеру сервис OpenStreetMap исользует PostgreSQL.

Язык структурированных запросов (SQL)

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

Создание БД development:

CREATE DATABASE development;

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

CREATE TABLE users (full_name VARCHAR(100), username VARCHAR(100));

При создании полей нам необходимо указать тип хранимой информации и её размер. Колонки “full_name” и “username” будут типа VARCHAR, который предназначен для хранения строк символов. Размер 100 символов. Список всех типов вы можете найти .

Добавление записи:

INSERT INTO users (full_name, username) VALUES ("Boris Hadjur", "_DreamLead");

Извлечение всех записей пользователя _DreamLead:

Обновление записи:

Удаление записи:

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

Итог

В этом уроке мы разобрали процесс создания реляционной БД, взяли набор данных и распределили их по таблицам, согласно реляционной модели. Также мы быстро пробежались по существующим СУБД и языку SQL.

База данных (БД) - это поименованная совокупность структурированных данных, относящихся к определенной предметной области и предназначенных для хранения, накопления и обработки с помощью ЭВМ.

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

Основные понятия реляционных баз данных:

· Тип данных – тип значений конкретного столбца.

· Домен (domain) – множество всех допустимых значений атрибута.

· Атрибут (attribute) – заголовок столбца таблицы, характеризующий поименованное свойство объекта, например, фамилия студента, дата оформления заказа, пол сотрудника и т.п.

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

· Отношение (relation) – таблица, отражающая информацию об объектах реального мира, например, о студентах, заказах, сотрудниках, жителях и т.д.

· Первичный ключ (primary key) – поле (или набор полей) таблицы, однозначно идентифицирующий каждую из ее записей.

· Альтернативный ключ – это поле (или набор полей), несовпадающее с первичным ключом и уникально идентифицирующий экземпляр записи.

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

· Реляционная модель данных (РМД) - организация данных в виде двумерных таблиц.

Каждая реляционная таблица должна обладать следующими свойствами:

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

2. Каждое значение, записывается на пересечении строки и столбца - является атомарным (неразделимым).

3. Значения каждого поля должны быть одного типа.

4. Каждое поле имеет уникальное имя.

5. Порядок расположения записей несущественен.

Основные элементы БД:

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

· имя, например, Фамилия, Имя, Отчество, Дата рождения;

· тип, например, строковый, символьный, числовой, датовый;

· длина, например, в байтах;

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

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

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


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

Запрос – сформулированный вопрос к одной или нескольким взаимосвязанным таблицам, содержащий критерии выборки данных. Запрос осуществляется с помощью структурированного языка запросов SQL (Srtructured Query Language). В результате выборки данных из одной или нескольких таблиц может быть получено множество записей, называемое представлением.

Представление данных – сохраняемый в базе данных именованный запрос на выборку данных (из одной или нескольких таблиц).

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

Отчет – компонент системы, основное назначение которого – описание и вывод на печать документов на основе информации из БД.

Общая характеристика работы с РБД:

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

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

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


28. АЛГОРИТМИЧЕСКИЕ ЯЗЫКИ. ТРАНСЛЯТОРЫ (ИНТЕРПРЕТАТОРЫ И КОМПИЛЯТОРЫ). АЛГОРИТМИЧЕСКИЙ ЯЗЫК БЕЙСИК. СТРУКТУРА ПРОГРАММЫ. ИДЕНТИФИКАТОРЫ. ПЕРЕМЕННЫЕ. ОПЕРАТОРЫ. ОБРАБОТКА ОДНОМЕРНЫХ И ДВУХМЕРНЫХ МАССИВОВ. ФУНКЦИИ ПОЛЬЗОВАТЕЛЯ. ПОДПРОГРАММЫ. РАБОТА С ФАЙЛАМИ ДАННЫХ.

Язык высокого уровня - язык программирования, понятия и структура которого удобны для восприятия человеком.

Алгоритмический язык (Algorithmic language) - язык программирования - искусственный (формальный) язык, предназначенный для записи алгоритмов. Язык программирования задается своим описанием и реализуется в виде специальной программы: компилятора или интерпретатора. Примерами алгоритмических языков служат – Borland Pascal, C++, Basic и т.д.

Основные понятия алгоритмического языка:

Состав языка :

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

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

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

Оператор - последовательность выражений, элементарных конструкций и символов.

Описание языка:

Описание символов заключается в перечислении допустимых символов языка. Под описанием элементарных конструкций понимают правила их образования. Описание выражений - это правила образования любых выражений, имеющих смысл в данном языке. Описание операторов состоит из рассмотрения всех типов операторов, допустимых в языке. Описание каждого элемента языка задается его СИНТАКСИСОМ и СЕМАНТИКОЙ.

Синтаксические определения устанавливают правила построения элементов языка.

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

Символы языка - это основные неделимые знаки, в терминах которых пишутся все тексты на языке.

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

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

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

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

Трансляторы - (англ. translator - переводчик) - это программа-переводчик. Она преобразует программу, написанную на одном из языков высокого уровня, в программу, состоящую из машинных команд.

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

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

1.Компиляция: Компилятор (англ. compiler - составитель, собиратель) читает всю программу целиком, делает ее перевод и создает законченный вариант программы на машинном языке, который затем и выполняется.

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

2. Интерпретация: Интерпретатор (англ. interpreter - истолкователь, устный переводчик) переводит и выполняет программу строка за строкой.

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

Откомпилированные программы работают быстрее, но интерпретируемые проще исправлять и изменять

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

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

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

Реляционная БД - это БД, основанная на реляционной модели данных (РМД).

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

В РМБД основной структурной единицей является таблица (отношение). Реляционная модель ориентирована на организацию данных в виде двумерных таблиц . Каждая реляционная таблица представляет собой двумерный массив и обладает следующими свойствами :

Каждый элемент таблицы – это один элемент данных;

Все столбцы в таблице однородные, т.е. все элементы в столбце имеют одинаковый тип (числовой, символьный и т.д.) и длину;

Каждый столбец имеет уникальное имя;

Одинаковые строки в таблице отсутствуют;

Порядок следования строк и столбцов может быть произвольным.

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

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

32 Основные модели баз данных (БД)

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

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

1) Иерархическая (перв. пол. 60-х г.) предназначалась для хранения БД на бумажном носителе и магнитных лентах. Структура связи между данными основ-ся на теории Графа и предст-ся в виде дерева (перевернутого). Разл. объекты создают узлы дерева , т.е. находятся на разл. уровнях иерархии. Связи опис-ся в категориях отец-сын или предок-потомок. Каждый узел i-го уровня иерархии относитсяся к узлу i-1 уровня (i>1), как относится сын к отцу, либо отец к сыну, а именно сын может быть одного отца, а отец – одного и более сыновей, т.е. объект данного i-го уровня относится к объектам i+1 уровня, как 1 ко многим (1:N, 1:∞). Недостатки : 1) польз-ль должен знать структуру дерева, иначе поиск данных затруднен; 2) поиск необх. данных всегда нач-ся с корня, а дальше осущ-ся навигация по ветвям дерева.



2) Сетевая (втор. пол. 60-х г.) для уменьшить влияние недостатков предыдущей модели. Осн. отличие от иерархич.: может сущ-ть связь между объектами, находящ-ся как на одном уровне иерархии, так и на разных. Это привело к увел-ю скорости поиска данных. Однако сущ-т недостаток : польз-ль должен знать структуру такого дерева.

Основной недостаток двух моделей : очень слабая математическая база.

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

Реляционная компьютерная база, как и любая другая база, является ИС, схематически представленной:

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

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

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

Нормализация

Нормальные формы

См. также

  • Реляционная модель
  • Реляционные СУБД

Смотреть что такое "Реляционные БД" в других словарях:

    Реляционные базы данных - Реляционная база данных база данных, основанная на реляционной модели данных. Слово «реляционный» происходит от англ. relation (отношение). Для работы с реляционными БД применяют реляционные СУБД. Использование реляционных баз данных было… … Википедия

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

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

    Алгебра Кодда - Содержание 1 Реляционные операторы 1.1 Совместимость отношений … Википедия

    OLAP - (англ. online analytical processing, аналитическая обработка в реальном времени) технология обработки данных, заключающаяся в подготовке суммарной (агрегированной) информации на основе больших массивов данных, структурированных по… … Википедия

    Грамматическая категория - Грамматическая категория замкнутая система взаимоисключающих и противопоставленных друг другу грамматических значений (граммем), задающая разбиение обширной совокупности словоформ (или небольшого набора высокочастотных словоформ с… … Википедия

    ORM - также может означать: англ. Object Role Model, рус. Модель ролей объекта методика концептуального проектирования информационных систем, включающая собственную графическую нотацию. Содержание 1 Задача … Википедия

    СУБД

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

    Реляционная алгебра - Реляционная алгебра замкнутая система операций над отношениями в реляционной модели данных. Операции реляционной алгебры также называют реляционными операциями. Первоначальный набор из 8 операций был предложен Э. Коддом в 1970 е годы и… … Википедия

Книги

  • Реляционные базы данных. Руководство , Уидом Дженнифер. Книга "Реляционные базы данных" написана хорошо известными учеными Станфордского университета Джеффри Ульманом и Дженнифер Уидом. Авторы предлагают ориентированный на пользователя подход к… Купить за 1074 руб
  • Реляционные базы данных , Ульман Д., Уидом Д.. Книга"Реляционные базы данных"написана хорошо известными учеными Станфордского университета Джеффри Ульманом и Дженнифер Уидом. Авторы предлагают ориентированный на пользователя подход к…

Уровень 1: Уровень внешних моделей – это самый верхний уровень где каждая модель имеет свое видение данных. Этот уровень определяет точку зрения базы данных отдельных приложений.

Концептуальный уровень: Центральное управляющее звено, где здесь БД представлена в наиболее общем виде, который объединяет данные используемые всеми приложениями. Фактически концептуальный уровень отражает обобщённую модель предметной область.

Физический уровень (База данных): Это сами данные расположенные в файлах или в страничных структурах, расположенных навнешних носителях информации.


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

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

1. Инфологические

2. Дата логические

3. Физические

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

Кортеж доменов

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

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

Даталогическая модель

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

Иерархическая модель

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

связь уровень


Узлом называется совокупность атрибутов данных описывающих некоторый объект. Каждый узел связан с одним узлом более высокого уровня и с любым количеством узлов нижнего уровня. Исключением является узел самого высокого уровня. Количество деревьев в базе данных определяется количеством корней деревьев. К каждой записи базы данных существует единственный путь от корневой записи. Простым примером может служить система доменных имен в интернете\ адрес. На первом уровне (корень дерева) лежит наша планета земля, на втором Страна, на третьем- Регион, на четвёртом – населённый пункт, улица, дом,квартира. Типичным представителем является СУБД от IBM - IMS.

Все экземпляры данного типа потомка с общим экземпляром типа предка называется близнецами. Для базы данных определён полный порядок обхода. Сверху вниз и с права на лево.

Физическая модель

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

Пример: В частности для реляционной БД она уже учитывает:

1. Физические аспекты хранения таблиц в определённых файлах.

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

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

Инфологические модели Х

Физические модели


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

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

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

Однако в большинстве систем, если говорить о базах данных, типы данных являются более статичным элементом чем способы их обработки. Поэтому получили интенсивное развитие такие методы системного анализа как диаграмма потоков data flown diagram. Развитие реляционных БД. Стимулировала развитие построения методик развития данных в частности ER диаграмм ER. Реляционная модель данных в качестве отображения непосредственно использует понятие отношения. Она ближе всего находится к концептуальной модели представления данных. И часто лежит в основе её.

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

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

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

ОТНОШЕНИЕ ЭТО ТАБЛИЦА.

Редактирование таблиц, записей…

Удаление то что создали и

Редактирование.


Реляционная модель базы данных

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

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

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

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

SUMM Киреева 25.50 Мотылёва 17.05 … …. …

Отношение

атрибуты

Поля KOD, NAME, SUMM это атрибуты таблицы содержащиеся в заголовке.

Пары KOD 5216, NAME Киреева, SUMM 25.50 являются элементами тела отношения.

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

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

Домены и отношения

Основные определения: Домены, виды отношений, предикаты.

Отношения имеет ряд основных свойств:

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

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

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

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

В реляционных системах поддерживается несколько видов отношений:

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

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

3. Производное отношение это то которое было определено через другие, как правило базовые, отношения путём использования средств СУБД.

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

5. Результат запросов это не именованное производное отношение содержащее данные(результат конкретного запроса). Результат в БД не хранится а существует до тех пор пока он необходим пользователю.

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


Связь в данном случае это ассоциирование двух или более отношений.

KOD ADRES
1 1 Связь один ко многим состоит в том что в каждый момент времени каждому элементу (кортежу А) соответствует несколько элементов кортежей Б
∞ Бинарная связь
Студенты
Преподы
Расписание занятий

∞
∞
∞
Студенты

Тернарные связи


Целостность данных

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

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

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

О внешних ключах. Стоит отметить ввиду что отношение С связывает отношения B и А, то оно должно включать внешние ключи, соответствующий первичным ключам отношениям А и В.

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

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

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

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

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

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

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

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


Реляционная алгебра

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

Произведение

А А А Б В В Г Г Д
Г Д
А
А Б В Г Г Д Ж Ж З

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

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

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

Опишем вариант алгебры который был предложен КОДДОМ. Операция состоит из 8 основных операторов:

· Выборка отношения (унарная операция)

· Проекция отношения (унарная операция)

· Объединения отношений

· Пересечение отношений(бинарная операция)

· Вычитание отношений

· Произведение отношений

· Соединение отношений

· Деление отношений

Эти операции можно объяснить следующим образом:

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

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

· При выполнении операции объединения двух отношений будет получено отношение включающее все кортежи входящие в хотя бы одно из участвующих в операции отношений.

· При выполнении операции пересечения двух отношений будет получено отношение включающее все кортежи входящие в оба первоначальных отношения.

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

· При выполнении прямого произведения двух отношений получается отношение кортежи которого являются сочетанием кортежей первого и второго отношения.

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

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

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

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

Отсюда следует что результатом реляционной операции является некоторое отношение то имеется возможность образовывать реляционные выражения в которых вместо первоначального отношения (операнда), будет использоваться вложенное реляционное выражение. Это происходит благодаря тому факту что операция реляционной алгебры действительно замкнуты относительно понятия отношения. Начнём с операции объединения отношений , однако это в равной мере относится и к операциям пересечения и сочетания, то есть в реляционной алгебры результатом операции объединения является отношение. Если допустить в реляционной алгебре возможность объединения произвольных двух отношений с разными наборами атрибутов, то результатом такой операции будет множество, однако множество разнотипных кортежей, то есть вообще говоря не отношение. Если исходить из требования замкнутости реляционной алгебры относительно понятия отношения то такая операция объединения является бессмысленной. Это приводит к появлению понятия совместимости отношений по объединению : два отношения совместимы только в том случае, когда обладают одинаковыми заголовками, то есть имеет тот же набор имён атрибутов, и одноимённые атрибуты определены в том же домене.

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

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

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

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

Введём ряд операторов.

Пусть union означает операцию объединения, intersect – операция пересечение, minus – операция вычитания. Для обозначения операции выборки будем использовать конструкцию A where B , где А – отношение операнд, а В простое условие сравнения. Пусть С1 и С2 два простых условия выборки

A where C1 AND C2 идентично (A where C1) intersect (A where C2)

A where C1 OR C2 идентично (A where C1) union (A where C2)

A where C1 not C2 идентично (A where C1) minus (A where C2)

С использованием этих определений можно реализовать операции выборки, в которых условием выборки является произвольное логическое выражение составленное из простых условий с использованием логических связей (and, or, not) . Операция взятия проекций отношение А оп списку атрибутов а1, а2,…,an будет отношение заголовком которого является множество атрибутов, а1,а2,…,an. Тело результата будет состоять из кортежей для которых в отношении А имеется кортеж, атрибут а1 имеет значение b1, атрибут а2 значение b2< и так далее атрибут an – bn. По сути при выполнении операции проекции определяется «Вертикальная» вырезка отношения - операнда с удалением возникающих кортежей –дубликатов.

Операция соединения, называемая иногда соединением по условию требует наличия двух операндов – соединяемых отношений, и третьего операнда – простое условие. Пусть соединяется отношение А и В. Как и в случае операции выборки, условие соединения С имеет вид, (а comp –op b) либо (а comp –op const) где А и В имена атрибутов отношений А и В, const- литерально заданная константа. Comp-op – допустимая в данном контексте операция сравнения. Тогда по определению результатом операции соединения является отношение, получаемое путём, выполнения операции ограничения, по условию С прямого произведения отношения А и В.

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

Операция деления отношений нуждается в более подробном объяснении поскольку трудна для понимания. Пусть заданы два отношение А {a1,a2,..,an,b1,b2,…,bm}

B {b1,b2,…,bn} Будем полагать что атрибут b1 отношения A и атрибут b1 отношения B определены на одном и том же домене. Назавём множество атрибутов {aj} составным атрибутом а, множество {bj} cсоставным атрибутом b. После этого будем говорить о реляционном делении бинарного отношения А (а,b) на унарное отношение B (b).

Результатом деления А на В является унарное отношение С (а), состоящее из таких кортежей v что в отношении А имеются кортежи которые во множестве значений {w} включают множество значений b в отношении B.

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


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

Допустим имеется база данных обладающая структурой СТУДЕНТЫ (номер, имя, стипендия, код группы), и отношение ГРУППЫ(гр_ном, гр_кол, гр стар) Предположим что необходимо узнать имена и номера студ. билетов у студентов являющимися старостами групп с количеством человек больше 25. В реляционной алгебре нужно предпринять следующие действия для такого запроса:

1. Выполнить соединение отношений СТУДЕНТЫ и ГРУППЫ, по условию «студ_ номер =гр_стар»;

2. Ограничить полученное отношение по условию гр_кол>25.

3. Cпроецировать результат предыдущей операции на атрибут студ_имя, студ_номер.

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

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

Byte Integer String Char
M
N
K

Для определения кортежи используется команда RANGE. Например чтобы определить переменную СТУДЕНТ областью определения которой является СТУДЕНТЫ нужно употребить конструкцию RANGE СТУДЕНТ IS СТУДЕНТЫ. Из этого определения следует что в любой момент времени переменная студент представляет некоторый кортеж отношения СТУДЕНТЫ. При использовании кортежных переменных в формулах можно ссылать на значения атрибута переменных. Например для того чтобы сослаться на значение атрибута СТУД_ИМЯ переменной СТУДЕНТ нужно употребить конструкцию СТУДЕНТ.СТУД_ИМЯ.

Правильно построенные формулы служат для выражения условий, накладываемых на кортежные переменные. В основе таких формул лежат простые сравнения, представляющие собой, операции сравнения значений атрибутов переменных и литерально заданных констант. Например конструкция СТУДЕНТ.СТУД_НОМ=123456. Является простым сравнением. Более сложным вариантом составных формул является с помощью логических связей AND, OR, NOT, IF…THEN. Наконец допускается построение правильно построенных формул с помощью кванторов. Если F это правильно построенная формула в которой участвует переменная var то конструкция EXIST (квантор существования) var (F) и FORALL(для всех кортежей) var (F) являются правильными.

Переменные, входящие в правильно построенные формулы могут быть свободными или связанными. Все переменные входящие в их состав при построение которых не использовались кванторы являются свободными. Это означает что если для какого то набора значений свободных кортежных переменных при вычислении формул получено значение «истина», то эти значения могут входить в результирующие отношение. Если же при построении формул используется квантор то переменные являются связанными. При вычислении значения такой правильно построенной формулы используется ни одно значение связанной переменной а вся её область определения.

1)EXISTS СТУД2 (CТУД.1СТУД_СТИП> СТУД2.СТУД_СТИП)

2)FORALL СТУД2 (CТУД.1СТУД_СТИП> СТУД2.СТУД_СТИП)

Пусть СТУД1 и СТУД2 две кортежные переменные определённые на отношение студенты, тогда формула, для текущего кортежа переменной СТУД1 принимает значение истина только в том случае если во всём отношении студенты найдётся такой кортеж связанный с переменной СТУД2 что значение его атрибута СТУД_СТИП удовлетворяет внутреннему условию сравнения. Правильно построенная формула №2 для построенного кортежа СТУД 1 принимает значение истина если для всех кортежей отношение СТУДЕНТЫ связанных с переменной СТУД 2 значение атрибута СТУД.СТИП удовлетворяет внутреннему условию.

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

Целевой список имеет вид:

· Var.attr –имя свободной переменной, атр имя атрибута отношения на котором определена переменная var.

· Var что эквивалентно отношению от списка, Var.attr1, Var.attr1… Var.attr№ включает имена всех атрибутов определяющего отношения.

· New_name = var.attr; новое имя соответствующего атрибута результирующего отношения.

Последний вариант требуется в тех случаях кода в формуле используется несколько свободных переменных с одинаковой областью определения. В исчислении доменов областью определения доменов являются не отношения а домены. Применительно к бд СТУДЕНТЫ ГРУППЫ можно говорить о доменных переменных ИМЯ (Значения домена – допустимые имена или НОМ СТУД). (Значения домена допустимые номера студентов).

Основным отличием исчисления доменов от исчисления кортежей является наличие дополнительного набора предикатов, позволяющих выражать так называемые условия членства. Если R это n- арное отношение с атрибутами (a1, a2, … an) то условие членства имеет вид R(ai1:Vi1,ai2:Vi2,…aim:Vim) где (m<=n). Где в Vij это либо литерально заданная константа либо имя кортежной переменной. Условие членства принимает значение истина, только в том случае если в отношении R существует кортеж, содержащий следующие значения указанных атрибутов. Если от Vij константа то на атрибут aij накладывается жёсткое условие независящее от текущих доменных переменных. Если же Vij имя доменной переменной то условие членства может принимать различные значения при разных значениях этой переменной.

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

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


Похожая информация.