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

Схемы бд называется как

  • автор:

База данных

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

Освойте профессию «Аналитик данных»

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

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

Профессия / 12 месяцев
Аналитик данных

Находите закономерности и делайте выводы, которые помогут бизнесу

Group 1321314279 (1)

Свойства базы данных

Из определения базы данных следует, что в ней:

  • всегда есть имя. Если имя не задано, то нет и базы данных;
  • фиксируется состояние объектов и их отношений в заданный момент времени. Со временем оно меняется. Например, цена товара может характеризовать его состояние. Вслед за изменением цены меняется и состояние товара;
  • фиксируется информация об объектах из определенной предметной области. Например, если рассматриваем предметную область «Библиотека», то в базе могут фиксироваться данные по книгам, их расположению в библиотеке, читателям и читательским билетам. Если наша предметная область — «Магазин», то в БД может находиться информация по товарам и их ценам, по торговым точкам и наличию товара в конкретной торговой точке.

Важной характерной чертой БД является ее постоянство. Оно проявляется в нескольких контекстах:

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

Отличия баз данных от электронных таблиц

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

Читайте также Как выбрать IT-специальность в новых реалиях?

Типы баз данных

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

Форма представления информации

  • Фактографические. Данные представлены в виде фактов об объектах предметной области в формате пар «параметр — значение». Пример: БД сайта www.ozon.ru.
  • Документальные. Данные представлены в виде полнотекстовых документов. Пример: БД сайта www.vedomosti.ru.
  • Мультимедийные. Данные представлены в виде графического, аудио- или видеоконтента. Пример: БД сайта www.youtube.com.

Тип используемой модели данных

  • Реляционные. Данные представлены в виде таблиц и связей между ними. Пример: БД Microsoft SQL Server, MySQL, PostgreSQL.
  • Нереляционные. Данные представлены в виде структур, отличных от таблиц. Например, JSON-подобных объектов, иерархических или сетевых структур. Пример: БД ElasticSearch, MongoDB.

Топология хранения

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

  • Локальные. Размещены на одной машине.
  • Распределенные. Размещены на нескольких машинах.

Функциональное назначение

  • Операционные. Большую часть времени используются для операций записи (добавление, изменение, удаление данных). Пример: БД 1С.
  • Справочно-информационные. Большую часть времени используются для операций чтения. Пример: БД сайта www.consultant.ru.

Степень доступности

  • Общедоступные. Открыты широкому кругу пользователей. Обычно доступ к базам данных бесплатный. Пример: БД энциклопедии Wikipedia.
  • С ограниченным доступом. Доступ к базам данных ограничен и обычно платный. Пример: БД энциклопедии Encarta.

* Примечание: примеры баз данных сайтов приведены на основе результатов анализа их пользовательского интерфейса и контента. Технически БД могут быть организованы по-другому.

Станьте аналитиком данных и получите востребованную специальность

Популярные системы управления базами данных

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

MySQL

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

Особенности:

  • Возможность работы с различными типами таблиц, от популярных InnoDB или MyISAM до редко используемых MERGE или HEAP.
  • Постоянное обновление и добавление новых поддерживаемых типов таблиц.
  • Высокая скорость работы — MySQL считается одной из самых быстрых несмотря на то, что одновременно с ней могут работать несколько пользователей, а количество строк в таблицах достигает 50 миллионов.
  • Простота — с MySQL несложно работать, потому что она поддерживает меньшее количество возможностей по сравнению с другими СУБД.
  • При работе с MySQL доступен не только текстовый, но и графический режим. Приложение phpMyAdmin позволяет администрировать свою базу данных через браузер без знания SQL-команд.

MySQL — удобная, гибкая и хорошо работающая БД для крупных или средних проектов.

Oracle

СУБД объектно-реляционного типа получила название от компании-разработчика. При работе с Oracle используется язык Java, а также расширение PL/SQL.

Особенности:

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

Станьте аналитиком данных и получите востребованную специальность

PostgreSQL

PostgreSQL относится к объектно-реляционному типу, свободно распространяется и работает на языках SQL и MySQL. Основное отличие от MySQL — в использовании инноваций и расширенном функционале.

