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

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

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

В качестве примеров СУБД можно назвать такие широко известные пакеты, как

• MySQL
• PostgreSQL
• Microsoft SQL Server
• Oracle
• IBM DB2
• Microsoft Access
• SQLite

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

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

Итак, основные задачи, выполняемые СУБД включают

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

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

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

Модели БД

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

• Иерархическая, или навигационная модель
• Сетевая модель

Иерархическая модель широко использовалась в СУБД, поставляемых компанией IBM в 1960х. Основная идея заключается в том, что запись в такой БД может иметь несколько “дочерних” и одну “родительскую”. В целом, это подозрительно похоже на иерархическую файловую систему. Чтобы получить запись в такой БД, часто необходим проход по всему дереву.

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

В 1970х Эдгаром Коддом (сотрудник IBM) была предложена реляционная модель, которая значительно облегчила задачу поиска информации в БД. О реляционной модели можно думать как о “таблицах”, в которых “строки” – это записи в БД. Записи в реляционной БД так же называются кортежами (tuples), а группы записей (“таблицы”) – отношениями (relations). Реляционная модель способна выразить связи иерархической и сетевой моделей, и добавляла собственные связи, соответствующие табличной модели.

На основе предложений Кодда к середине 1970х была разработана СУБД System R, а к концу в ней появилась поддержка стандартизованного языка запросов SQL.

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

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

Реляционная модель

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

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

Введем некоторые определения.

Домен Множество, содержащее полный набор всех возможных значений некоторой переменной. Домены часто так же называют типом данных . Атрибут Упорядоченная пара названия атрибута и домена \(D_j\) . Кортеж Конечное упорядоченное множество \((d_1, d_2, \ldots, d_n)\) Заголовок (схема) отношения Кортеж \((A_1, A_2, \ldots, A_n)\) , где \(A_j\) – атрибуты. Значение атрибута Конкретное значение, принадлежащее домену атрибута. Тело отношения Множество кортежей , где \(d^i_j \in D_j\) , \(D_j\) – домены. Запись Кортеж \((d^i_1, d^i_2, \ldots, d^i_n)\) при фиксированном \(i\) . Отношение Совокупность заголовка отношения и тела отношения. Схема базы данных Множество схем всех отношений, входящих в БД.

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

\(A_1\)	\(A_2\)	\(\ldots\)	\(A_n\)	← Заголовок
\(d^1_1\)	\(d^1_2\)	\(\ldots\)	\(d^1_n\)	← Запись
\(d^2_1\)	\(d^2_2\)	\(\ldots\)	\(d^2_n\)	← Запись
\(\ldots\)	\(\ldots\)	\(\ldots\)	\(\ldots\)	← Запись
\(d^m_1\)	\(d^m_2\)	\(\ldots\)	\(d^m_n\)	← Запись

Реляционная модель налагает следующие дополнительные требования на отношения:

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

Функциональная зависимость множество атрибутов \(B\) функционально зависит от множества атрибутов \(A\) (записывается \(A\rightarrow B\) ), если для любых двух записей, имеющих одинаковые значения \(A\) , их значения \(B\) совпадают. Иначе, каждому значению \(A\) соответствует единственное значение \(B\) (не обязательно уникальное, именно единственное).

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

В качестве более привычного примера функциональной зависимости, можно привести математическое определение функции. Для функции, каждому значению аргументов соответсвтует единственное значение функции. Обратное в общем случае неверно, например, для функции \(y = sin(x)\) любому значению \(y\) из области определения \(1\geq y \geq -1\) соответствует бесконечное множество значений \(x\) , но для каждого значения \(x\) есть ровно одно значение \(y\) , т.о. \(x \to y\) . Заметим, что понятие функциональной зависимости так же применимо и к функциям многих переменных. Для них, значение функции функционально зависит от всех аргументов одновременно . Скажем, для функции \(z = f(x,y)\) выполняется ФЗ \((x,y)\to z\) , или сокращенно, \(xy\to z\) .

