Локальная модель

Файл-серверная модель

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

Количество клиентов ограничено десятками.

Плюсы:

1. Многопользовательский режим работы с данными;

2. Удобство централизованного управления доступом;

3. Низкая стоимость разработки;

Минусы:

1. Низкая производительность;

2. Низкая надежность;

3. Слабые возможности расширения;

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

надежность приложения.

Модель удаленного доступа

Модель сервера данных

Модель телеобработки

Модель сервера приложений

2.​ Архитектура базы данных. Физическая и логическая независимость

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

В процессе научных исследований, посвященных тому, как именно должна быть устроена СУБД , предлагались различные способы реализации. Самым жизнеспособным из них оказалась предложенная американским комитетом по стандартизации ANSI (American National Standards Institute) трехуровневая система организации БД , изображенная на рис. 2:

Рис. 2. Трехуровневая модель системы управления базой данных, предложенная ANSI

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

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

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

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

Выделение концептуального уровня позволило разработать аппарат централизованного управления базой данных.

3.​ Модели данных.

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

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

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

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

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

4.​ Основные определения реляционной модели данных

Реляционная модель данных – логическая модель данных. Впервые была предложена британским учёным сотрудником компании IBM Эдгаром Франком Коддом (E. F. Codd). В настоящее время эта модель является фактическим стандартом, на который ориентируются практически все современные коммерческие СУБД.

Кристофер Дейт определил три составные части реляционной модели данных:

§ структурная

§ манипуляционная

§ целостная

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

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

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

Структура реляционной модели данных

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

Основные компоненты реляционного отношения

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

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

Именованное множество пар "имя атрибута – имя домена" называется схемой отношения . Мощность этого множества - называют степенью или "арностью" отношения. Набор именованных схем отношений представляет из себя схему базы данных .

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

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

5.​ Жизненный цикл базы данных. Этапы ЖЦ БД.

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

1. Исследование и анализ проблемы, для решения которой создаётся база данных.
2. Построение Инфологической и Даталогической модели.
3. Нормализация полученных Инфологических и Даталогических моделей. По окончании этого этапа, как правило получают заготовки таблицы БД и набор связей между ними (первичные и вторичные ключи)
4. Проверка целостности БД (Целостность базы данных)
5. Выбор физического способа хранения и эксплуатации (тех. средства) базы данных.
6. Проектирование входных и выходных форм.
7. Разработка интерфейса приложения.
8. Функциональное наполнение приложения
9. Отладка: проверка на корректность работы функционального наполнения системы
10. Тестирование: тест на корректность ввода вывода данных, тест на максимальное количество активных сессий и т. д.
11. Ввод в эксплуатацию: отладка ИТ-инфраструктуры, обучение пользователей и ИТ-персонала.
12. При необходимости добавления выходных форм и дополнительной функциональности. В случае если необходимы более серьёзные изменения, следует повторить все шаги с первого.
13. Вывод из эксплуатации: перенос данных в новую СУБД.

6.​ Основные свойства единиц информации. Составная единица информации. Описание структуры СЕИ. Показатели

Составная единица информации (СЕИ) – это набор из атрибутов и, возможно других СЕИ. Определение СЕИ рекурсивно. База данных тоже ЕИ. Множество атрибутов объединяются в одну СЕИ по следующим признакам:

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

Значения атрибутов, входящих в СЕИ, возникают одновременно, связаны арифметическими или логическими отношениями.

Простейшая характеристика СЕИ представлена именем, структурой и значением.

Имя – обозначение СЕИ в процессах обработки информации

Структура – вхождение одних единиц информации в состав других единиц

информации.

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

Описание структуры СЕИ

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

Показатель

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

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

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

Структура показателя:

П.(Р1, Р2,...,Рк, Q),

где Q - атрибут-основание, Р1, Р2,...,Рк - атрибуты- признаки. Таким образом, в показателях отражаются количественные свойства объектов и процессов.

Минимальный набор атрибутов показателя должен содержать:

1. Атрибуты отображающие идентификаторы объектов

2. Атрибуты, отображающие признак времени

3. Атрибут, отображающий некоторое количественное свойство объекта или взаимодействия.

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

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

2. Если значение атрибута текстовое, то это признак

3. Если атрибут обозначает предмет, это признак

4. Если атрибут в некотором показателе является признаком, то он будет играть эту роль и в других показателях.

5. Если показатели описывают сходные процессы, то их призначные части совпадают.

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

