Архитектура базы данных: понятие, определение, уровни. Компоненты информационной системы с базой данных и трехуровневая архитектура системы управления базой данных

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

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

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

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

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

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

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

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

В информационной системе с БД можно выделить несколько компонентов.

• 1. Пользователи - люди, которые используют информацию, находящуюся в БД. Принято выделять следующие группы пользователей: системные администраторы - отвечают за основные операции системы; администраторы базы данных - управляют работой СУБД и обеспечивают функционирование базы данных; проектировщики базы данных - разрабатывают структуру БД; системные аналитики - определяют основные функции системы базы данных и проектируют формы ввода данных, отчеты и процедуры, с помощью которых обеспечиваются доступ к данным и манипулирование ими (их добавление, изменение, удаление); программисты - создают программный код; непосредственные пользователи - используют прикладные программы для выполнения необходимых операций по автоматизации своей деятельности.
• 2. Приложения - программы пользователей, которым необходима информация из системы.
• 3. Система управления базой данных - ПО, управляющее доступом к данным и обеспечивающее указанные функциональные возможности ИС с БД.
• 4. Информация - обработанные данные (строки, хранящиеся в файлах).
• 5. Хост-система - компьютерная система, в которой хранятся файлы. Доступ к строкам данных осуществляется хост-системой. Роль СУБД состоит в том, чтобы генерировать запросы, позволяющие использовать функциональные возможности системы управления файлами хост- системы для обслуживания различных приложений. СУБД представляет собой дополнительный уровень ПО, надстроенный над программным обеспечением хост-системы.
• 6. Оборудование - все системные программные средства (универсальный компьютер, персональный компьютер, ноутбук, карманный компьютер).
• 7. Периферийные устройства - физические устройства, обеспечивающие ввод/вывод, а также электронные устройства для подключения дополнительных компьютеров и организации сети.

Графическая интерпретация ИС с БД в виде логической последовательности уровней представлена на рис. 3.1.

Рис. 3.1

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

Обычно современная СУБД содержит следующие компоненты:

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

Системы управления базой данных классифицируют по различным признакам, например: по модели данных - иерархические, сетевые, реляционные, объектно-ориентированные, объектно-реляционные; по способу размещения - локальные (все части локальной СУБД размещаются на одном компьютере), распределенные (части СУБД размещаются на двух и более компьютерах); по способу доступа к БД - файл-серверные, клиент-серверные, встраиваемые, - а также по другим признакам |9, 33].

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

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

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

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

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

В 1978 г. комитетом ANSI/SPARC (ANSI, American National Standard Institute - Национальный институт стандартизации США; SPARC,

Standard Planning and Requirements Committee - Комитет планирования стандартов и норм) официально зафиксировано различие между логическим и физическим представлением данных. В частности, была предложена обобщенная структура систем с базой данных. Эта структура получила название трехуровневой архитектуры, включающей внутренний, концептуальный и внешний уровни (рис. 3.2).

Рис. 3.2.

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

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

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

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

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

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

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

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

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

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

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

Независимость бывает двух типов:

• логическая - полная защищенность внешних схем от изменений, которые вносятся в концептуальную схему;
• физическая - защищенность концептуальной схемы от изменений, которые вносятся во внутреннюю схему.

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Размещено на http://www.allbest.ru/

1. Архитектура СУБД

Три уровня архитектуры.

Архитектура ANSI/SPARC включает три уровня: внутренний, концептуальный и внешний. В общих чертах они представляют собой следующее:

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

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

Концептуальный уровень-это «промежуточный» уровень между двумя первыми.

Внешний уровень (индивидуальные представления пользователей).

Концептуальный уровень (обобщенное представление пользователей).

Внутренний уровень (представление в памяти).

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

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

У каждого пользователя есть свой язык общения.

Для прикладного программиста это либо один из распространенных языков программирования, такой как C, COBOL или PL/1, либо специальный язык рассматриваемой системы. Такие оригинальные языки называют (неформально!) языками четвертого поколения на том основании, что машинный код, язык ассемблера и такие языки, как COBOL, можно считать языками трех первых «поколений», а оригинальные языки модернизированы по сравнению с языками третьего поколения так же, как языки третьего поколения улучшены по сравнению с языком ассемблера.

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

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

Язык обработки данных состоит из таких выполняемых операторов PL/1, которые передают информацию в и из БД; опять же, возможно, включая, новые специальные операторы.

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

Концептуальный уровень.

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

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

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

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

Теперь?перейдем к более детальному исследованию трех уровней архитектуры.