Особенности:

  • перегрузка функций и наследование таблиц;
  • поддержка большого количества типов данных: JSON, XML, «ключ — значение», пространственных данных и многого другого;
  • расширяемость, т.е. можно использовать готовые расширения, а также создавать собственные.

PostgreSQL подходит для хранения больших объемов данных, может обрабатывать сложные запросы. Способна выстраивать небольшие DWH (Data Warehouse), быть хранилищем для геоинформационных систем, мобильных игр, веб-приложений и т.д.

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

MongoDB

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

Особенности:

  • Не требуется описание схемы таблиц, как в реляционных БД. Данные хранятся в формате BSON (бинарных JSON-подобных документов).
  • Между коллекциями отсутствуют сложные соединения типа JOIN, как между таблицами реляционных баз данных. Обычно соединение выполняется при сохранении данных благодаря объединению документов.
  • Структура коллекций может различаться. У одного документа может быть один набор полей, в то время как у другого документа — совершенно другой (как тип, так и количество полей). MongoDB может хранить любые данные в формате JSON.

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

Redis

Еще одна NoSQL-система, предназначенная для хранения данных типа «ключ — значение».

Особенности:

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

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

Elasticsearch

Распределенная СУБД, основанная на Java-библиотеке Lucene. Способна поддерживать как структурированные, так и полуструктурированные данные. Это одна из самых масштабированных поисковых систем. Входит в группу Elastic Stack.

Особенности:

  • поисковый сервер с открытым исходным кодом, который написан на Java;
  • распределенное хранилище документов без схем, REST & JSON;
  • веб-интерфейс REST API с выводом JSON;
  • встроенный анализатор текстов;
  • полнотекстовый поиск;
  • поиск в реальном времени (NRT);
  • поддержка разных языков и геолокации.

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

SQLite

Реляционная СУБД, которая выпускается в виде библиотеки на языке C.

Особенности:

  • Встраивание в само приложение, а не работа по принципу «клиент — сервер». СУБД хранится на устройстве в виде локального файла: так она по умолчанию может быть встроена в некоторые телефоны и компьютеры.
  • Поставка с нулевой конфигурацией, поэтому администрирование или настройка не требуются.
  • Небольшой размер.
  • Автономность, что означает отсутствие внешних зависимостей.
  • SQLite-транзакции полностью совместимы с ACID, обеспечивают безопасный доступ к разным процессам или потокам.

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

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

Neo4j

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

Особенности:

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

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

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

Аналитик данных

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

База данных

Идеи, Концепции, учения, методы исследования

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

Происхождение термина «база данных» известный эксперт в области технологий баз данных Т. У. Олле (T. W. Olle) связывает с работами, проводимыми в начале 1960-х гг. по заказу военных организаций США. Эти работы были представлены на, вероятно, первом посвящённом этой тематике симпозиуме, организованном в 1963 г. компанией System Development Corporation в Санта-Монике (округ Лос-Анджелес, штат Калифорния). Термин «база данных» был использован в названии симпозиума, а также его секций и ряда докладов ( Олле. 1981. С. 9–10).

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

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

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

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

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

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

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

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