7.​ Операции над СЕИ: нормализация, свертка, декомпозиции, композиция, выборка, корректировка.

Нормализация – операция перехода от СЕИ с произвольной структурой к СЕИ с двухуровневой структурой. Одновременно происходит перекомпоновка значений СЕИ. Общее число значений в нормализованной СЕИ равно произведению размерностей всех СЕИ в исходном описании структуры.

Свёртка – это преобразование составной единицы информации с двухуровневой структурой в составную единицу информации с произвольной многоуровневой структурой. Свёртка нормализованной структуры может быть произведена в исходную в это смысле нормализация и свёртка взаимно-обратные операции.

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

Композиция – это операция преобразования нескольких составных единиц информации с различными структурами в одну СЕИ. Операция композиции обратна декомпозиции и точно определяется только для нормализованных исходных составных единиц информации. Условие выполнения операции композиции двух СЕИ – это наличие атрибутов, по которым они связаны.

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

Корректировка – это выполнение одной из следующих операций:

1. Добавление нового значения

2. Исключение существующего значения

3. Замена некоторого значения на новое

Возможны более сложные режимы корректировки, например, внесение изменений в

несколько СЕИ одновременно.

8.​ Два класса отношений: объектное и связное. Ключи отношений. Индексы.

Операции над отношениями:

1. Традиционные операции (объединение, пересечение, разность, декартово произведение, деление)

2. Специальные реляционные операции (проекция, соединение, выбор) Эти операции реализуются с помощью специальных языков, которые делятся на два класса:

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

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

Различают 2 класса отношений в зависимости от содержания:

1. Объектное отношение

2. Связное отношение

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

1. Запись должна однозначно определяться значением ключа

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

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

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

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

9.​ Нормализация отношений. Требования при группировке атрибутов в отношения в реляционной БД.

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

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

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

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

· корректировка отношений не должна приводить к двусмысленности или потере информации,

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

Удовлетворение этих требований достигается нормализацией отношений БД.

10.​ Функциональные зависимости. Нормальные формы.

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

Например, пусть в отношении R1 имеются 2 атрибута А и В. Атрибут В функционально зависит от атрибута А, если в любой момент времени каждое значение атрибута А соответствует единственному значению атрибута В. Обозначается А→В (если нет зависимости, то А В).

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

Если не ключевой атрибут зависит только от части ключа, то говорят о частичной зависимости .

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

Каждая НФ ограничена определенным типом функциональной зависимости и устраняет аномалии при выполнении Оп при рассмотрении БД.

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

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

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

необходимость поиска и изменения значений расценки во всех кортежах;

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

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

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

2) построить проекцию на часть составного ключа и атрибуты, зависящие от этой части.

Если для атрибутов A, B,C выполняются условия A→B и B→C, но обратная зависимость отсутствует, то С зависит от А транзитивно, т.е. можно говорить о транзитивной зависимости. Наличие транзитивных зависимостей порождает неудобства и аномалии следующего характера:

1) Дублирование информации о телефоне для нескольких рабочих

2) Проблема поиска и контроля при изменении номера телефона.

Таким образом, 2НФ также может требовать дальнейших преобразований.

Отношение находится в 3НФ, если оно находится во 2НФ и нем отсутствуют транзитивные зависимости не ключевых атрибутов от ключа. БД находится в 3НФ, если все ее отношения имеют 3НФ.

Алгоритм получения 3НФ:

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

Алгоритм получения отношений в ЗНФ обладает следующими свойствами:

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

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

Результат декомпозиции в ЗНФ обычно содержит меньше значений атрибутов, чем исходное отношение R (происходит уменьшение избыточности

Алгоритм состоит из следующий шагов:

1) Получить исходное множество функциональных зависимостей для атрибутов рассмотренной БД.

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

3) Для каждой функциональной зависимости, полученной на 2 шаге создать проекцию исходных отношений, R[X], где X – объединение атрибутов из левой и правой частей функциональной зависимостей.

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

БКНФ (Бойса-Кодда)

Считается, что отношение находится в нормальной форме БК, если оно находится в 3НФ и в нем отсутствуют зависимости ключевых атрибутов от неключевых.

Отношение находится в 4НФ, если оно находится в НФБК и в нем отсутствуют многозначные зависимости не являющиеся функциональными.

5НФ . Отношение R находится в пятой нормальной форме (5НФ ) тогда и только тогда, когда любая имеющаяся зависимость соединения является тривиальной .

Зависимость соединения называется нетривиальной зависимостью соединения , если выполняется два условия:

11.​ Операции над отношениями: объединение, пересечение, разность, декартово произведение.

Отношения

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

· объединение

· пересечение

· разность

· декартово произведение

· деление

· проекция

· соединение

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

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

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

ОБЪЕДИНЕНИЕ (R U S) отношений R и S представляет собой множество кортежей, которые принадлежат R или S, либо им обоим. Операция объединения выполняется над двумя совместимыми отношениями.

ПЕРЕСЕЧЕНИЕ. Результат пересечения R и S содержит только те кортежи первого отношения R, которое есть во втором S.

РАЗНОСТЬ. Результат вычитания (R-S) включает только те кортежи первого отношения R, которых нет во втором S.

ДЕКАРТОВО ПРОИЗВЕДЕНИЕ (R x T). Здесь операнды-отношения R и T могут иметь разные схемы: Степень результирующего отношения (R x T) равна сумме степеней отношений операндов (R и T), а мощность - произведение их мощностей.

12.​ Операции над отношениями: деление.

ДЕЛЕНИЕ (R / T). Операция в некотором смысле обратна операции "декартово произведение". Отношение "делимое" (R) должно содержать подмножество атрибутов отношения "делитель" (T). Результирующее отношение (R / T) содержит только те атрибуты делимого, которых нет в делителе. В него включают только те кортежи, декартово произведение которых с делителем содержатся в делимом.

13.​ Операции над отношениями: проекция, выборка, соединение.

ПРОЕКЦИЯ. Эта операция в отличие от всех предыдущих является унарной, т.е. выполняется над одним отношением (R). Результирующее отношение П (R) включает часть атрибутов исходного, на которые выполняется проекция. Кортежи-дубликаты отсутствуют.

Где X – список атрибутов в схеме отношения.

СОЕДИНЕНИЕ. Операция соединения выполняется над двумя отношениями (R и S). В каждом отношении выделяется атрибут, по которому будет производиться соединение. В качестве атрибута для соединения выберем атрибут B. Результирующее отношение включает все атрибуты первого отношения (R) и второго отношения (S):

ВЫБОР. Операция выполняется над одним отношением (R). Результирующее отношение (OB=b(R)) содержит подмножества кортежей, выбранных по некоторому условию (B = b).

14.​ Проектирование БД (архитектура ANSI / SPARC)

Архитектура ANSI-SPARC (также 3х-уровневая архитектура ) определяет принцип, согласно которому рекомендуется строить системы управления базами данных(СУБД).

Проект архитектуры был выдвинут в 1975 году подкомитетом SPARC ANSI.

3 уровня СУБД:

1. внешний (пользовательский)
2. промежуточный (концептуальный )
3. внутренний (физический)

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

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

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

15.​ Инфологическое моделирование. Модель «сущность-связь» (ER-модель)

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

ER-модель (Entity-Relationship Model – модель «сущность-связь») - представление ИМ, основывающееся на структурных элементах «сущность», «свойство», «связь».

Сущности и свойства

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

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

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

Простое свойство - состоит из одного компонента с независимым существованием.

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

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

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

Связь - описание связанности двух сущностей и их экземпляров.

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

1. отношение “один к одному” (1:1) означает, что каждая запись одной таблицы соответствует только одной записи в другой таблице;

2. отношение “один ко многим” (1:М) возникает, когда одна запись взаимосвязана со многими другими;

3. отношение “многие к одному” означает, что многие записи связаны с одной (М:1);

4. отношение “многие ко многим” (M:N) возникает между двумя таблицами в тех случаях, когда:

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

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

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

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

Ассоциация может использоваться для:

· Реализации связи М:М

· Связывания трех и более сущностей

· Хранения дополнительной информации о связи

· Последовательность инфологического проектирования:

· Определение сущностей

· Установление подчиненности сущностей и формирование сложных

объектов

· Установление связей и определение ассоциаций

· Определение свойств сущностей

· Определение идентификаторов

16.​ Критерии оценки качества логической модели данных. Переход к реляционной модели данных (6 правил)

Критерии оценки качества логической модели данных