Внутренний уровень.

Третьим уровнем архитектуры является внутренний уровень. Внутреннее представление - это представление нижнего уровня всей БД; оно состоит из многих экземпляров каждого типа внутренней записи. Термин «внутренняя запись» принадлежит терминологии ANSI/SPARC и означает конструкцию, называемую хранимой записью. Внутреннее представление так же, как внешнее и концептуальное, не связано с физическим уровнем, так как в нем не рассматриваются физические области устройства хранения, такие как цилиндры и дорожки. Другими словами, внутреннее представление предполагает бесконечное линейное адресное пространство; подробности того, как адресное пространство отображено на физическое устройство хранения, очень зависят от системы и умышленно не включены в общую архитектуру.

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

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

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

Базы данных и программные средства их создания и ведения (СУБД) имеют многоуровневую архитектуру.

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

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

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

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

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

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

Основные положения этой концепции:

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

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

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

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

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

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

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

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

внутренний уровень, на котором СУБД и операционная система воспринимают данные;

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

Данная архитектура СУБД вызревала не сразу, а постепенно, в течение ряда лет. Первые предложения поступили в 1971 году от рабочей группы CODASYL (Conference on Data Systems and Languages -- Конференция по языкам и системам данных), которая обосновала необходимость использования двухуровневого подхода, построенного на основе выделения системного представления и пользовательских представлений.

В 1975 году Комитет планирования стандартов и норм SPARC (Standards Planning and Requirements Committee) Американского национального института стандартов ANSI (American National Standards Institute) предложил обобщенную структуру систем баз данных, признав необходимость использования трехуровневой архитектуры, которая и была официально признана в 1978 году.

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

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

Рис. Трехуровневая архитектура СУБД

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

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

Внешний уровень

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

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

Какой бы язык высокого уровня не использовался (он в этом случае называется базовым), он должен включать в себя и подъязык для работы с данными. Система может поддерживать любое количество подъязыков данных, любое количество базовых языков. ]Но язык__Ј(ЗЬ поддерживается практически всеми системами. Он может использоваться и как встроенный в другие языки, и как отдельный самостоятельный язык запросов.

Концептуальный уровень

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

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

Концептуальная схема должна содержать:

объекты и их атрибуты;

связи между объектами;

ограничения, накладываемые на данные;

семантическую информацию о данных;

обеспечение безопасности и поддержки целостности данных.

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

Внутренний уровень

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

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

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

На внутреннем уровне хранится следующая информация:

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

сведения о размещении записей;

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

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

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

Итак, подведем итоги.

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

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

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

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

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

2. Базы данных. Схема данных. Независимость уровней от данных

пользователь информационный запись

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

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

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

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

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

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

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

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

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

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

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

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

Таблицы и их атрибуты

Связи между таблицами

Ограничения, накладываемые на данные

Семантику данных

В концептуальной схеме данных должны быть учтены аспекты безопасности и целостности данных

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

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

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

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

То, как должно быть распределено дисковое пространство для хранения данных и индексы

Информацию о сохраненных записях

Сведения о уже имеющихся записях

Сведения о способах шифрования и сжатия данных

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

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

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

пользователь информационный хранимый запись

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

Подобные документы

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

лекция , добавлен 19.08.2013


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

курсовая работа , добавлен 21.03.2015


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

курсовая работа , добавлен 23.02.2009


Краткая история развития СУБД ORACLE, основные понятия и определения, архитектура. Принципы работы с СУБД ORACLE. Разработка баз данных, средства и технологии их реализации; возможности процедурного языка PL/SQL. Приемы администрирования СУБД ORACLE.

презентация , добавлен 14.02.2014


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

курсовая работа , добавлен 01.11.2011


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

курсовая работа , добавлен 14.02.2011


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

реферат , добавлен 27.12.2013


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

курсовая работа , добавлен 23.02.2006


Архитектура "клиент-сервер". Параллельная обработка данных в многопроцессорных системах. Модернизация устаревших информационных систем. Характерные черты современных серверных СУБД. Наиболее популярные серверные СУБД. Распределенные запросы и транзакции.

курсовая работа , добавлен 11.11.2011


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

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

О физическом размещении в памяти данных и их описаний;

О механизме поиска запрашиваемых данных;

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

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

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

Обобщенная структура связей программ и данных при использовании СУБД показана на рисунке 6.6.

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

Сущности интересующей предметно области;

Атрибуты, характеризующие неотъемлемые свойства каждой сущности;

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

Рис. 6.6. Обобщенная структура связей программ и данных в СУБД

Подход к архитектуре и описанию данных предложен комитетом ANSISPARC (Комитет планирования Стандартов и норм

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

Рис. 6.7. Трехуровневая архитектура ANSI-SPARC

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

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

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

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

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

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

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

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

1) сущности, их атрибуты и связи;

2) ограничения, накладываемые на данные;