Технологии баз данных предусматривают и обеспечивают следующие основные свойства баз данных:

  • Данные, составляющие базу данных, являются самостоятельным информационным ресурсом, независимым и отделённым от использующего его прикладного программного обеспечения. Этим они отличаются от данных, используемых программой, описанных в её исходном коде на языке программирования .
  • База данных долговременно хранится во внешней (энергонезависимой) памяти компьютера. Надёжность её хранения (физическая целостность данных) обеспечивается администратором базы данных путём создания резервных копий и другими методами.
  • Организация базы данных соответствует модели данных, на которой основана СУБД, используемая для реализации системы базы данных. Структура базы данных и другие свойства её контента описываются схемой базы данных, представленной на языке описания данных модели данных.
  • Схема базы данных отделена от прикладных программ и от данных, содержащихся в базе данных.
  • База данных является интегрированной совокупностью данных в том смысле, что каждый факт представлен в ней однократно. Иначе говоря, должна обеспечиваться минимизация избыточности содержащихся в ней данных. Исключения из этого принципа используются, в частности, когда избыточные данные служат для целей контроля логической целостности данных (их полноты и непротиворечивости). Избыточные данные могут использоваться также в распределённых базах данных, когда дубликаты отдельных фрагментов базы данных хранятся в нескольких узлах сети для повышения производительности системы базы данных благодаря уменьшению времени доступа или для приближения данных к месту их использования. В таком случае при изменении одного из экземпляров данных должна осуществляться синхронизация всех дублирующих его экземпляров данных на других узлах сети.
  • Поскольку к базе данных могут одновременно обращаться (в частности, обновлять данные) многие пользователи, она управляется централизованно средствами СУБД, и только через посредство СУБД возможен доступ к её контенту. Эффективность организации базы данных должна оцениваться интегрально по отношению к потребностям всего сообщества пользователей. Задачу одновременного параллельного доступа нескольких пользователей решают механизмы управления транзакциями СУБД, позволяющие сохранить при этом логическую целостность данных в базе данных. Транзакцией называется совокупность операций манипулирования данными (вставки, удаления, выборки, обновления) в системе баз данных, которая переводит базу данных из одного целостного состояния в другое.
  • Пользователи базы данных не должны знать, каким образом хранится база данных. Это достигается благодаря многоуровневому представлению базы данных в системе базы данных, которое обеспечивается механизмами СУБД. Реальные данные представлены лишь на нижнем уровне иерархии уровней – в среде хранения базы данных. На более высоких уровнях поддерживаются виртуальные представления данных, и именно с ними имеют дело пользователи. Междууровневые отображения данных в такой архитектуре обеспечиваются механизмами используемой СУБД.
  • Благодаря многоуровневой архитектуре представления данных обеспечивается логическая и физическая независимость данных базы данных. Логической независимостью данных называют возможность изменения в определённых рамках схемы базы данных таким образом, что эти изменения остаются прозрачными (нечувствительными) для ранее созданных прикладных программ и формулировок пользовательских запросов. Физическая независимость данных понимается как возможность реорганизации хранимых данных базы данных также в определённых рамках таким образом, что при этом не требуются какие-либо изменения в схеме базы данных. Указанные возможности достигаются соответствующими изменениями междууровневых отображений данных в архитектуре многоуровневого представления базы данных.
  • Степень независимости данных в конкретной системе базы данных определяется тем, в какой мере управляемы механизмы отображения данных СУБД. В реляционных базах данных, управляемых СУБД с языком SQL, логическая независимость данных обеспечивается возможностями языка, позволяющими конструировать виртуальные таблицы, называемые представлениями (англ. view). Физическая независимость данных в таких базах данных весьма ограничена. Значительной степенью логической и физической независимости данных обладают базы данных сетевой структуры типа CODASYL (см. далее раздел « База данных типа CODASYL »). Для них физическая независимость данных при необходимости изменения организации хранения базы данных обеспечивается лишь соответствующими изменениями описания хранимых данных в схеме хранения и его отображения в схему базы данных. В свою очередь, логическая независимость данных при необходимости изменений представления базы данных или её части для прикладной программы обеспечивается соответствующими изменениями описания данных в подсхеме базы данных и его отображения в схему базы данных. Изменять схему базы данных в обоих случаях не требуется, однако только при отсутствии каких-либо изменений состава или структуры данных в базе данных.

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

В 1990–2000-е гг., в частности в связи с развитием веб-технологий, родился феномен больших данных . Начала формироваться новая ветвь науки – наука о данных (англ. data science). Стала изменяться роль данных в ряде областей научных исследований, которую сотрудник компании Microsoft Дж. Грей (J. Gray) квалифицировал как новую четвёртую парадигму науки – возможность исследований и открытий, движимых данными на основе их интенсивного использования, в отличие от традиционных теоретической, эмпирической и вычислительной парадигм. Аналогичная тенденция интенсивного использования данных возникла также во многих других сферах деятельности – медицине, технике, экономике, социальной сфере и др. Всё это потребовало создания и использования эффективного инструментария для управления данными и их анализа. Технологии баз данных откликнулись на этот вызов разработкой нового многоаспектного пласта технологий с единым названием NoSQL.

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

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