Адекватность базы данных предметной области
База данных должна адекватно отражать предметную область. Это означает, что должны выполняться следующие условия:
1. Состояние базы данных в каждый момент времени должно соответствовать состоянию предметной области.
2. Изменение состояния предметной области должно приводить к соответствующему изменению состояния базы данных
3. Ограничения предметной области, отраженные в модели предметной области, должны некоторым образом отражаться и учитываться базе данных.
Легкость разработки и сопровождения базы данных
Практически любая база данных, за исключением совершенно элементарных, содержит некоторое количество программного кода в виде триггеров и хранимых процедур.
Хранимые процедуры - это процедуры и функции, хранящиеся непосредственно в базе данных в откомпилированном виде и которые могут запускаться пользователями или приложения-ми, работающими с базой данных.
Триггеры - это хранимые процедуры, связанные с некоторыми событиями, происходящими во время работы базы данных. В качестве таких событий выступают операции вставки, обновления и удаления строк таблиц. Если в базе данных определен некоторый триггер, то он запускается автоматически всегда при возникновении события, с которым этот триггер связан.
Скорость операций обновления данных (вставка, обновление, удаление)
На уровне логического моделирования мы определяем реляционные отношения и атрибуты этих отношений. На этом уровне мы не можем определять какие-либо физические структуры хранения (индексы, хеширование и т.п.). Единственное, чем мы можем управлять - это распределением атрибутов по различным отношениям. Можно описать мало отношений с большим количеством атрибутов, или много отношений, каждое из которых содержит мало атрибутов. Таким образом, необходимо попытаться ответить на вопрос - влияет ли количество отношений и количество атрибутов в отношениях на скорость выполнения операций обновления данных. Такой вопрос, конечно, не является достаточно корректным, т.к. скорость выполнения операций с базой данных сильно зависит от физической реализации базы данных. Тем не менее, попытаемся качественно оценить это влияние при одинаковых подходах к физическому моделированию.
Таким образом, можно принять допущение, что чем больше атрибутов имеют отношения, разработанные в ходе логического моделирования, тем медленнее будут выполняться операции обновления данных, за счет затраты времени на перестройку большего количества индексов.
Скорость операций выборки данных
Одно из назначений базы данных - предоставление информации пользователям. Информация извлекается из реляционной базы данных при помощи оператора SQL - SELECT. Одной из наиболее дорогостоящих операций при выполнении оператора SELECT является операция соединение таблиц. Таким образом, чем больше взаимосвязанных отношений было создано в ходе логического моделирования, тем больше вероятность того, что при выполнении запросов эти отношения будут соединяться, и, следовательно, тем медленнее будут выполняться запросы. Таким образом, увеличение количества отношений приводит к замедлению выполнения операций выборки данных, особенно, если запросы заранее неизвестны.

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

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

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

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

Правило 4 . Если степень бинарной связи 1:N, и класс принадлежности n-связной сущности является обязательным, то достаточно построить два отношения - по одному на каждую сущность. При этом ключ каждой сущности является первичным ключом соответствующего отношения, а ключ 1-связной сущности добавляется в отношение для n -связной сущности в качестве атрибута.

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

Отметим, что если степень бинарной связи 1:N, то фактором, определяющим выбор одного из правил (правила 4, 5), является класс принадлежности n-связной сущности. Класс принадлежности 1-связной сущности не влияет на конечный результат декомпозиции. В ситуации правила 4 имеет место проблема нуль-значений по атрибуту Предмет, в ситуации правила 5 имеет место проблема нуль-значений по атрибутам Предмет и Преподаватель. Поэтому во избежание дублирования и нуль-значений в ситуации правил 4 и 5 необходимо строить два и три результирующих отношения соответственно. Миграция ключа 1-связной сущности выполняется для восстановления исходного отношения при соединении.

Если степень бинарной связи N:M, то во избежание дублирования и нуль-значений необходимо всегда строить три отношения. Сформулируем шестое правило.

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

17.​ Принципы поддержки целостности в реляционных моделях данных. Структурная целостность. Проблема Null значений.

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

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

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

<имя атрибута>IS NULL и <имя атрибута> IS NOT NULL.

Если в данном кортеже (в данной строке) указанный атрибут имеет неопределенное значение, то предикат IS NULL принимает значение TRUE (Истина), а предикат IS NOT NULL - FALSE(Ложь), в противном случае предикат IS NULL принимает значение FALSE, а предикат IS NOT NULL принимает значение TRUE. Ведение Null значений вызвало необходимость модификации классической двузначной логики и превращения ее в трехзначную. Все логические операции, производимые с неопределенными значениями, подчиняются этой логике в соответствии с заданной таблицей истинности.

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

А	В	Not A	A & B	А v B
TRUE	TRUE	FALSE	TRUE	TRUE
TRUE	FALSE	FALSE	FALSE	TRUE
TRUE	Null	FALSE	Null	TRUE
FALSE	TRUE	TRUE	FALSE	TRUE
FALSE	FALSE	TRUE	FALSE	FALSE
FALSE	Null	TRUE	FALSE	Null
Null	TRUE	Null	Null	TRUE
Null	FALSE	Null	FALSE	Null
Null	Null	Null	Null	Null

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

Логическое выражение > IS {TRUE | FALSE | UNKNOWN}

18.​ Принципы поддержки целостности в реляционных моделях данных. Языковая целостность. Ссылочная целостность. (продолжение 17 вопроса)

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

В-третьих , это поддержка ссылочной целостности (Declarative Referential Integrity, DRI), означает обеспечение одного из заданных принципов взаимосвязи между экземплярами кортежей взаимосвязанных отношений:

• кортежи подчиненного отношения уничтожаются при удалении кортежа основного отношения, связанного с ними.
• кортежи основного отношения модифицируются при удалении кортежа основного отношения, связанного с ними, при этом на месте ключа родительского отношения ставится неопределенное Null значение.

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

19.​ Семантическая поддержка целостности. Виды декларативных ограничений целостности

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

1. В библиотеке должны быть записаны читатели не моложе 17 лет.
2. В библиотеке присутствуют книги, изданные начиная с 1960 по текущий год.
3. Каждый читатель может держать на руках не более 5 книг.
4. Каждый читатель при регистрации в библиотеке должен дать телефон для связи: он может быть рабочим или домашним.

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

Выделяются следующие виды декларативных ограничений целостности:

§ Ограничения целостности атрибута: значение по умолчанию, задание обязательности или необязательности значений (Null), задание условий на значения атрибутов.

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

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

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

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

20.​ Транзакции. Триггеры и хранимые процедуры.

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

Транзакция обладает четырьмя важными свойствами, известными как свойства А СИД:

(А) Атомарность. Транзакция выполняется как атомарная операция - либо выполняется вся транзакция целиком, либо она целиком не выполняется.

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

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

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

Набор примитивов

- BEGIN_TRANSACTION ; границы

- END_TRANSACTION ; транзакции

- ABORT_TRANSACTION;

- WRITE.

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

Подана команда BEGIN TRANSACTION;

Подана команда ABORT_TRANSACTION (откатить транзакцию);

Произошло отсоединение пользователя от СУБД;

Произошел сбой системы.

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

Триггеры позволяют:

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

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

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

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

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

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

SQL для триггеров и хранимых процедур содержит множество операторов императивного программирования:

Конкатенацию строк,

Арифметические операции,

Операции сравнения,

Логические (not, and, or),

Операторы структурного программирования (IF, FOR, WHILE),

Объявление переменных (DECLARE),

Эти операторы используются совместно с операторами декларативного программирования INSERT, UPDATE, DELETE и SELECT.

В современных СУБД код хранимых процедур и триггеров может писаться на смеси диалектов SQL и языков высокого уровня, например, в Oracle – на PL/SQL или Java. Фактически запросы, написанные на декларативном языке, вкладываются в процедуры, написанные на императивном языке

Министерство образования Российской Федерации Министерство образования Республики Таджикистан

Российско-Таджикский (славянский) Университет

Кафедра «И и ИС»

Курсовая работа

по дисциплине: Базы данных

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

Душанбе – 2008

План

Введение

1 Модель данных

2 Базовые понятия реляционной модели данных

3 Общие представления о модели данных

Заключение

Список используемой литературы

Введение

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

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

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

1 Модель данных

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

Модели данных определяются:

a) способами организации данных.

b) ограничением ценности данных.

c) операциями с данными.

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

Рассмотрим 3 основных типа моделей данных: иерархическую, сетевую и реляционную.

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

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

А Уровень 1

В1 В2 В3 В4 В5 Уровень 2

С1 С2 С3 С4 С5 С6 С7 С8 Уровень 3

Рис. 1

К основным понятиям иерархической структуры относятся: уровень, элемент (узел), связь.

Узел – это совокупность атрибутов данных, описывающих некоторый объект. На схеме иерархического дерева узлы представляются вершинами графа. Каждый узел на более низком уровне связан только с одним узлом, находящимся на более высоком уровне. Иерархическое дерево имеет только одну вершину (корень дерева), не подчинённую никакой другой вершине и находящуюся на самом верхнем (первом) уровне. Зависимые (подчинённые) узлы находятся на втором, третьем и т.д. уровнях. Количество деревьев в базах данных определяется числом корневых записей. К каждойдятся на втором, третьемершине и находящуюся на самом верхнем 9первом) уровне. ровне. Записи базы данных существует только 1 иерархический путь от корневой записи. Например, как видно на рисунке 1 для записи С4 путь проходит через записи А и В3.

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

b) Ограничение целостности - целостность ссылок между предком и потомком с учетом основного правила: никакой потомок не может существовать без предка.

Примеры: 1) ОКА 3)TOTAL

2)ИНЭС 4) IMS

с) Операции над данными:

Найти указанное дерево.

Перейти от одного дерева к другому.

Перейти от одной записи к другой.

Перейти от одной записи к другой в порядке обхода иерархии.

Удаление текущей записи.

Институт (специальность, название, ректор)

Рис. 3 Сетевая структура базы данных в виде графа

Студент (номер зачётной книжки , фамилия, группа)

Работа (шифр ,

руководитель,

Рис. 4.

Примером сложной сетевой структуры может служить структура базы данных, содержащей сведения о студентах, участвующих в научно – исследовательских работах (НИР). Возможно участие одного студента в нескольких НИР, а также участие нескольких студентов в разработке одной НИР. Графическое изображение описанной в примере сетевой структуры, состоящей только из двух типов записей, показано на рисунке 4. Единственное отношение представляет собой сложную связь между записями в обоих направлениях.

с) Операции над данными сетевой модели данных:

Найти конкретную запись в наборе однотипных записей.

Перейти от узла высшего уровня к первому узлу низшего по некоторой связи.

Перейти к следующему узлу по некоторой связи.

Создать новую запись.

Уничтожить запись.

Модифицировать запись.

Включить 1 связь.

Исключить из связи.

Переставить в другую связь.

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

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

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

Понятие реляционной (англ. relation – отношение) связано с разработками известного американского специалиста в области систем баз данных Е. Кодда.

2 Базовые понятия реляционной модели данных

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

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

Целочисленные типы;

Вещественные типы;

Строковые типы;

Типы данных для денежных величин;

Типы данных для временных величин;

Типы двоичных объектов (не имеет аналогов в языках программирования, и обозначаются Blob)

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

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

Атрибуты, схема отношения, схема базы данных

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

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

Степень отношения - это число его атрибутов. Отношение степени один называют унарным, степени два - бинарным, степени три - тернарным,..., а степени п - n-арным.

Схемой базы данных называется множество именованных схем отношений.

Кортеж

Кортеж, соответствующий данной схеме отношения, представляет собой множество пар {имя атрибута, значение}, которое содержит одно вхождение каждого имени атрибута, принадлежащего схеме отношения. «Значение» является допустимым значением домена данного атрибута (или типа данных, если понятие домена не поддерживается). Тем самым степень кортежа, то есть число элементов в нем, совпадает со степенью соответствующей схемы отношения. Иными словами, кортеж - это набор именованных значений заданного типа. Схему отношения иногда называют также заголовком отношения, а отношение как набор кортежей - телом отношения. Понятие схемы отношения напоминает понятие структурного типа данных в языках про граммирования (структура в С/С++, запись в Pascal). Однако в реляционных базах данных имя схемы отношения всегда совпадает с именем соответствующего отношения-экземпляра. В классических реляционных базах данных после определения схемы базы Данных изменяются только отношения-экземпляры. В них могут появляться новые и удаляться или модифицироваться существующие кортежи. Однако во многих реализациях допускается и изменение схемы базы данных: определение новых и изменение существующих схем отношения. Это принято называть эволюцией схемы базы данных.

Ключи отношения

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

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

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

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

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

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

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

Естественный ключ - ключ, в который включены значимые атрибуты и который, таким образом, содержит информацию.

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

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

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

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

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

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

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

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

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

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

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

Связанные отношения

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

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

Внешние ключи отношения

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

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

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

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

Условия целостности данных

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

· Важнейшими ограничениями целостности данных являются: категорийная целостность;ссылочная целостность.

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

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

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

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

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

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

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

Типы связей между таблицами

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

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

· один к одному - каждой записи одной таблицы соответствует только одна запись другой таблицы;

· один ко многим - одной записи главной таблицы могут соответствовать несколько записей подчиненной таблицы;

· многие к одному - нескольким записям главной таблицы может соответствовать одна и та же запись подчиненной таблицы;

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

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

Основные свойства отношений

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

3 Общие представления о модели данных

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

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

Элемент данных (поле) – наименьшая поименованная единица данных. Используется для представления значения атрибута.

Запись – поименованная совокупность полей. Используется для представления совокупности атрибутов сущности (записи о сущности).

Экземпляр записи – запись с конкретными значениями полей.

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

Файл – поименованная совокупность экземпляров записей одного типа. Используется для представления однородного набора сущностей.

Набор файлов – поименованная совокупность файлов, обрабатываемых в системе. Используется для представления нескольких наборов сущностей.

Введем понятие «группа», обобщающее понятия «агрегат» и «запись».

Группа – это поименованная совокупность элементов данных или элементов данных и других групп.

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

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

База данных – поименованная совокупность экземпляров групп и групповых отношений.

Для представления группового отношения используется две формы:

а) Графовая . Группы изображаются вершинами графа, связи между группами – дугами, направленными от группы-владельца к группе-члену с указанием имени отношения и коэффициента.

По типу графов различают:

􀂃 иерархическую модель (граф без циклов – дерево);

􀂃 сетевую модель (ориентированный граф общего вида).

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

Модель данных описывается следующим образом:

􀂃 определяются типы и характеристики логических структур данных

(полей, записей, файлов);

􀂃 описываются правила составления структур более общего типа из структур более простых типов;

􀂃 описываются возможные действия над структурами и правила их

выполнения, включающие:

− основные элементарные операции над данными;

− обобщенные операции (процедуры);

− средства контроля относительно простых условий корректности ввода данных (ограничения);

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

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

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

Заключение

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

Список используемой литературы

1. Компьютеры в офисе и дома: Реляционные БД: 2004г. 228 стр.

2. Мичи Д., Джонатон Р. Реляционные СУБД. 2004г. №8, стр. 4

3. www.libbooks.ru (2006 по 2008г. Раздел: База данных).

4. www.bankreferatov.ru (2004 по 2008г. Раздел: База данных).

5. Джонс Э., Саттон Д. пользователя Office 97./ К.: Диалектика, 1999г.

6. Петров В.Н. Информационные системы: учебное пособие для студентов высших учебных заведений, 2003г. 2е изд. стр. 139

Лекция 12

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

Нормализация. Нормальные формы.

Технология отображение концептуальной модели базы данных на реляционную модель данных

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

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

1.1. Структурный компонент реляционной модели

С точки зрения структуры данных реляционная модель является удобной и наиболее привычной формой представления данных в виде таблицы. Понятию «таблица» соответствует понятие «отношение» (relation). Отсюда и произошло название модели – реляционная. Т.е., применительно к базам данных понятия «реляционная БД» и «табличная БД» по существу являются синонимами. В отличие от иерархической и сетевой модели, такой способ представления

1) понятен пользователю-непрограммисту;

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

3) обеспечивает необходимую гибкость при обработке непредвиденных запросов.

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

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

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

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

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

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

Сформулируем правила назначения первичных ключей сущностей:

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

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

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

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

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

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

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

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

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

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

12.1.2. Управляющий компонент реляционной модели

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

12.1.3. Целостность данных (слайд 5 )

Целостность на уровне доменов

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

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

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

Целостность на уровне отношений

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

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

Обычно для ситуации наличия неизвестных или неполных данных используются типы данных, пополненные так называемым NULL -зпачением.

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

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

Следует отметить, что большинство СУБД вполне позволяют создавать таблицы и без первичных ключей. Однако нарушение правила целостности отношений на практике сразу дает о себе знать. Например, для СУБД MS SQL-сервер станет невозможным доступ к данным по технологии OLE DB Provider .

Целостность внешних ключей (целостность на уровне БД)

Различные объекты предметной области, информация о которых хранится в базе данных, всегда взаимосвязаны. Наиболее типичный способ подобной связи между отношениями описывается ограничением внешнего ключа (FK , Foreign Key ).

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

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

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

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

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

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

В целом концепция реляционной модели определяется следующими двенадцатью правилами Кодда (слайд 6 ):

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

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

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

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

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

6. Правило обновления представлений. Все представления, которые теоретически можно обновить, должны быть доступны для обновления.

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

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

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

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

11. Правило независимости распространения. Реляционная СУБД не должна зависеть от потребностей конкретного клиента.

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

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

Правило 3 требует, чтобы отсутствующие данные можно было представить с помощью недействительных значений (NULL ).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

12.2.1. Функциональные зависимости

