Домен в бд: What is a data domain? (examples included)

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

Последнее обновление: 02.07.2017

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

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

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

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

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

4. Нормализация базы данных

На первом этапе происходит выделение сущностей.

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

У каждой сущности определяют набор атрибутов. Атрибут представляет свойство, которое описывает некоторую характеристику объекта.

Каждый столбец должен хранить один атрибут сущности. А каждая строка представляет отдельный объект или экземпляр сущности.

Восходящий и нисходящий подходы

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

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

Например, нам дана следующая информация:

Том посещает курс по математике, который преподает профессор Смит. 
Сэм посещает курс по математике, которые преподает профессор Смит.
Том посещает курс по языку JavaScript, который преподает ассистент Адамс.
Боб посещает курс по алгоритмам, который преподает ассистент Адамс.
Сэм имеет следующие электронный адрес [email protected] и телефон +1235768789.

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

Затем мы можем выполнить группировку по сущностям, к которым относятся эти данные:

Студент	Преподаватель	Курс
Имя студента Название курса Дата рождения студента Электронный адрес студента Телефон студента	Имя преподавателя Должность преподавателя Название курса	Имя студента Имя преподавателя Название курса

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

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

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

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

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

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

Атомизация атрибутов

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

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

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

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

Домен

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

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

Например, выше были определены атрибуты сущности Студент. Определим используемые домены:

• Имя. Домен представляет все возможные имена, которые могут использоваться. Каждое имя представляет строку длиной максимум 20 символов (маловероятно, что нам могут встретиться имена свыше 20 символов).

• Фамилия. Домен представляет все возможные фамилии, которые могут использоваться. Каждая фамилия представляет строку длиной максимум 20 символов.

• Год рождения. Домен представляет все года рождения. Каждый год является числовым значением от 1950 до 2017.

• Город. Домен представляет все города текущей страны. Каждый город представляет строку длиной максимум 50 символов.

• Улица. Домен представляет все улицы текущей страны. Каждая улица представляет строку длиной максимум 50 символов.

• Дом. Домен представляет все возможные номера домов. Каждый номер дома является числом от 1 до, скажем, 10000.

• Телефон. Домен представляет все возможные телефонные номера. Каждый номер является строкой длиной в 11 символов.

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

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

Определитель NULL

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

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

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

СодержаниеВперед

ГЛОССАРИЙ — Российский НИИ Развития Общественных сетей

ICANN — Internet Corporation for Assigned Names and Numbers (официальный сайт — http://www.icann.org/)

Администратор (регистрант) — пользователь,на имя которого зарегистрировано доменное имя в Реестре базы данных ДВУ . SU.

Администрирование — осуществление администратором (регистрантом) прав и обязанностей, установленных настоящими Правилами.

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

Аннулирование регистрации — исключение информации о доменном имени из Реестра базы данных ДВУ .SU.

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

ДВУ (англ. TLD (top-level domain) — домен верхнего уровня.

ДВУ .SU — домен верхнего уровня с уникальным обозначением «su».

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

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

Доменное имя — символьное обозначение домена второго уровня, состоящее из собственного обозначения (или имени домена) и символов домена верхнего уровня».SU» (например: именем домена второго уровня «example.su» является «example»), предназначенное для сетевой адресации, в которой используется система доменных имен (DNS).

Период преимущественного продления — период времени после истечения срока регистрации доменного имени, в течение которого за прежним администратором (регистрантом) сохраняется право продления регистрации доменного имени.

Поддержка сведений о доменном имени — действия регистратора по внесению, изменению и удалению сведений в Реестре базы данных ДВУ .SU, относящихся к доменному имени и его администратору (регистранту).

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

Правила — Правила регистрации и условия использования доменных имен в домене .SU.

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

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

Представление доменного имени (представление) — доменное имя,содержащее буквы латинского алфавита, цифры и дефисы. Представление является результатом преобразования доменного имени в соответствии с алгоритмом PUNYCODE (приведенным в технических стандартах RFC-3490, 3491, 3492).

Продление регистрации доменного имени — внесение в Реестр базы данных ДВУ .SU сведений о продлении срока регистрации доменного имени.

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

Регистратура (Администратор, ccTLD Manager) ДВУ .SU — АНО «РосНИИРОС» (официальный сайт — https://www.ripn.su). Лицо, признанное ICANN в качестве уполномоченного лица по управлению, обслуживанию и поддержке ДВУ .SU. Регистратура ДВУ.SU осуществляет контроль над доменным пространством домена верхнего уровня .SU и поддерживает систему доменных имен, формирует (организует формирование) базы данных ДВУ .SU, являясь доверительным управляющим ДВУ .SU для мирового Интернет-сообщества. Регистратура осуществляет управление ДВУ .SU, устанавливает правила и процедуры регистрации доменов и принципы формирования базы данных доменных имен второго уровня в ДВУ .SU.

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

Регистратор-донор — регистратор, передающий регистратору-реципиенту поддержку сведений о доменном имени.

Регистратор-реципиент — регистратор, принимающий от регистратора-донора поддержку сведений о доменном имени.

Регистрация доменного имени — внесение в Реестр базы данных ДВУ .SU сведений о доменном имени, его администраторе и иных сведений, установленных Правилами.

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

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

Database Design — Introduction

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

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

Издания

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

• Обновите все веб-страницы, чтобы использовать элементы HTML, соответствующие их содержанию. Для например, используйте списки, в которых указана информация, использование HTML5 элементы раздела (статья, раздел и т. д.), используйте элемент рисунка в качестве контейнера изображений и т. д. Удалите использование устаревших элементов/атрибутов HTML.
• Обновляет определения стилей CSS по мере необходимости, чтобы учесть изменения в HTML.
• Использование символов UTF-8, а не символов HTML.
• Интегрирует Highlight.js, библиотека подсветки синтаксиса, встроенная в JavaScript и используется на этом веб-сайте для выделения примеров операторов SQL.
• Исправьте ошибки в представленном синтаксисе SQL и предоставьте альтернативный синтаксис SQL.
• Расширение пояснений некоторых понятий, которые вызывают затруднения у некоторых учащихся на основе многолетнего опыта преподавания. Например, студенты часто путают использование ассоциативных классов и многие-ко-многим с историей шаблон дизайна. Объяснение этого было изменено, и дополнительная информация предоставлен в попытке сделать эти (и другие концепции) более ясными.
• Организовали тематические страницы, добавив больше заголовков для структурирования контента.

Предыдущие издания

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

1. Третье издание dbDesign представляет собой общее обновление, требованиям доступности «Раздел 508» США и ввести код в соответствие последним стандартам World Wide Web Consortium. В процессе, Я попытался сделать примеры SQL как можно более общими, хотя вы все равно придется обращаться к документации по вашей собственной системе баз данных. Для графики больше не требуется плагин SVG; большие изображения и только текст просмотр каждой графики предоставляется всем читателям; в меню теперь упорядочено по тематическим областям; и версия для печати (минус левосторонняя навигация) выполняется автоматически таблицей стилей.
2. Второе издание было в значительной степени мотивировано очень полезным комментарии профессора Альваро Монжа, а также Собственные наблюдения Тома Джуэтта в двух семестров использования своего предшественника в классе. Основные изменения включали четкое разделение UML от его реализации в реляционной модели, введение терминологии реляционной алгебры в помощь пониманию SQL, и повышенный акцент на естественном понимании дизайна.
3. Первоначальный сайт был продуктом предыдущей книги проект Практическая разработка реляционной базы данных (PRDD), Уэйн Дик и Том Джуэтт. Движение в Интернете сопровождалось сжатыми обсуждениями, комплексное представление концепций и навыков работы с базами данных, и использование унифицированного языка моделирования в процессе проектирования. Я благодарны за положительный ответ, который сайт получил до сих пор, оба от моих собственных учеников и от онлайн-читателей со всего мира.

Благодарности

• В 2002 году Том Джуэтт воплотил в жизнь книжный проект PRDD в Интернете. Инструкторы CSULB из вводного класса по базам данных (CECS 323) использовали эту онлайн-книгу все эти годы и сделали это с отличными результатами. Тяжелая работа, самоотверженность и профессионализм Тома сделала эту онлайн-книгу успешной. В 2014 году он передал этот проект Альваро Монже, который надеется продолжить великую работу, которую он и Уэйн Дик начали много лет назад и которая Том принес в Интернет с большим успехом.
• В каждом выпуске этого сайта огромный долг благодарности Профессор Уэйн Дик, ведущий автор более ранней книги PRDD и всемирно известный Эксперт по доступности. За годы работы он внес большой вклад в в базах данных, которые пробились на этот интернет-ресурс.

Альваро Монж
Кафедра вычислительной техники и компьютерных наук
Калифорнийский государственный университет, Лонг-Бич,
Альваро Монж
электронная почта: [email protected]

Атрибутные домены | Типы (описание проекта)

• RelationalDB
• Реляционная база данных
• Структура реляционной базы данных
• Жизненный цикл базы данных
• Анализ требований
• Атрибуты объектов

Урок 6	Домены атрибутов
Цель	Описание атрибутивных доменов и типов доменов

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

1. Тип данных: Домены определяют тип данных атрибута, например, целые числа, числа с плавающей запятой, строки, даты или логические значения. Это гарантирует, что в каждом атрибуте будут храниться только данные правильного типа.
2. Ограничения: Домены также могут включать ограничения или правила, дополнительно ограничивающие допустимые значения атрибута. Например, в домене может быть указано, что целочисленный атрибут должен быть положительным числом, или строковый атрибут должен иметь максимальную длину.
3. Уникальность: Домены могут применять ограничения уникальности, гарантируя, что никакие две строки в таблице не будут иметь одинаковое значение определенного атрибута. Это обычно используется для первичных ключей, которые однозначно идентифицируют каждую строку в таблице.
4. Ссылочная целостность: Домены могут использоваться для обеспечения ссылочной целостности путем определения отношений внешнего ключа между таблицами. Это гарантирует, что значения в атрибуте внешнего ключа должны совпадать со значениями в указанном атрибуте первичного ключа, обеспечивая согласованность данных между связанными таблицами.
5. Значения по умолчанию: Домены могут указывать значения по умолчанию для атрибута, которые используются, когда новая строка вставляется в таблицу без указания значения для этого атрибута.
6. Правила проверки: Домены могут определять пользовательские правила проверки, чтобы гарантировать, что данные, хранящиеся в атрибуте, соответствуют определенным бизнес-требованиям или правилам.

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

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

 S, M, L.
 

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

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

1. символов,
2. цифр,
3. валюты,
4. дат,
5. раз и
6. логических значений (логическое значение либо истинно, либо ложно).

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

Выбор правильного типа домена

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

Принудительное применение доменов

РСУБД использует ограничения домена ^[1] для принудительного применения доменов атрибутов. Когда пользователь вводит значение данных, РСУБД проверяет, разрешает ли домен, назначенный этому атрибуту, это значение.