Иерархическая база данных

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

База данных типа CODASYL

База данных сетевой структуры, организованная и обеспечивающая доступ к содержащимся в ней данным в соответствии с моделью данных CODASYL. В соответствии с предложениями CODASYL DBTG (от англ. Data Base Task Group), разработавшей сетевую модель данных, база данных имеет трёхуровневое представление: уровень хранимых данных, уровень схемы и уровень подсхемы. Для каждого из этих уровней представление базы данных определяется соответственно схемой хранения, схемой базы данных и подсхемами базы данных. Схема хранения описывается на языке описания хранения данных (англ. data storage description language). Схема базы данных описывается на языке определения данных (англ. data definition language). Языки описания подсхемы базы данных разработаны для языков программирования, на которых разрабатываются приложения системы базы данных. Были созданы такие языки для языков Cobol и Fortran . Описание хранения данных – схема хранения включает декларации его отображения в схему базы данных. Отображения в схему базы данных декларируются и в подсхемах базы данных.

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

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

Полная база данных подразделяется на области. Каждый тип записей относится к одной из областей.

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

База данных CODASYL может содержать активные компоненты, называемые процедурами базы данных. Процедуры базы данных являются программами, которые могут быть ассоциированы в соответствии с декларацией в схеме базы данных с элементами данных, записями, наборами, областями. Эти программы выполняются, если над этими компонентами базы данных выполняется указанный в схеме оператор языка манипулирования данными из какого-либо приложения. Процедура базы данных является прототипом триггера в языке SQL – совокупности операторов языка, активизирующейся при выполнении условий, указанных в её определении. База данных CODASYL, для которой в её схеме декларированы процедуры базы данных, относится к активным базам данных (см. далее).

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

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

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

При проектировании реляционной базы данных может потребоваться нормализация – процесс преобразования структуры таблиц базы данных для приведения их в т. н. нормальные формы с целью исключения избыточности данных и улучшения их логической целостности, устранения нежелательных аномалий, которые могут возникнуть при выполнении операций вставки, обновления и удаления данных. Концепция нормализации была предложена Э. Коддом как часть его теории реляционной модели данных. Определено шесть нормальных форм. Каждая следующая обладает свойствами предыдущей и некоторыми дополнительными полезными свойствами. Первая, вторая и третья нормальные формы были предложены Э. Коддом. Позднее им совместно с Р. Бойсом (R. Boyce) были разработаны ещё три нормальные формы, являющиеся усилением предложенных ранее Э. Коддом. Процесс нормализации и получения представлений таблиц в требуемой нормальной форме осуществляется их пошаговой декомпозицией. Таким образом, процесс проектирования реляционной базы данных может быть итерационным.

Объектно-ориентированная база данных

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

Объектно-реляционная база данных

База данных, в которой поддерживается как реляционное, так и объектное представление данных. Такие гибридные базы данных позволяют использовать ряд новых важных возможностей, отсутствующих в чисто реляционных базах данных. Например, можно естественным образом моделировать более сложные структуры данных, используя новые типы данных, определяемые пользователем. Попытка формулировки основ объектно-реляционной базы данных была предпринята в работе Х. Дарвина (H. Darwen) и К. Дейта (C. Date) «Третий манифест» ( Дарвин. 1996 ). Программные продукты для работы с такими базами данных (объектно-реляционные СУБД) появились в начале второй половины 1990-х гг. В настоящее время создание и использование таких баз данных в некоторой степени позволяют СУБД, основанные на действующей версии стандарта языка SQL, реализующей объектное расширение реляционной модели данных.

Временная (темпоральная) база данных

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

Пространственная база данных

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

Многомерная база данных

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

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

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

База данных XML

