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

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

Разработка новых архитектур СУБД. Современные ИС требуют от СУБД возможности хранить и обрабатывать данные огромных объемов. В связи с этим говорят о необходимости организации нового уровня иерархии носителей - третичной памяти. Устройствами третичной памяти могут быть устройства в виде стоек магнитных дисков или лент с автоматически сменяемыми носителями. Примером может быть буферная система VSM (Virtual Storage Manager) корпорации Storage Tek. Эта система накапливает и сохраняет данные на жестких дисках в буфере данных, где они складируются в виде виртуальных томов на магнитных лентах (до 100 000 томов на каждом дисковом буфере). Максимальная скорость передачи данных пользователя - до 45 Мбайтов/с.

Расширение областей применения БД. К новым областям применения можно отнести следующие два класса задач:

1. Обработки сверхбольших объемов информации. Примером является проектируемая информационная система наблюдения Земли EOS (Earth Observing System), основным элементом которой является база данных EOS DIS (EOS Data and Information System) - система данных и информации.

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

3. Улучшение сервиса конечных пользователей, администраторов и разработчиков.

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

Глоссарий

В начале 1970-х годов в одной из исследовательских лабораторий компании IBM была разработана экспериментальная реляционная СУБД IBM System R, для которой затем был создан специальный язык SEQUEL, позволявший относительно просто управлять данными в этой СУБД. Аббревиатура SEQUEL расшифровывалась как Structured English QUEry Language - "структурированный английский язык запросов". Позже по юридическим соображениям язык SEQUEL был переименован в SQL. Когда в 1986 году первый стандарт языка SQL был принят ANSI (American National Standards Institute), официальным произношением стало [,es kju: ' el] - эс - кью - эл. Несмотря на это, даже англоязычные специалисты зачастую продолжают читать SQL как сиквел (по-русски также часто говорят "эс - ку - эль").

Целью разработки было создание простого непроцедурного языка, которым мог воспользоваться любой пользователь, даже не имеющий навыков программирования. Собственно разработкой языка запросов занимались Дональд Чэмбэрлин (Donald D Chamberlin) и Рэй Бойс (Ray Boyce). Пэт Селинджер (Pat Selinger) занималась разработкой стоимостного оптимизатора (cost - based optimizer), Рэймонд Лори (Raymond Lorie) занимался компилятором запросов.

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

Первыми СУБД, поддерживающими новый язык, стали в 1979 году Oracle V2 для машин VAX от компании Relational Software Inc. (впоследствии ставшей компанией Oracle) и System/38 от IBM, основанная на System/R.

Стандартизация.

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

В 1983 году Международная организация по стандартизации (ISO) и Американский национальный институт стандартов (ANSI) приступили к разработке стандарта языка SQL. По прошествии множества консультаций и отклонения нескольких предварительных вариантов в 1986 году ANSI представил свою первую версию стандарта, описанного в документе ANSI X3.135-1986 под названием "Database Language SQL" (рус. Язык баз данных SQL). Неофициально этот стандарт SQL-86 получил название SQL1. Год спустя, была завершена работа над версией стандарта ISO 9075-1987 под тем же названием. Разработка этого стандарта велась под патронажем Технического Комитета TC97 (англ. Technical Committee TC97), областью деятельности которого являлись процессы вычисления и обработки информации (англ.computing and Information Processing). Именно его подразделение, именуемое как Подкомитет SC21 (англ. Subcommittee SC21) курировало разработку стандарта, что стало залогом идентичности стандартов ISO и ANSI для SQL1 (SQL-86).

Стандарт SQL1 разделялся на два уровня. Первый уровень представлял собой подмножество второго уровня, описывавшего весь документ в целом. То есть, такая структура предусматривала, что не все спецификации стандарта SQL1 будут относиться к Уровню 1. Тем самым, поставщик, заявлявший о поддержке данного стандарта, должен был заявлять об уровне, которому соответствует его реализация языка SQL. Это значительно облегчило принятие и поддержку стандарта, поскольку производители могли реализовывать его поддержку в два этапа.

Со временем к стандарту накопилось несколько замечаний и пожеланий, особенно с точки зрения обеспечения целостности и корректности данных, в результате чего в 1989 году данный стандарт был расширен, получив название SQL89. В частности, в него была добавлена концепция первичного и внешнего ключей. ISO-версия документа получила название ISO 9075: 1989 "Database Language SQL with Integrity Enhancements" (рус. Язык баз данных SQL с добавлением контроля целостности) параллельно была закончена и ANSI-версия.

Сразу после завершения работы над стандартом SQL1 в 1987 году была начата работа над новой версией стандарта, который должен был заменить стандарт SQL89, получив название SQL2, поскольку дата принятия документа на тот момент была неизвестна. Таким образом, фактически SQL89 и SQL2 разрабатывались параллельно. Новая версия стандарта была принята в 1992 году, заменив стандарт SQL89. Новый стандарт, озаглавленный как SQL92, представлял собой по сути расширение стандарта SQL1, включив себя множество дополнений имевшихся в предыдущих версиях инструкций.

Как и SQL1, SQL92 также был разделён на несколько уровней, однако, во-впервых, число уровней было увеличено с двух до трёх, а во - вторых они получили названия вместо порядковых цифр: начальный (англ. entry), средний (англ. intermediate), полный (англ. full). Уровень "полный" как и Уровень 2 в SQL1 подразумевал весь стандарт целиком. Уровень "начальный" представлял собой подмножество уровня "средний", в свою очередь представлявшего собой подмножество уровня "полный". Уровень "начальный" был сравним с Уровнем 2 стандарта SQL1, но спецификации этого уровня были несколько расширены. Таким образом, цепочка включений уровней стандартов выглядела примерно следующим образом:

SQL1 Уровень 1 - > SQL1 Уровень 2 - > SQL92 "Начальный" - > SQL92 "Средний" - > SQL92 "Полный".

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

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

· создание в базе данных новой таблицы;

· добавление в таблицу новых записей;

· изменение записей;

· удаление записей;

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

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

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

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

запросы на создание или изменение в базе данных новых или существующих объектов (при этом в запросе описывается тип и структура создаваемого или изменяемого объекта);

· запросы на получение данных;

· запросы на добавление новых данных (записей)

· запросы на удаление данных;

· обращения к СУБД.

Основным объектом хранения реляционной базы данных является таблица, поэтому все SQL-запросы - это операции над таблицами. В соответствии с этим, запросы делятся на:

· запросы, оперирующие самими таблицами (создание и изменение таблиц);

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

Каждая таблица описывается в виде перечисления своих полей (столбцов таблицы) с указанием:

· типа хранимых в каждом поле значений;

· связей между таблицами (задание первичных и вторичных ключей);

· информации, необходимой для построения индексов.

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

· вставка новой строки;

· изменение значений полей строки или набора строк;

· удаление строки или набора строк.

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

· просмотреть полученный набор;

· изменить все записи набора;

· удалить все записи набора.

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

Описание.

Язык SQL представляет собой совокупность

· операторов;

· инструкций;

· вычисляемых функций.

Операторы.

Согласно общепринятому стилю программирования, операторы (и другие зарезервированные слова) в SQL всегда следует писать прописными буквами.

Операторы SQL делятся на:

· операторы определения данных (Data Definition Language, DDL)

CREATE создает объект БД (саму базу, таблицу, представление, пользователя и т.д.)

ALTER изменяет объект

DROP удаляет объект

· операторы манипуляции данными (Data Manipulation Language, DML)

SELECT считывает данные, удовлетворяющие заданным условиям

INSERT добавляет новые данные

UPDATE изменяет существующие данные

DELETE удаляет данные

· операторы определения доступа к данным (Data Control Language, DCL)

GRANT предоставляет пользователю (группе) разрешения на определенные операции с объектом

REVOKE отзывает ранее выданные разрешения

DENY задает запрет, имеющий приоритет над разрешением

· операторы управления транзакциями (Transaction Control Language, TCL)

COMMIT применяет транзакцию.

ROLLBACK откатывает все изменения, сделанные в контексте текущей транзакции.

SAVEPOINT делит транзакцию на более мелкие участки.

Преимущества.

Независимость от конкретной СУБД.

Несмотря на наличие диалектов и различий в синтаксисе, в большинстве своём тексты SQL-запросов, содержащие DDL и DML, могут быть достаточно легко перенесены из одной СУБД в другую. Существуют системы, разработчики которых изначально ориентировались на применение по меньшей мере нескольких СУБД (например: система электронного документооборота Documentum может работать как с Oracle, так и с Microsoft SQL Server и IBM DB2). Естественно, что при применении некоторых специфичных для реализации возможностей такой переносимости добиться уже очень трудно.

Наличие стандартов.

Наличие стандартов и набора тестов для выявления совместимости и соответствия конкретной реализации SQL общепринятому стандарту только способствует "стабилизации" языка. Правда, стоит обратить внимание, что сам по себе стандарт местами чересчур формализован и раздут в размерах (например, Core-часть стандарта SQL: 2003 представляет собой более 1300 страниц текста).

Декларативность.

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

Недостатки.

Несоответствие реляционной модели данных.

Создатели реляционной модели данных Эдгар Кодд, Кристофер Дейт и их сторонники указывают на то, что SQL не является истинно реляционным языком. В частности, они указывают на следующие проблемы SQL:

Повторяющиеся строки

Неопределённые значения (nulls)

Явное указание порядка колонок слева направо

Колонки без имени и дублирующиеся имена колонок

Отсутствие поддержки свойства "="

Использование указателей

Высокая избыточность

В опубликованном Кристофером Дейтом и Хью Дарвеном Третьем Манифесте они излагают принципы СУБД следующего поколения и предлагают язык Tutorial D, который является подлинно реляционным.

Сложность.

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

Отступления от стандартов.

Несмотря на наличие международного стандарта ANSI SQL-92, многие компании, занимающиеся разработкой СУБД (например, Oracle, Sybase, Microsoft, MySQL AB), вносят изменения в язык SQL, применяемый в разрабатываемой СУБД, тем самым отступая от стандарта. Таким образом, появляются специфичные для каждой конкретной СУБД диалекты языка SQL.

Сложность работы с иерархическими структурами.

Ранее диалекты SQL большинства СУБД не предлагали способа манипуляции древовидными структурами. Некоторые поставщики СУБД предлагали свои решения (например, Oracle использует выражение CONNECT BY). В настоящее время в ANSI стандартизована рекурсивная конструкция WITH из диалекта SQL DB2. В MS SQL Server рекурсивные запросы появились лишь в версии MS SQL Server 2005.

Типы данных.

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

INTEGER - целое число (обычно до 10 значащих цифр и знак);

SMALLINT - "короткое целое" (обычно до 5 значащих цифр и знак);

DECIMAL (p,q) - десятичное число, имеющее p цифр (0 < p < 16) и знак; с помощью q задается число цифр справа от десятичной точки (q < p, если q = 0, оно может быть опущено);

FLOAT - вещественное число с 15 значащими цифрами и целочисленным порядком, определяемым типом СУБД;

CHAR (n) - символьная строка фиксированной длины из n символов (0 < n < 256);

VARCHAR (n) - символьная строка переменной длины, не превышающей n символов (n > 0 и разное в разных СУБД, но не меньше 4096);

DATE - дата в формате, определяемом специальной командой (по умолчанию mm/dd/yy); поля даты могут содержать только реальные даты, начинающиеся за несколько тысячелетий до н.э. и ограниченные пятым-десятым тысячелетием н.э.;

TIME - время в формате, определяемом специальной командой, (по умолчанию hh. mm. ss);

DATETIME - комбинация даты и времени;

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

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

SQL-функции.

В SQL существует ряд специальных стандартных функций (SQL-функций). Кроме специального случая COUNT (*) каждая из этих функций

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

COUNT - число значений в столбце,

SUM - сумма значений в столбце,

AVG - среднее значение в столбце,

MAX - самое большое значение в столбце,

MIN - самое малое значение в столбце.

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

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

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

Возможности SQL.

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

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

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

· указание физической организации данных;

· поддержка ограничений целостности и непротиворечивости базы данных;

· защита данных от несанкционированного доступа посредством определения пользователей (с именами и паролями) и ролей, прав доступа к данным и прав на изменение состояния базы данных;

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

· поиск данных в нескольких таблицах и упорядочение полученных результатов;

· организация резервного копирования и восстановления базы данных;

· поддержка целостности транзакций;

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

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

Приложение Б

Правила Кодда

В 1985 году в двух статьях в журнале Computer World Э.Ф. Кодд сформулировал правила, которым должны соответствовать настоящие реляционные базы данных. Всего правил было двенадцать. Несколько позже Кодд сформулировал 13-е правило и присвоил ему номер 0. Начнем рассмотрение правил с этого последнего или нулевого.

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

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

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

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

· Уникальность имени таблицы в базе данных.

· Уникальность имени столбца в таблице.

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

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

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

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

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

· Определение структуры данных.

· Определение представлений.

· Модификацию данных (содержимого таблиц).

· Определения условий целостности.

· Определение правил авторизации (идентификация прав доступа).

· Определение границ транзакций.

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

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

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

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

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

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

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

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

Размещено на Allbest.ru