Отношения в данном контексте можно рассматривать как некие табличные или дискретные функции.

Работа с ФЗ

Существуют определенные формальные правила работы с ФЗ отношения.

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

Аксиомы Армстронга

Существуют правила вывода новых ФЗ из существующих, называемые аксиомами Армстронга .

Аксиомы Армстронга

1. Правило рефлексивности: если \(B \subset A\) , то \(A\rightarrow B\)
2. Правило дополнения: если \(A\rightarrow B\) , то \(AC\rightarrow BC\)
3. Правило транзитивности: если \(A\rightarrow B\) и \(B\rightarrow C\) , то \(A\rightarrow C\)

Из этих аксиом так же могут быть выведены следующие дополнительные правила:

1. Правило самоопределения: \(A\rightarrow A\)
2. Правило декомпозиции: Если \(A\rightarrow BC\) , то \(A\rightarrow B\) и \(A\rightarrow C\)
3. Правило объединения: Если \(A\rightarrow B\) и \(A\rightarrow C\) , то \(A\rightarrow BC\)
4. Правило композиции: Если \(A\rightarrow B\) и \(C\rightarrow D\) , то \(AC\rightarrow BD\)

Можно заметить, что, вследствие правила рефлексивности, любое множество атрибутов \(A\) подразумевает ФЗ вида \(A\to A\) . Такие ФЗ, а так же следующие из них, не представляют интереса, и называются тривиальными.

Тривиальная функиональная зависимость ФЗ \(A \to B\) , такая, что \(B \subset A\) .

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

Замыкание множества ФЗ Замыканием множества ФЗ называется такое множество ФЗ, которое включает все ФЗ исходного множества, а так же все подразумеваемые ими. Другими словами, для отношения \(R\) , обладающего функциональными зависимостями \(S\) , замыканием \(S^+\) называется множество всех ФЗ, возможных для \(R\) , исходя из \(S\) .

Как правило, требуется установить, будет ли некая ФЗ \(X\rightarrow Y\) следовать из данного множества ФЗ \(S\) . Оказывается, это возможно тогда и только тогда, когда множество атрибутов \(Y\) является подмножеством замыкания атрибутов \(X^+\) в \(S\) .

Замыкание атрибутов Замыканием \(X^+\) атрибутов \(X\) по множеству ФЗ \(S\) называется множество всех атрибутов, которые функционально зависят от какого-либо подмножества \(X\) .

Для вычисления замыкания множества атрибутов \(X^+\) по множеству ФЗ \(S\) существует следующее правило: для каждой ФЗ \(A\rightarrow B\) в \(S\) , если \(A \subset X^+\) , то и \(B \subset X^+\) , причем достаточно начать с предположения, что \(X^+ = X\) .

Следует заметить, что для любого замыкания \(X^+\) , существуют ФЗ вида \(X \to B\) , где \(B \subset X^+\) , таким образом, замыкания всех атрибутов отношения по его ФЗ описывают замыкание ФЗ этого отношения.

Это правило используется для вычисления неприводимого множества ФЗ, эквивалентного данному (в смысле эквивалентности их замыканий). Уменьшение количества ФЗ при сохранении замыкания (и, следовательно, внутренней логики, описываемой ФЗ) является важным шагом в проектировании БД.

Множество ФЗ называется неприводимым, если:

1. Правая часть каждой ФЗ содержит только один элемент
2. Ни один атрибут ни одной левой части ФЗ множества не может быть удален без изменения замыкания
3. Ни одна ФЗ множества не может быть удалена без изменения замыкания.

Для любого множества ФЗ существует хотя бы одно эквивалентное неприводимое множество. Такое множество называется минимальным покрытием .

РМД была придумана и разработана Э.Кодд в 1970г. Его последователь Дейт.

В основе РМД лежит понятие теоретико-множественного отношения .

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

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

Атрибут – это свойство характеризующее сущность.

Пусть дано D 1 ,D 2 ,…,D n –n-множеств,