База данных, содержащая совокупность XML-документов. С появлением языка XML и комплекса связанных с ним стандартов индустрия программного обеспечения систем баз данных начала выпускать программные продукты для управления такими базами данных, которые можно назвать XML- серверами . В качестве основной части схемы базы данных при этом использовалось описание типа документов – XML DTD (от англ. Document Type Definition). Одним из первых таких продуктов был выпущенный компанией Software AG XML-сервер Tamino. В настоящее время возможности описания и манипулирования XML-данными имеются в действующей версии стандарта языка SQL. СУБД, поддерживающие этот стандарт, доминируют в разработках баз данных XML.

Дедуктивная база данных

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

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

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

Распределённая база данных

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

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

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

База данных с сетевым доступом

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

Мобильная база данных

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

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

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

Активная база данных

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

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

В реляционных базах данных средства для реализации активного поведения в форме механизма, названного его авторами триггером, были позднее предусмотрены в прототипе языка SQL, названного SEQUEL его авторами из компании IBM и опубликованного в 1975 г. Они были реализованы в известном исследовательском проекте System R этой компании и впоследствии были включены в стандарт языка SQL.

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

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

Персональная база данных

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

База данных, поддерживаемая (резидентная) в оперативной памяти

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

Самоописываемая база данных

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

Статистическая база данных

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

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

Базы данных NoSQL

Истоки направления в технологиях баз данных, обозначаемого акронимом NoSQL (No SQL – не SQL), относятся ко второй половине 1990-х гг. Это направление рассматривалось как альтернатива реляционным базам данных, управляемым СУБД с языком SQL. Системы реляционных баз данных оказались недостаточно эффективны для работы с большими данными, в частности с данными Веба , распределённые системы таких баз данных в этих условиях оказывались плохо масштабируемы и недостаточно гибко адаптируемыми к приложениям. В 2000-е гг. появились программные продукты, разработанные крупные компаниями, такими как Google , Amazon и др., позволяющие преодолевать указанные трудности. NoSQL стали расшифровывать как Not Only SQL (не только SQL). Начались многочисленные разработки СУБД, баз данных и систем баз данных, основанных на разнообразных технологиях и удовлетворяющих в различной степени указанным требованиям. Единым «зонтиком» для них стала фактически их категоризация как NoSQL.

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

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

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

Опубликовано 24 октября 2022 г. в 17:21 (GMT+3). Последнее обновление 24 октября 2022 г. в 17:21 (GMT+3). Обратная связь

Схема базы данных

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

Постоянные данные в среде базы данных включают в себя схему и базу данных. Система управления данными использует определения данных в схеме для обеспечения доступа и управления доступом к данным в базе данных [1] .

Схема как структура базы данных

Схема базы данных MediaWiki

Схема системы базы данных (от англ. Database schema) — её структура, описанная на формальном языке, поддерживаемом системой управления базами данных (СУБД). В реляционных базах данных схема определяет таблицы, поля в каждой таблице, а также отношения между полями и таблицами.

Схемы в общем случае хранятся в словаре данных. Хотя схема определена на языке базы данных в виде текста, термин часто используется для обозначения графического представления структуры базы данных. [2]

Основными объектами схемы являются таблицы и связи.

Схема как объект базы данных

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

Схема (SCHEMA) [3] — является одним из основных объектов базы данных Oracle. Близкое понятие (RIS Schema) существует в RIS-интерфейсе доступа к базам данных. SCHEMA также появилась и в Microsoft SQL Server 2005 и формально определяется как набор объектов в базе данных [4] .

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

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

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

Существуют и подобъекты схемы, такие как:

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

Существуют объекты не зависимые от схемы

  • каталоги,
  • профили,
  • роли,
  • сегменты,
  • табличные области
  • пользователи.

Уровни схемы базы данных

  • Концептуальная схема — карта концепций и их связей
  • Логическая схема — карта сущностей и их атрибутов и связей
  • Физическая схема — частичная реализация логической схемы
  • Схема объекта — объект БД Oracle

Примечания

  1. 12 ГОСТ Р ИСО МЭК ТО 10032-2007: Эталонная модель управления данными (идентичен ISO/IEC TR 10032:2003 Information technology — Reference model of data management)
  2. What is schema? — A Word Definition From the Webopedia Computer Dictionary
  3. Основные объекты Oracle — Книги по базам данных
  4. Схемы баз данных SQL Server 2005, разделение пользователей и схем — AskIt.RU

