Структура современной субд. Архитектура базы данных: понятие, определение, уровни
По своей архитектуре СУБД делятся на одно-, двух- и трехзвенные [ 191. В однозвенной архитектуре (рис. 1.11, а) используется единственное звено (клиент), обеспечивающее необходимую логику управления данными и их визуализацию. В двухзвенной архитектуре (рис. 1.11, 6) значительную часть логики управления данными реализует сервер баз данных (сервер БД), в то время как клиентское звено в основном занято отображением данных в удобном для пользователя виде. В трехзвенных СУБД (рис. 1.11, в) используется промежуточное звено - сервер приложений,
Рис. 1.11.
а - однозвенная; 6 - двухзвенная; в - трехзвенная являющееся посредником между клиентом и сервером БД. Сервер приложений позволяет полностью избавить клиента от функций по управлению данными и обеспечению связи с сервером БД.
В зависимости от местоположения отдельных частей СУБД различают локальные и сетевые СУБД. Все части локальной СУБД размещаются на компьютере пользователя, обращающегося к базе данных. Чтобы с одной и той же БД одновременно могло работать несколько пользователей, каждый пользовательский компьютер должен иметь доступ к своей копии локальной БД. Существенной проблемой СУБД такого типа является синхронизация содержимого копий данных (репликация данных), именно поэтому для решения задач, требующих совместной работы нескольких пользователей, локальные СУБД не пригодны.
К сетевым относятся файл-серверные, клиент-серверные и распределенные СУБД. Непременным атрибутом этих систем является сеть, обеспечивающая аппаратную связь компьютеров и делающая возможной совместную работу множества пользователей с одной и той же базой данных.
В файл-серверных СУБД вся база данных обычно размещается на одном или нескольких запоминающих устройствах достаточно мощной машины, специально выделенной для этих целей и постоянно подключенной к сети. Такой компьютер называется файл-сервером. Безусловным достоинством СУБД этого типа является относительная простота ее создания и обслуживания, так как фактически все сводится лишь к организации локальной сети и установке на подключенных к ней компьютерах сетевых операционных систем. Между локальными и файл-серверными вариантами СУБД нет особых различий, так как в них все части СУБД сосредоточены на компьютере пользователя. По архитектуре они обычно являются однозвенными, но в некоторых случаях могут использовать сервер приложений. Недостатком файл-серверных систем является значительная нагрузка на сеть. Например, если пользователю, работающему на клиентском компьютере, нужно отыскать сведения об одной из книг, имеющихся в библиотеке, то по сети вначале передается весь файл, содержащий сведения обо всех книгах, и лишь затем в созданной таким образом локальной копии данных отыскиваются нужные сведения. При интенсивной работе с данными нескольких десятков пользователей пропускная способность сети может оказаться недостаточной, и пользователя будут раздражать значительные задержки в реакции СУБД на его требования. Файл-серверные СУБД могут успешно использоваться в относительно небольших организациях с количеством клиентских мест до нескольких десятков.
Клиент-серверные (двухзвенные) системы значительно снижают нагрузку на сеть, так как клиент общается с данными через специализированного посредника - сервер БД, который размещается на машине с базой данными. Сервер БД принимает запрос от клиента, отыскивает в данных нужную запись и передает ее клиенту. Таким образом, но сети передаются относительно короткий запрос и единственная нужная запись, даже если база данных содержит сотни тысяч записей. Как правило, запрос к серверу формируется на специальном языке запросов SQL, поэтому часто серверы БД называются SQL-серверами. Серверы БД представляют собой относительно сложные программы, разрабатываемые различными фирмами, например: Microsoft SQL Server (SQL Server) производства корпорации Microsoft, Sybase Adaptive Server корпорации Sybase, Oracle производства одноименной корпорации, DB2 корпорации IBM, InterBase корпорации Borland и т.д. Клиент-серверные СУБД обеспечивают функционирование, или масштабируются, до сотен и тысяч клиентских мест.
Распределенные СУБД могут содержать несколько десятков и сотен серверов БД. Количество клиентских мест в них может достигать десятков и сотен тысяч. Обычно такие СУБД обеспечивают работу организаций государственного масштаба (например, Центральной избирательной комиссии РФ), отдельные подразделения которых рассредоточены на значительной территории. В распределенных СУБД некоторые серверы могут дублировать друг друга с целью достижения предельно малой вероятности отказов и сбоев, которые могут исказить жизненно важную информацию.
Актуальность распределенных СУБД возросла в связи со стремительным развитием Интернета. Опираясь на возможности Интернета, распределенные системы строят не только организации государственного масштаба, но и относительно небольшие коммерческие предприятия, обеспечивая своим сотрудникам работу с корпоративными данными на дому и в командировках.
Понятие. Система управления базами данных (СУБД) – это сов-сть языковых и програмн средств, предназначенных для создания, ведения и совместного использования БД многими пользователями.
Современная СУБД содержит в своем составе программные средства создания баз данных (язык описания и манипулирования данными, визуальные средства, отладчики), средства работы с данными и сервисные средства. Функции элементов СУБД: - язык описания служит для преобразования логической модели в физическую; - язык манипулирования реализует операции над данными; - визуальные средства привлекаются в процессе проектирования графических объектов; - программы отладки соединяют и тестируют блоки программы управления, созданной БД; - средства работы с БД обеспечивают удобный интерфейс с пользователем; сервисные средства привлекают к работе с БД другие программы (эксель).
Архитектура. В среде СУБД можно выделить след. пять основных компонентов:
Аппаратное обеспечение. Одни СУБД предназначены для работы только с конкр типами ОС или оборудования, другие могут работать с широким кругом аппаратного обеспечения и различными ОС. Для работы СУБД обычно требуется некоторый минимум оперативной и дисковой памяти, но ее может быть недостаточно для достижения приемлемой производительности системы.
Программное обеспечение. Этот компонент включает операционную систему, программное обеспечение самой СУБД, прикладные программы, включая и сетевое программное обеспечение, если СУБД используется в сети. Обычно приложения создаются на языках третьего поколения, таких как С, COBOL, Fortran, Ada или Pascal, или на языках четвертого поколения, таких как SQL, операторы которых внедряются в программы на языках третьего поколения.
Данные – наиболее важный компонент с точки зрения конечных пользователей. База данных содержит как рабочие данные, так и метаданные, т.е. "данные о данных".
Процедуры, к которым относят инструкции и правила, которые должны учитываться при проектировании и использовании базы данных: регистрация в СУБД; использование отдельного инструмента СУБД или приложения; запуск и останов СУБД; создание резервных копий СУБД; обработка сбоев аппаратного и программного обеспечения, включая процедуры идентификации вышедшего из строя компонента, исправления отказавшего компонента (например, посредством вызова специалиста по ремонту аппаратного обеспечения), а также восстановления базы данных после устранения неисправности; изменение структуры таблицы, реорганизация базы данных, размещенной на нескольких дисках, способы улучшения производительности и методы архивирования данных на вторичных устройствах хранения.
Пользователи: клиенты БД, администратор БД, прикладные программисты. Более подробно этот компонент рассматривается в лекции №9 (Администрирование БД)
Подсистема средств проектирования представляет собой набор инструментов, упрощающих проектирование и реализацию баз данных и их приложений. Как правило, этот набор включает в себя средства для создания таблиц, форм, запросов и отчетов.
Подсистема обработки обеспечивает обработку компонентов приложений, созданных с помощью средств проектирования. Например, в Access 2003 имеется компонент, реализующий построение формы и связывающий элементы формы с данными таблиц.
Третий компонент СУБД – ее ядро (DBMS Engine) выполняет функцию посредника между подсистемой средств проектирования и обработки и данными. Ядро СУБД получает запросы от двух других компонентов, выраженные в терминах таблиц, строк и столбцов, и преобразует эти запросы в команды операционной системы, выполняющие запись и чтение данных с физического устройства.
Microsoft представляет два различных ядра для Access 2003: Jet Engine и SQL Server. Ядро Jet Engine используется для персональных и коллективных баз данных небольшого объема. Ядро SQL Server предназначено для крупных баз данных.
35. Возможности, предоставляемые СУБД пользователям. Производительность СУБД .
К основным функциям СУБД относятся: Ведение системного каталога, Системный каталог, или словарь данных, является хранилищем инф-ции, описывающей данные в БД (по сути, это "данные о данных", или метаданные). Обычно в системном каталоге хранятся следующие сведения: имена, типы и размеры элементов данных; имена связей; накладываемые на данные ограничения поддержки целостности; имена санкционированных пользователей, которым предоставлено праводоступа к данным; внешняя, концептуальная и внутренняя схемы и отображения между ними; статистические данные, например частота транзакций и счетчики обращений к объектам базы данных.
¨ Поддержка транзакций. Транзакция - набор действий, выполняемых отдельным пользователем или прикладной программой с целью доступа или изменения содержимого базы данных. Примерами транзакций может служить добавление в БД, обновление, удаление каких-либо сведений.
¨ Поддержка параллельной работы.
¨ Восстановление базы данных после сбоев. Журнал - это особая часть БД, недоступная пользователям СУБД и поддерживаемая с особой тщательностью (иногда поддерживаются две копии журнала, располагаемые на разных физических дисках), в которую поступают записи обо всех изменениях основной части БД.
¨ Контроль доступа к данным. СУБД должна иметь механизм, гарантирующий возможность доступа к базе данных только санкционированных пользователей.
¨ Поддержка обмена данными. СУБД в должны поддерживать работу в локальной сети, чтобы вместо нескольких разрозненных баз данных для каждого отдельного пользователя можно было бы установить одну централизованную базу данных и использовать ее как общий ресурс для всех существующих пользователей. Такая топология называется распределенной обработкой.
¨ Поддержка целостности данных. Целостность базы данных означает корректность и непротиворечивость хранимых данных. Она может рассматриваться как еще один тип защиты базы данных.
¨ Поддержка независимости от данных. Независимость от данных обычно достигается за счет реализации механизма поддержки представлений или подсхем. Физическая независимость от данных достигается довольно просто, так как обычно имеется несколько типов допустимых изменений физических характеристик базы данных, которые никак не влияют на представления.
Вспомогательные функции. предназначенны для администрирования базы данных, импорта и экспорта БД, мониторинга характеристик функционирования и использования базы данных, статистического анализа, реорганизации индексов, перераспределения памяти.
Приложения выполняют пять основных функций: 1. Создание, чтение, обновление и удаление представлений. 2. Форматирование представлений. 3. Реализация ограничений. 4. Обеспечение механизмов безопасности и контроля. 5. Реализация логики обработки информации. Производительность СУБД оценивается:
Временем выполнения запросов; скоростью поиска информации в неиндексированных полях; временем выполнения операций импортирования базы данных из других форматв; скоростью создания индексов и выполнения таких массовых операций, как обновление, вставка, удаление данных; максимальным числом параллельных обращений к данным в многопользовательском режиме; временем генерации отчета. На производительность СУБД оказывают влияние два фактора: СУБД, которые следят за соблюдением целостности данных, несут дополнительную нагрузку, которую не испытывают другие программы; производительность собственных прикладных программ сильно зависит от правильного проектирования и построения базы данных.
Основной интерес применения СУБД заключается в том, чтобы предложить пользователю (или прикладным процессам) абстрактное представление данных, скрыв особенности хранения и управления ими. СУБД должна представлять доступ к данным посредством прикладных процессов любым пользователям, в том числе не имеющим представления:
О физическом размещении в памяти данных и их описаний;
О механизме поиска запрашиваемых данных;
О проблемах, возникающих при одновременном запросе одних и тех же данных большим числом пользователей (прикладных программ);
О способах защиты данных от некорректных обновлений и (или) несанкционированного доступа;
О поддержании базы данных в актуальном состоянии.
Обобщенная структура связей программ и данных при использовании СУБД показана на рисунке 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. Компоненты контроллера базы данных
По способу организации взаимодействия с базой данных через сеть , СУБД делятся на:
СУБД с централизованной архитектурой;
СУБД с архитектурой файл-сервер;
СУБД с архитектурой клиент-сервер;
СУБД с трехуровневой архитектурой: «тонкий клиент» - сервер приложений – сервер базы данных.
В СУБД с централизованной архитектурой , СУБД и сама база данных размещается и функционирует на центральном миникомпьютере (мэйнфрейме), а пользователи получают доступ к базе данных при помощи обычных терминалов – компьютер рассматривается просто как устройство ввода и отображения информации: на мэйнфрейм передаются нажатия клавиш, в обратном направлении передаются данные, отображаемые непосредственно на мониторе пользователя. Примерами СУБД с централизованной архитектурой являются ранние версии СУБД DB2, ранние версии СУБД Oracle и Ingres.
В СУБД с архитектурой файл-сервер база данных хранится на сервере, а копии СУБД устанавливаются на компьютерах пользователей. Файл базы данных находящийся на сервере, совместно используется всеми пользователями одновременно, при помощи сетевого программного обеспечения и самой операционной системы. Ярким примером такой архитектуры является СУБД MS Access: копии СУБД установлены на компьютере каждого пользователя, а сам файл базы данных находится на сервере в сетевой папке.
Архитектура файл-сервер позволяет добиться приемлемой производительности, т.к. в распоряжении каждой копии СУБД находятся все ресурсы компьютера пользователя. С другой стороны, производительность такой схемы для каждого пользователя, напрямую зависит от характеристик компьютера пользователя. Кроме того, такая схема работы значительно загружает сеть.
Допустим, что пользователю необходимо отобрать строки таблицы с товарами, по которым объем продаж не превышает 100 тыс. рублей. Поскольку строки в таблице не упорядочены, то скорее всего по сети будут переданы все строки таблицы, из которых СУБД уже «на месте» (на компьютере пользователя) отберет нужные.
Очевидно, что такая схема нерациональна при больших объемах обрабатываемой информации или большем числе пользователей базы данных. Поэтому, для таких БД целесообразнее применять архитектуру клиент-сервер.
При архитектуре клиент-сервер база данных хранится на сервере, а СУБД подразделяется на две части: клиентскую и серверную . Клиентская часть СУБД выполняется на стороне клиента и обеспечивает интерактивное взаимодействие с пользователем и формирование запросов к базе данных (на языке SQL).
Серверная часть работает на сервере и взаимодействует с базой данных, обеспечивая выполнение запросов клиентской части, т.е. если провести аналогию с рассмотренным выше примером, то клиентская часть сформирует и отправит серверной части запрос «Отбери меня для строки таблицы с товарами, по которым объем продаж не превышает 100 тыс. рублей», серверная часть выполнил данный запрос и отошлет клиентской части те строки, которые необходимо, не передавая по сети все строки.
Большинство современных СУБД реализованы по архитектуре клиент-сервер: Oracle, MS SQL Server, PostgreSQL, MySQL, Informix, DB2 и др.
Однако и архитектура клиент-сервер не лишена недостатков.
Если деловая логика взаимодействия с базой данных (логика, определяющая порядок работы предприятия: какие таблицы и в каком порядке заполнять, что делать при добавлении нового сотрудника и т.д.) изменяется, то приходится заново переписывать клиентские программы (водить новые формы, менять порядок их заполнения и т.д.).
Если изменения происходят слишком часто, а количество рабочих мест велико, то постоянная переустановка программного обеспечения (которая, кстати, должна осуществляться достаточно быстро) становится серьезной проблемой.
В таких случаях следует переходить к трехуровневой архитектуре: «тонкий клиент» - сервер приложений – сервер базы данных.
При трехуровневой архитектуре в функции клиентской части («тонкий клиент») входит только интерактивное взаимодействие с пользователем, а вся деловая логика вынесена на сервер приложений, который собственно и обеспечивает формирование запросов к базе данных, передаваемых на выполнение серверу базы данных.
«Тонкий клиент» находится на компьютере пользователя и чаще всего представляет собой Web-браузер (например, Internet Explorer) с применением соответствующей HTML-странице апплетов Java или компонентов ActiveX.
Сервер приложений находится на сервере и может являться специализированной программой (например, Oracle Forms Server) или обычным Web-сервером, вызывающим для обработки HTTP-запроса внешнюю программу через интерфейс CGI (рис. 33).
Рис. 33. Трехуровневая архитектура БЗ.
Преимущества трехуровневой архитектуры очевидны: при необходимости изменений в деловой логике, изменения вносятся только один раз – на сервере приложений. Изменять или переустанавливать клиентские программы нет никакой необходимости.
КОНСПЕКТ ОБЗОРНОЙ ЛЕКЦИИ
Для
студентов специальности
Т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 с.