В основе процесса нормализации лежит концепция функциональной зависимости. Функциональная зависимость описывает связь между атрибутами отношения: если в отношении R , содержащем атрибуты A и B , атрибут B функционально зависит от атрибута A , то каждое отдельное значение атрибута A связано только с одним значением атрибута B (причем в качестве A и B могут выступать группы атрибутов). Атрибут или группа атрибутов A называются при этом детерминантом функциональной зависимости (слайд 8 ).

Таким образом, при наличии функциональной зависимости A →B кортежи (строки), имеющие одинаковое значение атрибута A , совпадают и по значению атрибута B . Однако обратное не верно: одно и то же значение атрибута B может соответствовать разным значениям атрибута A . Например, из функциональной зависимости Сотрудник→Должность следует, что везде, где будет указываться сотрудник «Еремеев В.К.», ему будет соответствовать должность «Профессор», но должность «Профессор» могут иметь и другие сотрудники.

Функциональная зависимость A →B является полной функциональной зависимостью, если удаление какого-либо атрибута из группы атрибутов A приводит к потере этой зависимости. Функциональная зависимость A →B является частичной функциональной зависимостью, если в группе атрибутов A есть один или несколько атрибутов, при удалении которых эта зависимость сохраняется.

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

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

В качестве примера рассмотрим фрагмент таблицы «Прием экзаменов (зачетов)». Таблица отражает связь дисциплины и формы отчетности с фамилией преподавателя. В этой таблице существует многозначная зависимость «Дисциплина - Преподаватель»: дисциплину «Математический анализ» ведут несколько преподавателей (Раков И. И., Рыбин К. К., Карпов К. Ю.) и, соответственно, все они могут участвовать в приеме экзаменов (зачетов). Другая многозначная зависимость – «Дисциплина – Форма отчетности»: по одной и той же дисциплине может проводиться и экзамен, и зачет. При этом Форма отчетности и Преподаватель не связны функциональной зависимостью, что приводит к появлению избыточности (чтобы добавить фамилию еще одного преподавателя, придется ввести в таблицу две новых строки).

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

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

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

Реляционная таблица находится в первой нормальной форме (1НФ), если (слайд 10 )

Каждое значение любого ее атрибута является атомарным;

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

Каждый столбец уникально поименован именем атрибута и содержит текущее значение этого атрибута;

Каждый атрибут ассоциирован с определенным доменом (типом данных).

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

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

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

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

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

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

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

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

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

12.3. Процедура нормализации (слайд 14 )

Процедура приведения таблиц к 3НФ основывается на том, что единственными функциональными зависимостями в любой таблице должны быть зависимости вида А →K , где K - первичный ключ, а А - некоторый атрибут. Цель нормализации состоит в удалении других функциональных зависимостей.

Возможны два случая:

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

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

Таким образом, повторяя применение двух рассмотренных правил, для любой заданной таблицы почти во всех реальных практических ситуациях можно получить в конечном счете множество таблиц, которые находятся в 3НФ или НФБК и не содержат каких-либо функциональных зависимостей вида, отличного от А →К .

12.4. Получение реляционной схемы из ER-диаграммы (слайд 17 )

1. Каждая простая сущность превращается в таблицу (отношение). Имя сущности становится именем таблицы.

2. Связь «многие ко многим» рассматривается как сущность-связь и превращается в таблицу (отношение). Тем самым связь «многие ко многим» трансформируется в две связи «многое к одному».

3. Каждый атрибут становится возможным столбцом с тем же именем. Столбцы, соответствующие необязательным атрибутам, могут содержать неопределенные значения; столбцы, соответствующие обязательным атрибутам, - не могут. Если атрибут является множественным, то для него строится отдельное отношение.

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

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

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

7. Если в концептуальной схеме присутствуют подтипы, то возможны два варианта.

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

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

8. Если остающиеся внешние ключи все принадлежат одному домену, т.е. имеют общий формат, то создаются два столбца: идентификатор связи и идентификатор сущности. Столбец идентификатора связи используется для различения связей. Столбец идентификатора сущности используется для хранения значений уникального идентификатора сущности на дальнем конце соответствующей связи.

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

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

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

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

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

Пример отношения (Заборов)

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

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

• Объединение;
• Пересечение;
• Вычитание;
• Декартово произведение;
• Выборка;
• Проекция;
• Соединение;
• Деление.

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

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

Пример операций над кортежами (Заборов)

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

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

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

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

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

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

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