3) семантическую информацию о данных;

4) информацию о мерах обеспечения безопасности.

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

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

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

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

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

Карта распределения дискового пространства для хранения данных и индексов;

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

Сведения о размещении записей;

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

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

На внутреннем уровне создается физическая модель.

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

В соответствии с предложениями ANSI-SPARC можно представить соответствующую трехуровневую модель данных (рис. 6.8):

Рис. 6.8. Уровни моделей данных

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

Рис. 6.9. Основные компоненты СУБД

Рассмотрим основные компоненты СУБД.

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

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

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

Препроцессор языка DML преобразует внедренные в прикладные программы DML операторы в вызовы стандартных функций базового языка. Для генерации соответствующего кода препроцессор языка DML должен взаимодействовать с процессором запросов. Язык манипулирования данными (Data Manipulation Language - DML) - совокупность языковых средств организации доступа к данным в некоторой модели данных и в соответствующих ей СУБД.

Компилятор языка DDL преобразует DDL команды в набор таблиц, содержащих метаданные. Затем эти таблицы сохраняются в системном каталоге, а управляющая информация - в заголовках файлов с данными. Язык определения данных (Data Definition Language - DDL) - формальный закон, используемый в некоторой модели данных для определения структуры данных.

Контроллер словаря управляет доступом к системному каталогу и обеспечивает работу с ним. Системный каталог доступен большинству компонентов СУБД.

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

1. Контроль прав доступа (пользователь имеет или не имеет права на затребованную операцию).

2. Процессор команд (для выполнения запроса управление передается процессору команд).

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

4. Оптимизатор запросов определяет наилучшую стратегию выполнения запроса.

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

6. Планировщик отвечает за бесконфликтное выполнение параллельных с базой данных операций.

7. Контроллер восстановления обеспечивает восстановление данных до непротиворечивого состояния после сбоя.

8. Контроллер буферов отвечает за перенос данных между ОЗУ и внешними носителями.

Рис. 6.10. Компоненты контроллера базы данных

КОНСПЕКТ ОБЗОРНОЙ ЛЕКЦИИ

Для студентов специальности
Т1002 «Программное обеспечение информационных технологий»

(Л.В. Рудикова, к.ф.-м.н., доцент)

Вопрос 31. АРХИТЕКТУРА СУБД. РЕЛЯЦИОННАЯ МОДЕЛЬ ДАННЫХ

1. Понятие базы данных.

2. Трехуровневая архитектура базы данных.

3. Жизненный цикл базы данных.

4. Архитектура СУБД.

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

6. Проектирование реляционных баз данных.

7. Нормальные формы отношений.

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

1. Понятие базы данных.

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

Информационная система – автоматическая система, организующая данные и выдающая информацию.

Информационно-управляющая система – система, обеспечивающая информационную поддержку менеджмента.

Данные – разрозненные факты.

Информация – организованные и обработанные данные.

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

Каждая СУБД должна удовлетворять следующим требованиям:

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

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

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

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

Система с базой данных состоит из следующих компонентов:

· Пользователи, т.е. люди, которые используют данные.

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

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

· Данные, т.е. строки, хранящиеся в файлах.

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

Таким образом, систему с БД можно представить в виде следующей последовательности уровней:

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

2. Трехуровневая архитектура базы данных.

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

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

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

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

Рис. Уровни СУБД

3. Жизненный цикл базы данных.

Процесс проектирования, реализации иподдержания системы базы данных называется жизненным циклом базы данных (ЖЦБД). Процедура создания системы называется жизненным циклом системы (ЖЦС).

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

ЖЦБД состоит из следующих этапов:

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

· какие прикладные программы используются, и какие функции они выполняют;

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

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

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

Информация этого этапа документируется в виде обобщенной модели данных.

2. Проверка осуществимости . Здесь определяется технологическая, операционная и экономическая осуществимость плана создания БД, т. е.:

· технологическая осуществимость – есть ли технология для реализации запланированной БД?

· операционная осуществимость – есть ли средства и эксперты, необходимые для успешного осуществления плана создания БД?

· экономическая целесообразность – можно ли определить выводы? Окупится ли запланированная система? Можно ли оценить издержки и выгоду?

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

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

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

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

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

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

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