См. также

  • Моделирование данных
  • Моделирование данных
  • Базы данных
  • Теоретические основы баз данных

Проектирование реляционных БД на основе принципов нормализации

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

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

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

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

ОПРЕДЕЛЕНИЕ

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

Процесс разработки корректной схемы реляционной БД называется логическим проектированием БД.

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

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

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

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

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

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

  • первая нормальная форма ( 1NF );
  • вторая нормальная форма ( 2NF );
  • третья нормальная форма ( 3NF );
  • нормальная форма Бойса—Кодда ( BCNF );
  • четвертая нормальная форма ( 4NF );
  • пятая нормальная форма, или форма проекции-соединения ( 5NF или PJNF).

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

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

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

ОПРЕДЕЛЕНИЕ

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

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

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

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

Приведем ряд основных определений.

Функциональной зависимостью набора атрибутов В отношения R от набора атрибутов A того же отношения, обозначаемой как R.A -> R.B или A -> B

называется такое соотношение проекций R[A] и R[B] , при котором в каждый момент времени любому элементу проекции R[A] соответствует только один элемент проекции R[B] , входящий вместе с ним в какой-либо кортеж отношения R .

Функциональная зависимость R.A -> R.B называется полной,если набор атрибутов B функционально зависит от A и не зависит функционально от любого подмножества A , то есть R.A -> R.B называется полной, если:

\forall A1 \subseteq A \to R.A -/\to R.B

,

что читается следующим образом:

для любого A1 , являющегося подмножеством А , R.B функционально не зависит от R.A , в противном случае зависимость R.A -> R.B называется неполной.

Функциональная зависимость R.A -> R.B называется транзитивной, если существует набор атрибутов С такой, что:

  1. С не является подмножеством А .
  2. С не включает в себя B .
  3. Существует функциональная зависимость R.A -> R.C .
  4. Не существует функциональной зависимости R.C -> R.A .
  5. Существует функциональная зависимость R.C -> R.B .

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

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

В общем случае в отношении может быть несколько возможных ключей.

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

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

Взаимно-независимые атрибуты — это такие атрибуты, которые не зависят функционально один от другого.

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

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

  1. Рефлексивность: если В является подмножеством А , то А -> B
  2. Дополнение: если А->B, то A.C -> B.C
  3. Транзитивность: если A -> B и B -> C, то A -> C .

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

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

ОПРЕДЕЛЕНИЕ

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

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

Преподаватель День недели Номер пары Название дисциплины Тип занятий Группа
Петров В. И. Понед. 1 Теор. выч. проц. Лекция 4906
Вторник 1 Комп. графика Лаб. раб.. 4907
Вторник 2 Комп. графика Лаб. раб 4906
Киров В. А. Понед. 2 Теор. информ. Лекция 4906
Вторник 3 Пр-е на С++ Лаб. раб. 4907
Вторник 4 Пр-е на С++ Лаб. раб. 4906
Серов А. А. Понед. 3 Защита инф. Лекция. 4944
Среда 3 Пр-е на VB Лаб. раб 4942
Четверг 4 Пр-е на VB Лаб. раб. 4922

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

Для приведения отношения «Расписание» к первой нормальной форме необходимо дополнить каждую строку фамилией преподавателя.

Преподаватель День недели Номер пары Название дисциплины Тип занятий Группа
Петров В. И. Понед. 1 Теор. выч. проц. Лекция 4906
Петров В. И. Вторник 1 Комп. графика Лаб. раб.. 4907
Петров В. И. Вторник 2 Комп. графика Лаб. раб 4906
Киров В. А. Понед. 2 Теор. информ. Лекция 4906
Киров В. А. Вторник 3 Пр-е на С++ Лаб. раб. 4907
Киров В. А. Вторник 4 Пр-е на С++ Лаб. раб. 4906
Серов А. А. Понед. 3 Защита инф. Лекция. 4944
Серов А. А. Среда 3 Пр-е на VB Лаб. раб 4942
Серов А. А. Четверг 4 Пр-е на VB Лаб. раб. 4922

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *