1.2 Домены
В реляционной модели данных с понятием тип данных тесно связано понятие домена, которое можно считать уточнением типа данных.
Домен — это семантическое понятие. Домен можно рассматривать как подмножество значений некоторого типа данных имеющих определенный смысл. Домен характеризуется следующими свойствами:
Домен имеет уникальное имя (в пределах базы данных).
Домен определен на некотором простом типе данных или на другом домене.
Домен может иметь некоторое логическое условие, позволяющее описать подмножество данных, допустимых для данного домена.
Домен несет определенную смысловую нагрузку.
Например, домен 
, имеющий смысл «возраст сотрудника» можно описать как следующее подмножество множества натуральных чисел:
Если тип данных можно считать множеством всех возможных значений данного типа, то домен напоминает подмножество в этом множестве.
Отличие домена от понятия подмножества состоит именно в том, что домен отражает семантику, определенную предметной областью. Может быть несколько доменов, совпадающих как подмножества, но несущие различный смысл. Например, домены «Вес детали» и «Имеющееся количество» можно одинаково описать как множество неотрицательных целых чисел, но смысл этих доменов будет различным, и это будут различные домены.
Основное значение доменов состоит в том, что домены ограничивают сравнения. Некорректно, с логической точки зрения, сравнивать значения из различных доменов, даже если они имеют одинаковый тип. В этом проявляется смысловое ограничение доменов. Синтаксически правильный запрос «выдать список всех деталей, у которых вес детали больше имеющегося количества» не соответствует смыслу понятий «количество» и «вес».
Понятие домена помогает правильно моделировать предметную область. При работе с реальной системой в принципе возможна ситуация когда требуется ответить на запрос, приведенный выше. Система даст ответ, но, вероятно, он будет бессмысленным.
Не все домены обладают логическим условием, ограничивающим возможные значения домена. В таком случае множество возможных значений домена совпадает с множеством возможных значений типа данных.
2. Целостность реляционных данных
Во второй части реляционной модели данных определяются два ограничения, которые должны выполняться в любой реляционной базе данных. Это:
Целостность внешних ключей.
Прежде, чем описывать целостность сущностей, необходимо описать использование null-значений в реляционных базах данных.
2.1 Null-значения
Основное назначение баз данных состоит в том, чтобы хранить и предоставлять информацию о реальном мире. Для представления этой информации в базе данных используются привычные для программистов типы данных — строковые, численные, логические и т.п. Однако в реальном мире часто встречается ситуация, когда данные неизвестны или не полны. Например, место жительства или дата рождения человека могут быть неизвестны (база данных разыскиваемых преступников). Если вместо неизвестного адреса уместно было бы вводить пустую строку, то что вводить вместо неизвестной даты? Ответ — пустую дату — не вполне удовлетворителен, т.к. простейший запрос «выдать список людей в порядке возрастания дат рождения» даст заведомо неправильных ответ.
Для того чтобы обойти проблему неполных или неизвестных данных, в базах данных могут использоваться типы данных, пополненные так называемым null-значением. Null-значение — это, собственно, не значение, а некий маркер, показывающий, что значение неизвестно.
Таким образом, в ситуации, когда возможно появление неизвестных или неполных данных, разработчик имеет на выбор два варианта.
Первый вариант состоит в том, чтобы ограничиться использованием обычных типов данных и не использовать null-значения, а вместо неизвестных данных вводить либо нулевые значения, либо значения специального вида — например, договориться, что строка «АДРЕС НЕИЗВЕСТЕН» и есть те данные, которые нужно вводить вместо неизвестного адреса. В любом случае на пользователя (или на разработчика) ложится ответственность на правильную трактовку таких данных. В частности, может потребоваться написание специального программного кода, который в нужных случаях «вылавливал» бы такие данные. Проблемы, возникающие при этом очевидны — не все данные становятся равноправны, требуется дополнительный программный код, «отслеживающий» эту неравноправность, в результате чего усложняется разработка и сопровождение приложений.
Второй вариант состоит в использовании null-значений вместо неизвестных данных. За кажущейся естественностью такого подхода скрываются менее очевидные и более глубокие проблемы. Наиболее бросающейся в глаза проблемой является необходимость использования трехзначной логики при оперировании с данными, которые могут содержать null-значения. В этом случае при неаккуратном формулировании запросов, даже самые естественные запросы могут давать неправильные ответы. Есть более фундаментальные проблемы, связанные с теоретическим обоснованием корректности введения null-значений, например, непонятно вообще, входят ли null-значения в домены или нет.
Вопрос о проблемах использования null-значений в теории реляционных баз данных окончательно не решен. Основоположник реляционного подхода Кодд считал null-значения неотъемлемой частью реляционной модели, хотя К. Дейт выступает против null-значений.
Домен (базы данных)
Домен — допустимое потенциальное ограниченное подмножество значений данного типа. Например, домен ИМЕНА определен на базовом типе строк символов, но в число его значений могут входить только те строки, которые могут представлять имена (в частности, для возможности представления русских имен такие строки не могут начинаться с мягкого или твердого знака и не могут быть длиннее, например, 20 символов). В один домен могут входить значения из нескольких колонок, объединённых, помимо одинакового типа данных, ещё и логически. Если два значения берутся из одного и того же домена, то можно выполнить сравнение этих двух значений.
Более простое определение домена — это допустимое потенциальное множество значений одного типа.
- Найти и оформить в виде сносок ссылки на авторитетные источники, подтверждающие написанное.
- Проставив сноски, внести более точные указания на источники.
- Дополнить статью (статья слишком короткая либо содержит лишь словарное определение).
- Теоретические основы баз данных
Wikimedia Foundation . 2010 .
Полезное
Смотреть что такое «Домен (базы данных)» в других словарях:
Реляционные базы данных — Реляционная база данных база данных, основанная на реляционной модели данных. Слово «реляционный» происходит от англ. relation (отношение[1]). Для работы с реляционными БД применяют реляционные СУБД. Использование реляционных баз данных было… … Википедия
Таблица (базы данных) — У этого термина существуют и другие значения, см. Таблица (значения). Таблица (англ. table) (в реляционной модели данных) структура хранения данных, состоящая из строк и столбцов и обладающая следующими свойствами: значения, находящиеся в одном… … Википедия
Домен — (фр. domaine) область; единица структуры: В Викисловаре есть статья «домен» … Википедия
Интеграция данных — включает объединение данных, находящихся в различных источниках и предоставление данных пользователям в унифицированном виде. Этот процесс становится существенным как в коммерческих задачах (когда двум похожим компаниям необходимо объединить их… … Википедия
Реляционная база данных — Реляционная база данных база данных, основанная на реляционной модели данных. Слово «реляционный» происходит от англ. relation (отношение[1]). Для работы с реляционными БД применяют реляционные СУБД. Использование реляционных баз… … Википедия
ГОСТ Р ИСО/МЭК ТО 10032-2007: Эталонная модель управления данными — Терминология ГОСТ Р ИСО/МЭК ТО 10032 2007: Эталонная модель управления данными: 2.36 база данных (database): Совокупность данных, хранимых в соответствии со схемой данных, манипулирование которыми выполняют в соответствии с правилами средств… … Словарь-справочник терминов нормативно-технической документации
Дескрипционная логика — Описательные логики[1] или дескрипционные логики[2][источник не указан 861 день](сокр. ДЛ, англ. description logics, иногда используется неточный перевод: дескриптивные логики) семейство языков представления знаний … Википедия
информационный — 3.1.24 информационный (informative): По ИСО/МЭК 14252. Источник: Р 50.1.041 2002: Информационные технологии. Руководство по проектированию профилей … Словарь-справочник терминов нормативно-технической документации
Miranda IM — У этого термина существуют и другие значения, см. Миранда. Miranda IM … Википедия
ДНС — DNS Название: Domain Name System Уровень (по модели OSI): Прикладной Семейство: TCP/IP Порт/ID: 53/UDP Назначение протокола: Разрешение доменных имён Спецификация: RFC 1034, RFC 1035 / STD 13 Основные реализации (клиен … Википедия
Основы проектирования баз данных
Качество проектирования базы данных может влиять на работу с ней. С хорошо спроектированной базой данных легче работать, легче писать к ней запросы. И в данном руководстве мы рассмотрим основные принципы проектирования баз данных.
Для качественного проектирования базы данных существуют различные методики, различные последовательности шагов или этапов, которые во многом похожи. И в целом мы можем выделить следующие этапы:
Выделение сущностей и их атрибутов, которые будут храниться в базе данных, и формирование по ним таблиц. Атомизация сложных атрибутов на более простые.
Определение уникальных идентификаторов (первичных ключей) объектов, которые хранятся в строках таблицы
Определение отношений между таблицами с помощью внешних ключей
Нормализация базы данных
На первом этапе происходит выделение сущностей. Сущность (entity) представляет тип объектов, которые должны храниться в базе данных. Каждая таблица в базе данных должна представлять одну сущность. Как правило, сущности соответствуют объектам из реального мира.
У каждой сущности определяют набор атрибутов. Атрибут представляет свойство, которое описывает некоторую характеристику объекта.
Каждый столбец должен хранить один атрибут сущности. А каждая строка представляет отдельный объект или экземпляр сущности.
Восходящий и нисходящий подходы
При проектировании базы данных на этапе выделения сущностей и их атрибутов мы можем использовать два подхода: восходящий и нисходящий.
Восходящий подход предусматривает выделение необходимых атрибутов, которые надо сохранить в бд. Затем выделенные атрибуты группируются в сущности, для которых впоследствии создается таблицы. Такой подход больше подходит для проектирования небольших баз данных с небольшим количеством атрибутов.
Например, нам дана следующая информация:
Какие данные из этой информации мы можем сохранить: имя студента, название курса, учебная должность преподавателя, имя преподавателя, электронный адрес студента.
Затем мы можем выполнить группировку по сущностям, к которым относятся эти данные:
Дата рождения студента
Электронный адрес студента
Так, те данные, которые имеются позволяют выделить три сущности: студент, преподаватель и курс. При этом мы вполне можем добавлять какие-то недостающие данные. Также следует отметить, что какие-то данные могут иметь отношение к разным сущностям. Например, курс хранит информацию о студенте, которые его посещает. А студент хранит информацию о посещаемом курсе. Подобная избыточность данных решается на последующих шагах проектирования в процессе нормализации базы данных.
Но подобных атрибутов может оказаться очень много: сотни и даже тысячи. И в этом случае более оптимальным будет нисходящий подход. Данный подход подразумевает выявление сущностей. Затем происходит анализ сущностей, выявляются связи между ними, а потом и атрибуты сущностей.
То есть в данном случае мы могли бы сразу определить, что нам надо хранить данные по студентам, курсам и преподавателям. Затем в рамках каждой сущности выявить атрибуты
Например, у сущности «Студент» мы могли бы выделить такие атрибуты, как имя студента, его адрес, телефон, рост, вес, год его рождения. В тоже время нам надо учитывать не вообще все свойства, которые в принципе могут быть у сущности «Студент», а только те, которые имеют значение в рамках описываемой системы. Вряд ли в данном случае играют роль такие свойства как рост или вес студента, поэтому мы можем их вычеркнуть из списка атрибутов при проектировании таблицы.
Иногда подходы комбинируются. Для описания разных частей системы могут использоваться разные подходы. А затем их результаты объединяются.
Атомизация атрибутов
При определении атрибутов происходит разделение сложных комплексных элементов на более простые. Так, в случае с именем студента мы можем его разбить на собственно имя и фамилию. Это позволит впоследствии выполнять операции с эти подэлементами отдельно, например, сортировать студентов только по фамилии.
То же самое касается адреса — мы можем сохранить весь адрес целиком, а можем разбить его на части — дом, улицу, город и т.д.
В то же время возможность разделения одного элемента на подэлементы не всегда может быть востребованной. В ряде задач это может быть просто не нужно. Выделять необходимо только те элементы, которые действительно нужны.
В соответствии с этим аспектом мы можем выделить у сущности «Студент» следующие атрибуты: имя студента, фамилия студента, год рождения, город, улица, дом, телефон.
Домен
Каждый атрибут имеет домен (domain). Домен представляет набор допустимых значений для одного или нескольких атрибутов. По сути домен определяет смысл и источник значений, которые могут иметь атрибуты.
Домены могут отличаться для разных атрибутов, но также несколько атрибутов могут иметь один домен.
Например, выше были определены атрибуты сущности Студент. Определим используемые домены:
Имя . Домен представляет все возможные имена, которые могут использоваться. Каждое имя представляет строку длиной максимум 20 символов (маловероятно, что нам могут встретиться имена свыше 20 символов).
Фамилия . Домен представляет все возможные фамилии, которые могут использоваться. Каждая фамилия представляет строку длиной максимум 20 символов.
Год рождения . Домен представляет все года рождения. Каждый год является числовым значением от 1950 до 2017.
Город . Домен представляет все города текущей страны. Каждый город представляет строку длиной максимум 50 символов.
Улица . Домен представляет все улицы текущей страны. Каждая улица представляет строку длиной максимум 50 символов.
Дом . Домен представляет все возможные номера домов. Каждый номер дома является числом от 1 до, скажем, 10000.
Телефон . Домен представляет все возможные телефонные номера. Каждый номер является строкой длиной в 11 символов.
Определяя домен, мы сразу видим, какие данные и каких типов будут хранить атрибуты. Какое-то другое значение, которое не соответствует домену, атрибут иметь не может.
В примере выше каждый атрибут имеет свой домен. Но, домены могут совпадать. Например, если бы сущность содержала бы следующие два атрибута: город рождения и город проживания, то домен бы совпадал и был бы одним и тем же для обоих атрибутов.
Определитель NULL
При определении атрибутов и их домена необходимо проанализировать, а может ли у атрибута отсутствовать значение. Определитель NULL позволяет задать отсутствие значения. Например, в примере выше у студента обязательно должно быть какое-либо имя, поэтому недопустима ситуация, когда у атрибута, который представляет имя, отсутствует значение.
В то же время студент может не иметь телефонного номера или в рамках системы телефон не обязателен. Поэтому на этапе проектирования таблицы можно указать, что данный атрибут позволяет значение NULL.
Как правило, большинство современных реляционных СУБД поддерживают определитель NULL и позволяют задать его допустимость для столбца таблицы.
Основы реляционной алгебры
Реляционная алгебра базируется на теории множеств и является основой логики работы баз данных.
Когда я только изучал устройство баз данных и SQL, предварительное ознакомление с реляционной алгеброй очень помогло дальнейшим знаниям правильно уложиться в голове, и я постараюсь что бы эта статья произвела подобный эффект.
Так что если вы собираетесь начать свое обучение в этой области или вам просто стало интересно, прошу под кат.
Реляционная база данных
Для начала введем понятие реляцинной базы данных, в которой будем выполнять все действия.
Реляционной базой данных называется совокупность отношений, содержащих всю информацию, которая должна хранится в базе. В данном определении нам интересен термин отношение, но пока оставим его без строго определения.
Лучше представим себе таблицу продуктов.
таблица PRODUCTS
| ID | NAME | COMPANY | PRICE |
| 123 | Печеньки | ООО ”Темная сторона” | 190 |
| 156 | Чай | ООО ”Темная сторона” | 60 |
| 235 | Ананасы | ОАО ”Фрукты” | 100 |
| 623 | Томаты | ООО ”Овощи” | 130 |
Таблица состоит из 4х строк, строка в таблице является кортежем в реляционной теории. Множество упорядоченных кортежей называется отношением.
Перед тем как дать определение отношения, введем еще один термин — домен. Домены применительно к таблице это столбцы.
Для ясности, теперь введем строгое определение отношения.
Пусть даны N множеств D1,D2, …. Dn (домены), отношением R над этими множествами называется множество упорядоченных N-кортежей вида <d1,d1. dn>, где d1 принадлежит D1 и тд. Множества D1,D2. Dn называются доменами отношения R.
Каждый элемент кортежа представляет собой значение одного из атрибутов, соответствующего одному из доменов.
Ключи в отношениях
В отношении требованием является то, что все кортежи должны различаться. Для однозначной идентификации кортежа существует первичный ключ. Первичный ключ это атрибут или набор из минимального числа атрибутов, который однозначно идентифицирует конкретный кортеж и не содержит дополнительных атрибутов.
Подразумевается, что все атрибуты в первичном ключе должны быть необходимыми и достаточными для идентификации конкретного кортежа, и исключение любого из атрибутов в ключе сделает его недостаточным для идентификации.
Например, в такой таблице ключом будет сочетание атрибутов из первого и второго столбца.
| COMPANY | DRIVER |
| ООО ”Темная сторона” | Владимир |
| ООО ”Темная сторона” | Михаил |
| ОАО ”Фрукты” | Руслан |
| ООО ”Овощи” | Владимир |
Видно, что в организации может быть несколько водителей, и чтобы однозначно идентифицировать водителя необходимо и значение из столбца “Название организации” и из “Имя водителя”. Такой ключ называется составным.
В реляционной БД таблицы взаимосвязаны и соотносятся друг с другом как главные и подчиненные. Связь главной и подчиненнной таблицы осуществляется через первичный ключ (primary key) главной таблицы и внешний ключ ( foreign key ) подчиненной таблицы.
Внешний ключ это атрибут или набор атрибутов, который в главной таблице является первичным ключем.
Этой подготовительной теории будет достаточно для знакомства с основными операциями реляционной алгебры.
Операции реляционной алгебры
- Объединение
- Пересечение
- Вычитание
- Декартово произведение
- Выборка
- Проекция
- Соединение
- Деление
Для понимания важно запомнить, что результатом любой операции алгебры над отношениями является еще одно отношение, которое можно потом так же использовать в других операциях.
Создадим еще одну таблицу, которая нам пригодится в примерах.
| ID | SELLER |
| 123 | OOO “Дарт” |
| 156 | ОАО ”Ведро” |
| 235 | ЗАО “Овоще База” |
| 623 | ОАО ”Фирма” |
Условимся, что в этой таблице ID это внешний ключ, связанный с первичным ключом таблицы PRODUCTS.
Для начала рассмотрим самую простую операцию — имя отношения. Её результатом будет такое же отношение, то есть выполнив операцию PRODUCTS, мы получим копию отношения PRODUCTS.
Проекция
Проекция является операцией, при которой из отношения выделяются атрибуты только из указанных доменов, то есть из таблицы выбираются только нужные столбцы, при этом, если получится несколько одинаковых кортежей, то в результирующем отношении остается только по одному экземпляру подобного кортежа.
Для примера сделаем проекцию на таблице PRODUCTS выбрав из нее ID и PRICE.
Синтаксис операции:
π (ID, PRICE) PRODUCTS
В результате этой операции получим отношение:
| ID | PRICE |
| 123 | 190 |
| 156 | 60 |
| 235 | 100 |
| 623 | 130 |
Выборка
Выборка — это операция, которая выделяет множество строк в таблице, удовлетворяющих заданным условиям. Условием может быть любое логическое выражение.
Для примера сделаем выборку из таблицы с ценой больше 90.
Синтаксис операции:
σ (PRICE>90) PRODUCTS
| ID | NAME | COMPANY | PRICE |
| 123 | Печеньки | ООО ”Темная сторона” | 190 |
| 235 | Ананасы | ОАО ”Фрукты” | 100 |
| 623 | Томаты | ООО ”Овощи” | 130 |
В условии выборки мы можем использовать любое логическое выражение. Сделаем еще одну выборку с ценой больше 90 и ID товара меньше 300:
σ (PRICE>90 ^ ID<300) PRODUCTS
| ID | NAME | COMPANY | PRICE |
| 123 | Печеньки | ООО ”Темная сторона” | 190 |
| 235 | Ананасы | ОАО ”Фрукты” | 100 |
Совместим операторы проекции и выборки. Мы можем это сделать, потому что любой из операторов в результате возвращает отношение и в качестве аргументов использует также отношение.
Из таблицы с продуктами выберем все компании, продающие продуты дешевле 110.
π COMPANY σ (PRICE<100 ) PRODUCTS
| COMPANY |
| ООО ”Темная сторона” |
| ОАО ”Фрукты” |
Умножение
Умножение или декартово произведение является операцией, производимой над двумя отношениями, в результате которой мы получаем отношение со всеми доменами из двух начальных отношений. Кортежи в этих доменах будут представлять из себя все возможные сочетания кортежей из начальных отношений. На примере будет понятнее.
Получим декартово произведения таблиц PRODUCTS и SELLERS.
Синтаксис операции:
PRODUCTS × SELLERS
Можно заметить, что у двух этих таблиц есть одинаковый домен ID. В подобной ситуации домены с одинаковыми названиями получают префикс в виде названия соответствующего отношения, как показано ниже.
Для краткости перемножим не полные отношения, а выборки с условием ID<235
(цветом выделены одни и те же кортежи)
| PRODUCTS.ID | NAME | COMPANY | PRICE | SELLERS.ID | SELLER |
| 123 | Печеньки | ООО ”Темная сторона” | 190 | 123 | OOO “Дарт” |
| 156 | Чай | ООО ”Темная сторона” | 60 | 156 | ОАО ”Ведро” |
| 123 | Печеньки | ООО ”Темная сторона” | 190 | 156 | ОАО ”Ведро” |
| 156 | Чай | ООО ”Темная сторона” | 60 | 123 | OOO “Дарт” |
Для примера использования этой операции представим себе необходимость выбрать продавцов с ценами меньше 90. Без произведения необходимо было бы сначала получить ID продуктов из первой таблицы, потом по этим ID из второй таблицы получить нужные имена SELLER, а с использованием произведения будет такой запрос:
π (SELLER) σ (RODUCTS.ID=SELLERS.ID ^ PRICE<90) PRODUCTS × SELLERS
В результате этой операции получим отношение:
| SELLER |
| ОАО ”Ведро” |
Соединение и естественное соединение
Операция соединения обратна операции проекции и создает новое отношение из двух уже существующих. Новое отношение получается конкатенацией кортежей первого и второго отношений, при этом конкатенации подвергаются отношения, в которых совпадают значения заданных атрибутов. В частности, если соединить отношения PRODUCTS и SELLERS, этими атрибутами будут атрибуты доменов ID.
Также для понятности можно представить соеднинение как результат двух операций. Сначала берется произведение исходных таблиц, а потом из полученного отношения мы делаем выборку с условием равенства атрибутов из одинаковых доменов. В данном случае условием явлется равенство PRODUCTS.ID и SELLERS.ID.
Попробуем соединить отношения PRODUCTS и SELLERS и получим отношение.
| PRODUCTS.ID | NAME | COMPANY | PRICE | SELLERS.ID | SELLER |
| 123 | Печеньки | ООО ”Темная сторона” | 190 | 123 | OOO “Дарт” |
| 156 | Чай | ООО ”Темная сторона” | 60 | 156 | ОАО ”Ведро” |
| 235 | Ананасы | ОАО ”Фрукты” | 100 | 235 | ЗАО “Овоще База” |
| 623 | Томаты | ООО ”Овощи” | 130 | 623 | ОАО ”Фирма” |
Натуральное соединение получает схожее отношение, но в случае, если у нас корректно настроена схема в базе ( в данном случае первичный ключ таблицы PRODUCTS ID связан с внешним ключем таблицы SELLERS ID), то в результирующем отношении остается один домен ID.
Синтаксис операции:
PRODUCTS ⋈ SELLERS;
Получится такое отношение:
| PRODUCTS.ID | NAME | COMPANY | PRICE | SELLER |
| 123 | Печеньки | ООО ”Темная сторона” | 190 | OOO “Дарт” |
| 156 | Чай | ООО ”Темная сторона” | 60 | ОАО ”Ведро” |
| 235 | Ананасы | ОАО ”Фрукты” | 100 | ЗАО “Овоще База” |
| 623 | Томаты | ООО ”Овощи” | 130 | ОАО ”Фирма” |
Пересечение и вычитание.
Результатом операции пересечения будет отношение, состоящее из кортежей, полностью входящих в состав обоих отношений.
Результатом вычитания будет отношение, состоящее из кортежей, которые являются кортежами первого отношения и не являются кортежами второго отношения.
Данные операции аналогичны таким же операциям над множествам, так что, я думаю, нет необходимости подробно их расписывать.