5. Реализация – процесс превращения концептуальной модели в функциональную БД. Он включает в себя следующие этапы.

1) Выбор и приобретение необходимой СУБД.

2) Преобразование концептуальной (инфологической) модели БД в логическую и физическую модель данных:

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

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

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

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

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

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

· разработать сетевую топологию БД и механизм бесшовного доступа к удалённым данным (реплицированная или распределённая БД).

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

4) Заполнение базы данных.

5) Создание прикладных программ, контроль управления.

6) Обучение пользователей.

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

Таким образом, ЖЦБД включает в себя:

· Изучение предметной области и представление соответствующей документации (1-3).

· Построение инфологической модели (4).

· Реализация (5).

· Оценка работы и поддержка БД (6).

4. Архитектура СУБД.

Рис. Главные компоненты СУБД

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

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

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

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

· Менеджер файлов контролирует расположение файлов на диске и получает блок или блоки, содержащие файлы, по запросу менеджера буфера (диск в общем случае делится на дисковые блоки - смежные области памяти, содержащие от 4000 до 16000 байт).

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

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

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

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

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

Как правило, система БД поддерживает одновременно множество транзакций. Именно правильное выполнение всех таких транзакций и обеспечивает менеджер транзакций . Правильное выполнение транзакций обеспечивается ACID -свойствами (atomicity , consistency , isolation , durability ):

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

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

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

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

Рассмотрим также 3 типа обращения к СУБД:

1. Запросы - вопросы по поводу данных могут генерироваться двумя способами:

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

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

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

3. Модификации схемы - это команды администраторов БД, которые имеют право изменять схему БД или создавать новую БД.

Архитектура клиент/сервер. Во многих вариантах современного ПО реализуется архитектура клиент/сервер : один процесс (клиент) посылает запрос для выполнения другому процессу (серверу). Как правило, БД часто разделяется на процесс сервера и несколько процессов клиента.

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

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

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

Отношение представляет собой двумерную таблицу, содержащую некоторые данные. Математически под N -арным отношением R понимают множество декартова произведения D 1 D 2 … D n множеств (доменов ) D 1, D 2 , …, D n (), необязательно различных:

R D 1 D 2 … D n ,

где D 1 D 2 … D n – полное декартово произведение, т.е. набор всевозможных сочетаний из n элементов каждое, где каждый элемент берется их своего домена.

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

· Домен имеет уникальное имя (в пределах базы данных).

· Домен определен на некотором простом типе данных или на другом домене.

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

· Домен несет определенную смысловую нагрузку .

Атрибут отношения есть пара вида <Имя_атрибута: Имя_домена>. Имена атрибутов должны быть уникальны в пределах отношения. Часто имена атрибутов отношения совпадают с именами соответствующих доменов.

Отношение R , определенное на множестве доменов, содержит две части: заголовок и тело.

Заголовок отношения – это фиксированное количество атрибутов отношения:

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

Тело отношения содержит множество кортежей отношения. Каждый кортеж отношения представляет собой множество пар вида <Имя_атрибута: Значение_атрибута>:

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

Отношение обычно записывается в виде:

или короче

,

или просто

Число атрибутов в отношении называют степенью (или -арностью ) отношения. Мощность множества кортежей отношения называют мощностью отношения.

Схемой отношения называется перечень имен атрибутов данного отношения с указанием домена, к которому они относятся:

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

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

Пусть – схема отношения . – схема отношения после упорядочения имен атрибутов. Тогда

~

Таким образом, для эквивалентных отношений выполняются следующие условия:

· Таблицы имеют одинаковое количество столбцов.

· Таблицы содержат столбцы с одинаковыми наименованиями.

· Столбцы с одинаковыми наименованиями содержат данные из одних и тех же доменов.

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

Все такие таблицы есть различные изображения одного и того же отношения.

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

· В отношении нет одинаковых кортежей .

· Кортежи не упорядочены (сверху вниз) .

· Атрибуты не упорядочены (слева направо) .

· Все значения атрибутов атомарны .

Рис. Схематическое изображение отношения

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

6. Проектирование реляционных баз данных.

При проектирование реляционной БД должны быть решены следующие проблемы:

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

2) Обеспечить эффективность выполнения запросов к базе данных (физическое проектирование БД).

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

· Построение корректной схемы данных ориентируясь на реляционную модель данных.

· Описание схемы БД в терминах выбранной СУБД.

· Описание внешних моделей в терминах выбранной СУБД.

· Описание декларативных правил поддержки целостности БД.