Тогда отношение R-это множество упорядоченных кортежей d i єD i , гдеd i -атрибут,D i –домен.

Пример:

Сотрудник

Арностью отношений (степенью) является общее количество атрибутов в отношении.

Кардинальным числом (мощностью отношений) называют число всех различных кортежей в образующих отношенияR.

Отношением называется некоторое подмножество декартового произведения, включающего один или несколько доменов.

Пр: имеется множество

D 1* D 2* D 3 ={(A,B,3),(A,B,4),(A,B,5),(A,C,3),(A,C,4),(A,C,5),(2,B,3),(2,B,4),(2,B,5),(2,C,3),(2,C,4),

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

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

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

Подмножество атрибутов Р отношения R называется потенциальным ключом (возможным ключом), если выполняются следующие два условия:

в отношении R не может быть двух различных кортежей с одинаковым значениям (это называется свойством уникальности).

никакое подмножество Р не обладает свойством уникальности.

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

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

Ключи обычно используются для следующих целей:

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

упорядочивание кортежей.

ускорение работы с кортежами отношений.

организация связывания таблиц.

Пусть в отношении R1 имеется неключевой атрибутA, значение которого является значением ключевого атрибутаBдругого отношенияR2, тогда говорят что атрибутAотношенияR1 являетсявнешним ключом .

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

все записи должны иметь одинаковую структуру.

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

значение элементов одного столбца должны принадлежать одному и тому же домену.

имена столбцов должны быть уникальными.

ADD – данная операция сообщает об ошибках в следующих случаях:

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

Некоторое значение кортежа не принадлежит соответствующему домену.

Кортеж совпадает по ключу с кортежем, уже имеющемся в отношении.

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

CH – дляданной операции все ошибки добавления и удаления имеют место.

ПРОГРАММИРОВАНИЕ В СРЕДЕ DELPHI 6

Базы данных. Создание отчета с помощью Word.

Утверждено Редакционно-издательским советом

университета в качестве лабораторного практикума

Воронеж 2004

УДК 681.3

Воробьёв Э.И., Короткевич Д.Э.. Программирование в среде Delphi 6: Лабораторный практикум: Ч. 2: Базы данных. Создание отчета с помощью Word. Потоки. Воронеж: Воронеж. гос. техн. ун-т, 2004. 107 с.

Во второй части лабораторного практикума рассматриваются теоретические и практические сведения для написания программ в среде Delphi 6 на тему: «Проектирование баз данных, создание отчетов в программе Word и использование потоков при создании высокопроизводительных приложений».

Издание соответствует требованиям Государственного образовательного стандарта высшего профессионального образования по направлению 230100 «Информатика и вычислительная техника», специальности 230104 «Системы автоматизированного проектирования», дисциплине «Программирование на языках высокого уровня».

Табл. 3. Ил. 19. Библиогр.: 7 назв.

Научный редактор: д-р техн. наук, проф. Я.Е. Львович

Рецензенты: кафедра вычислительной техники Воронеж- ской лесотехнической академии (зав. кафедрой д-р техн. наук, проф. В.Е. Межов);

д-р техн. наук, проф. О.Ю.Макаров

© Воробьёв Э.И., Короткевич Д.Э., 2004

© Оформление. Воронежский государственный

технический университет, 2004

Введение

Концепция баз данных

Базы данных считаются основным преимуществом Delphi. Даже специализированные языки для работы с базами данных (такие, как MS Visual FoxPro) явно уступают по простоте и мощи программирования этого типа приложений. Delphi скрывает все сложности и в то же время даёт величайшую мощь. Ещё не было такой задачи, которую не смогли бы реализовать на Delphi за короткий промежуток времени. А главное, что всё это реализовано очень удобно и легко для понимания. В Delphi можно создавать простые приложения, даже со сложными базами, без единой строчки кода. В данном учебном пособии рассмотрены лабораторные задания для освоения приемов работы с локальными базами данных.

Теория реляционных баз данных

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

Базы данных делятся на локальные (установленные на компьютере клиента, там же где и работает программа) и удалённые (установленные на сервере, удалённом компьютере). Серверные базы данных располагаются на удалённом компьютере и работают под управлением серверного программного обеспечения. К их главным преимуществам можно отнести возможность работы с одной базой данных одновременно несколькими пользователями, и при этом осуществляется минимальная нагрузка на сеть. Есть ещё сетевые базы данных, которые создают слишком большую нагрузку на сеть и неудобны в работе как для программиста, так и для конечного пользователя. Когда программа присоединяется к сетевой базе данных, то она выкачивает с сервера практически полную его копию. Если Вы внесли изменения, то Ваша копия полностью закачивается обратно. Это очень неудобно, потому что создаётся большая нагрузка на сеть из-за излишней перекачки данных. При клиент-серверной технологии программа клиент посылает простой текстовый запрос на сервер на получение каких-либо данных. Сервер обрабатывает его и возвращает только необходимую порцию данных. Когда нужно изменить какие-то данные опять посылается запрос к серверу на их изменение, и сервер изменяет данные в своей базе. Таким образом, по сети происходит перекачка в основном только текстовых запросов, которые в основном занимают меньше килобайта. Все данные обрабатывает сервер, а значит, машина клиента загружается намного меньше и не так сильно требовательна к ресурсам. Сервер отсылает клиенту только самые необходимые данные, а значит, отсутствует излишняя перекачка копии всей базы. Благодаря всему этому сетевые базы данных уже устарели и практически не используются. Их практически полностью вытесняет технология клиент-сервер. А вот локальные базы данных будут жить всегда. Может измениться формат их хранения или добавиться какие-то новые функции, но сами базы данных будут существовать. Для дальнейшего рассмотрения нам надо определить новое понятие – таблица . Пока что говорились только общие принципы, поэтому использовалось общее понятие баз данных . Таблица базы данных – это как двухмерный массив, в котором в столбец выстроены данные (яркий пример таблицы – Excel). База данных – грубо говоря, это всего лишь файл, в котором может храниться от одной до нескольких таблиц. Большинство локальных баз данных могут хранить только одну таблицу (dBase, Paradox, XML). Но есть представители локальных баз, где в одном файле заключено несколько таблиц (например Access).

Локальные базы данных

Из локальных баз данных рассмотрим реляционные как самые распространённые. Что такое реляционная база данных? Это таблица, в которой в качестве столбцов выступают имена хранимых в ней данных, а каждая строка хранит сами данные. Таблица базы данных похожа на электронную таблицу Excel (если быть точнее, то Excel хранит свои данные в виде собственного формата, построенного на основе технологии баз данных). Локальные таблицы баз данных могут храниться на локальном жёстком диске или централизовано сохраняться на сетевой диск файлового сервера. Эти файлы можно копировать с помощью стандартных средств как любой другой файл, потому что сами таблицы базы данных не привязаны к определённому месту расположения. Главное, чтобы программа могла найти таблицу. В каждой таблице должно быть одно уникальное поле, которое однозначно будет идентифицировать строку. Это поле называется ключевым. Эти поля очень часто используются для связывания нескольких таблиц между собой. Но даже если таблица не связана, ключевое поле всё равно обязательно. В качестве ключа желательно использовать численный тип и если позволяет база данных, то будет лучше если он будет типа "autoincrement" (автоматически увеличивающееся/уменьшающееся число или счётчик). Имена столбцов в таблице базе данных также должны быть уникальными, но в этом случае не обязательно числовыми. Их можно называть как угодно, лишь бы было уникально и понятно. Каждый столбец (поле базы данных) обязательно должен иметь определённый тип. Количество типов и их разновидности зависят от типа базы данных, например формат dBASE (файлы с расширением DBF) поддерживает только 6 типов, а Paradox уже до 15. База данных может храниться в одном файле (Access) или в нескольких (Paradox, dBase). Точнее сказать, данные таблицы всегда хранятся в одном файле, а вот дополнительная информация может располагаться в отдельных файлах. В качестве дополнительной информации могут быть индексы, ограничения или список значений по умолчанию для конкретных полей. Если хотя бы один из файлов запортится или будет удалён, то данные могут стать недоступными для редактирования.

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

Если надо, чтобы какая-то таблица была упорядочена по полю «Фамилия », то это поле надо сначала проиндексировать. Затем нужно только указать, что таблица должна работать сейчас с таким-то индексом, и она сортируется автоматически.

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

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

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

Требования к базам данных

Итак, хорошо спроектированная база данных:

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

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

3. Обеспечивает естественное, легкое для восприятия структурирование информации. Качественное построение базы позволяет делать запросы к базе более “прозрачными” и легкими для понимания; следовательно, снижается вероятность внесения некорректных данных и улучшается качество сопровождения базы.

4. Удовлетворяет требованиям пользователей к производительности базы данных. При больших объемах информации вопросы сохранения производительности

начинают играть главную роль, сразу “высвечивая” все недочеты этапа проектирования.

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

1. Определить информационные потребности базы данных.

2. Проанализировать объекты реального мира, которые необходимо смоделировать в базе данных. Сформировать из этих объектов сущности и характеристики этих сущностей (например, для сущности “деталь” характеристиками могут быть “название”, “цвет”, “вес” и т.п.) и сформировать их список.

3. Поставить в соответствие сущностям и характеристикам - таблицы и столбцы (поля) в нотации выбранной Вами СУБД (Paradox, dBase, FoxPro, Access, Clipper, InterBase, Sybase, Informix, Oracle и т.д.).

4. Определить атрибуты, которые уникальным образом идентифицируют каждый объект.

5. Выработать правила, которые будут устанавливать и поддерживать целостность данных.

6. Установить связи между объектами (таблицами и столбцами), провести нормализацию таблиц.

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

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

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

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

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

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

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

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

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

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

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

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

Атрибут (или данное) - это некоторый показатель, который характеризует некий объект и принимает для конкретного экземпляра объекта некоторое чис­ловое, текстовое или иное значение. Информационная система оперирует на­борами объектов, спроектированными применительно к данной предметной области, используя при этом конкретные значения атрибутов (данных) тех или иных объектах. Например, возьмем в качестве набора объектов классы в школе. Число учеников в классе - это данное, которое принимает числовое значение (у одного класса 28, у другого- 32). Название класса - это данное, принимающее текстовое значение (у одного - 10А, у другого - 9Б и т. д.).

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

Основоположником теории реляционных баз данных считается сотрудник фирмы IBM доктор Э. Кодд, опубликовавший 6 (июня 1970 г. статью A Relational Model of Data for Large-Shared Data Banks (Реляционная модель данных для больших коллективных банков данных). В этой статье впервые был использован термин «реляционная модель данных. Теория реляционных баз данных, разработанная в 70-х годах в США докто­ром Э. Коддом, имеет под собой мощную математическую основу, описывающую правила эффективной организации данных. Разработанная Э. Коддом теорети­ческая база стала основой для разработки теории проектирования баз данных.

Э. Кодд, будучи математиком по образованию, предложил использовать для обработки данных аппарат теории множеств (объединение, пересечение, раз­ность, декартово произведение). Он доказал, что любой набор данных можно представить в виде двумерных таблиц особого вида, известных в математике как «отношения».

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

Таблица состоит из столбцов (полей) и строк (записей); имеет имя, уникаль­ное внутри базы данных. Таблица отражает тип объекта реального мира (сущ­ность), а каждая ее строка- конкретный объект. Каждый столбец таблицы - это совокупность значений конк­ретного атрибута объекта. Значения выбираются из множества всех возможных значений атрибута объек­та, которое называется доменом (domain) .

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

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

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

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

Так как строки в таблице не упорядочены, невозможно выбрать строку по ее позиции - среди них не существует «первой», «второй», «последней». Любая таблица имеет один или несколько столбцов, значения в которых однозначно идентифицируют каждую ее строку. Такой столбец (или комбинация столбцов) называется первичным ключом (primary key) . Часто вводят искусственное поле, предназначенное для нумерации за­писей в таблице. Таким полем, например, может быть его порядковый, который сможет обеспечить уникальность каж­дой записи в таблице. Ключ должен обладать следующими свойствами.

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

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

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

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

Взаимосвязь таблиц является важнейшим элементом реляционной модели данных. Она поддерживается внешними ключами (foreign key).

При описании модели реляционной базы данных для одного и того же поня­тия часто употребляют различные термины, что зависит от уровня описания (теория или практика) и системы (Access, SQL Server, dBase). В табл. 2.3 приве­дена сводная информация об используемых терминах.

Таблица 2.3. Терминология баз данных

Теория БД____________ Реляционные БД_________ SQL Server __________

Отношение (Relation) Таблица (Table) Таблица (Table)

Кортеж (Tuple) Запись (Record) Строка (Row)

Атрибут (Attribute)Поле (Field)_______________ Столбец или колонка (Column)

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

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

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

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

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

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

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

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

Коротко о важном.

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

Первая нормальная форма (1НФ)

• отсутствуют повторяющиеся группы данных
• гарантируется элементарности(atomicity) данных (все данные являются автономными и независимыми).

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

Вторая нормальная форма (2НФ)

• таблица удовлетворяет условиям 1НФ
• каждый столбец зависит от всего ключа, а не от его части.

Третья нормальная форма (3НФ)

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

Другие нормальные формы, не имеющие особой практической ценности:

Нормальная форма Бойса-Кодда(Boyce-Codd)

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

Четвертая нормальная форма

Предназначена для решения вопроса с многозначными зависимостями. Такие ситуации возникают, если в приведенной к 3НФ таблице один столбец составного первичного ключа зависит от другого столбца первичного ключа.

Пятая нормальная форма

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

Шестая нормальная форма (нормальная форма доменного ключа)

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

Отношения.

Однажды я услышал от женщин, что мужчины
немедленно стараются покинуть помещение, в котором
прозвучало слово "отношения". <...> ключом к успеху
отношений является осведомленность каждого о своей роли
в данном отношении, а также о правилах и ограничениях,
налагаемых данным отношением.
(С)Robert Viera, “Professional SQL Server 2000 Programming”

Типы отношений

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

Объединения

INNER JOIN

Исключающее объединение (exclusive join). В результат выборки попадают только те записи таблиц, у которых есть соответствия в парной таблице по заданному условию.

LEFT|RIGHT JOIN

Включающее объединение (inclusive join). В результат выборки попадают записи из таблицы, стоящей слева/справа от JOIN соответственно. При этом данные из недостающей «парной» записи будут заполнены NULL .
FROM left_table LEFT JOIN right_table – включены все записи из левой таблицы left_table
FROM left_table RIGHT JOIN right_table – включены все записи из правой таблицы right_table

FULL JOIN

Включающее объединение (inclusive join). В результат выборки попадают не только записи, которые имеют соответствие в другой таблице, но и записи из обоих таблиц, для которых в соответствие в другой таблице не найдено. При этом данные из недостающей «парной» записи будут заполнены NULL.

CROSS JOIN

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

Принципы упорядочивания нескольких JOIN ’ов

В случае, если необходимо произвести объединение нескольких таблиц, нужно помнить о двух принципах:

1. Все объединения левее JOIN воспринимаются как одиночная таблица для включения или исключения из запроса.
2. Все объединения ПРАВЕЕ JOIN ТАКЖЕ воспринимаются как одиночная таблица для включения или исключения из запроса.

Следствием из этих принципов является следующая рекомендация для формирования сложных объединений:

• Везде, где только можно, следует использовать INNER JOIN.
• Если возникает необходимость использования OUTER JOIN – их нужно ставить последними, а в начале объединения размещаются INNER JOIN.

P.S. Все вышеизложенное является общими "постулатами" теории реляционных баз данных, не привязанными к особенностям определенных СУБД.