· Разработка процедур поддержки семантической целостности БД.

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

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

Проектирование схемы БД можно выполнить двумя методами:

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

· Метод синтеза – компоновка схемы БД из заданных исходных элементарных зависимостей между объектами предметной области.

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

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

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

В теории реляционных БД обычно выделяют следующие нормальные формы:

первая нормальная форма (1 NF );

· вторая нормальная форма (2 NF );

· третья нормальная форма (3 NF );

· нормальная форма Байса-Кодда ( BCNF );

· четвертая нормальная форма (4 NF );

· пятая нормальная форма или форма проекции - соединения (5 NF или PYNF ).

Основные свойства нормальных форм:

· каждая следующая нормальная форма в некотором смысле лучше предыдущей;

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

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

7. Нормальные формы отношений.

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

· Аномалии вставки (INSERT) – хранение в одном отношении разнородной информации.

· Аномалии обновления (UPDATE) –избыточность данных отношения из-за хранения разнородной.

· Аномалии удаления (DELETE) – хранение разнородной информации в одном отношении.

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

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

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

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

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

Заменить , первичный ключ , ФЗ

на , первичный ключ

и , первичный ключ .

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

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

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

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

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

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

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

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

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

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

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

Если отношение находится в НФБК, то оно автоматически находится в 3НФ, что следует из определения 4. Чтобы устранить зависимость от детерминантов, не являющихся потенциальными ключами, следует провести декомпозицию, вынося эти детерминанты и зависимые от них части в отдельное отношение.

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

Опр.5. Отношение находится в четвертой нормальной форме (4НФ) тогда и только тогда, когда отношение находится в НФБК и не содержит нетривиальных многозначных зависимостей.

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

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

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

Опр.6. тождественно также следует определению.

Опр.7. Отношение не находится в 5НФ, если в отношении найдется нетривиальная зависимость соединения.

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

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

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

Взаимно-независимые атрибуты – это атрибуты, не зависящие один от другого. Если в отношение существует несколько ФЗ, то каждый атрибут или набор атрибутов, от которого зависит другой атрибут, называется детерминантом отношения.

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

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

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

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

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

· определение снимка, т.е. определение данных для сохранения в виде «мгновенного снимка» отношения;

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

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

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

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

Реляционная алгебра, определенная Коддом состоит из 8 операторов, составляющих 2 группы:

• традиционные операции над множествами (объединение, пересечение, вычитание, декартово произведение);
• специальные реляционные операции (выборка, проекция, соединение, деление).

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

Краткий обзор операторов реляционной алгебры.

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

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

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

Объединение – возвращает отношение, содержащее все кортежи, которые принадлежат или одному из двух определенных отношений, или обоим.

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

Вычитание – возвращает отношение, содержащее все кортежи, которые принадлежат первому из двух определенных отношений и не принадлежат второму.

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

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

ЛИТЕРАТУРА

1. Дейт К.Дж. Введение в системы баз данных, 6-е издание: Пер. с англ. – К.; М.; СПб.: Издательский дом «Вильямс», 2000. – 848 с.

2. Конноли Т., Бегг К., Страчан А. Базы данных: проектирование, реализация и сопровождение. Теория и практика, 2-е изд.: Пер. с англ. – М.: Издательский дом «Вильямс», 2000. – 1120 с.

3. Карпова Т.С. Базы данных: модели, разработка, реализация. – СПб.: Питер, 2001. – 304 с.

4. Фаронов В.В., Шумаков П.В. Delphi 4. Руководство разработчика баз данных. – М.: «Нолидж», 1999. – 560 с.

5. Дж. Грофф, П.Вайнберг. SQL: Полное руководство: Пер. с англ. – К.: Издательская группа BHV, 2001. – 816 с.

6. Кен Гетц, Пол Литвин, Майк Гилберт. Access 2000. Руководство разработчика. Т.1, 2. Пер. с англ. – К.: Издательская группа BHV, 2000. – 1264 с, 912 c.

7. Маклаков С.В BPwin и EPwin. CASE-средства разработки информационных систем. – М.: ДИАЛОГ-МИФИ, 2001. – 304 с.

8. Ульман Д., Уидом Д. Введение в системы баз данных / Пер. с англ. – М.: «Лори», 2000. – 374 с.

9. Хомоненко А.Д., Цыганков В.М., Мальцев М.Г. Базы данных: Учебник для высших учебных заведений / Под ред. Проф. А.Д.Хомоненко. – Спб.: КОРОНА принт, 2000. – 416 с.