|
|
@@ -1,343 +0,0 @@
|
|
|
-[содержание](/readme.md)
|
|
|
-
|
|
|
-# Проектирование баз данных.
|
|
|
-
|
|
|
->Основано на книге "Реляционные базы данных в примерах", полный текст книги см. в каталоге `docs` этого репозитория
|
|
|
-
|
|
|
-<!--
|
|
|
-https://pro-prof.com/forums/topic/db_example
|
|
|
-https://habr.com/ru/post/193136/
|
|
|
-https://metanit.com/sql/tutorial/
|
|
|
-https://se.ifmo.ru/education/documentation/dbguide/
|
|
|
-https://se.ifmo.ru/education/documentation/dbguide/
|
|
|
--->
|
|
|
-
|
|
|
-## Данные и базы данных
|
|
|
-
|
|
|
-**Данные (data)** — поддающееся различной интерпретации представление информации в формализованном виде, пригодном для передачи, связи, или обработки.
|
|
|
-
|
|
|
-*Упрощённо: информация, организованная по определённым правилам.*
|
|
|
-
|
|
|
-Ключевых моментов здесь два.
|
|
|
-
|
|
|
-**Во-первых**, информация должна быть представлена в формализованном виде (иными словами, подчиняться неким правилам). Для наглядности приведём пример неформализованного и формализованного представления информации:
|
|
|
-
|
|
|
-
|
|
|
-
|
|
|
-**Во-вторых**, различная интерпретация позволяет нам по-разному воспринимать одни и те же данные в разном контексте. Например, поле pass (пропуск) может быть интерпретировано так:
|
|
|
-
|
|
|
-* номер пропуска сотрудника;
|
|
|
-* поле с уникальным значением;
|
|
|
-* число;
|
|
|
-* естественный первичный ключ отношения;
|
|
|
-* кластерный индекс {110} таблицы;
|
|
|
-* и т.д.
|
|
|
-
|
|
|
-Когда данных становится достаточно много, появляется необходимость в их организации в более сложные структуры.
|
|
|
-
|
|
|
-**База данных (database)** — совокупность данных, организованных в соответствии с концептуальной структурой, описывающей характеристики этих данных и взаимоотношения между соответствующими сущностями и поддерживающей одну или более областей применения.
|
|
|
-
|
|
|
-*Упрощённо: большой объём данных, взаимосвязь между которыми построена по специальным правилам.*
|
|
|
-
|
|
|
-Итак, база данных — это большая совокупность данных, подчинённых дополнительным правилам. Такие правила зависят от вида базы данных, а за их соблюдение отвечает *система управления базами данных* (СУБД).
|
|
|
-
|
|
|
-**Система управления базами данных, СУБД (database management system, DBMS)** — система (базирующаяся на программном и аппаратном обеспечении) для описания, создания, использования, контроля и управления базами данных.
|
|
|
-
|
|
|
-*Упрощённо: программное средство, управляющее базами данных.*
|
|
|
-
|
|
|
->Стоит отметить важный для начинающих факт (т.к. очень часто можно услышать просьбу «показать СУБД»): подавляющее большинство СУБД не имеет никакого «человеческого интерфейса», представляет собой сервис (демон в *nix-системах) и взаимодействует с внешним миром по специальным протоколам (чаще всего, построенным поверх TCP/IP). Такие известные продукты как MySQL Workbench, Microsoft SQL Server
|
|
|
-Management Studio, Oracle SQL Developer и им подобные — это не СУБД, это лишь клиентское программное обеспечение, позволяющее нам взаимодействовать с СУБД.
|
|
|
-
|
|
|
-Итак, СУБД — это специальное программное обеспечение, предназначенное для управления базами данных. Поскольку в этой книге мы будем говорить исключительно о реляционных базах
|
|
|
-данных и реляционных же СУБД, можно сразу отметить, что взаимодействие с такими СУБД происходит путём выполнения SQL-запросов.
|
|
|
-
|
|
|
-## Моделирование баз данных
|
|
|
-
|
|
|
-**Модель базы данных (database model)** — способ описания базы данных с помощью формализованного (в т.ч. графического) языка на некотором уровне абстракции.
|
|
|
-
|
|
|
-*Упрощённо: описание базы данных, по которому она потом будет создана (по аналогии с проектом здания, по которому оно потом будет построено).*
|
|
|
-
|
|
|
-Особый интерес в данном определении представляет упоминание уровня абстракции. Получается, что у одной и той же базы данных может быть несколько моделей, отличающихся уровнем детализации и целью (например, общее описание данных и их взаимосвязей, описание структур данных, описание способов хранения и обработки данных и т.д.)
|
|
|
-
|
|
|
-Отсюда мы переходим к понятию уровней (этапов) моделирования и проектирования баз данных, т.е. к построению нескольких взаимосвязанных моделей базы данных, каждая из которых
|
|
|
-призвана служить своей особой цели.
|
|
|
-
|
|
|
-Прежде, чем мы рассмотрим каждый уровень необходимо дать
|
|
|
-ещё одно предельно важное пояснение, без которого вся эта информация может оказаться бесполезной.
|
|
|
-
|
|
|
-Как правило, студенты, изучающие базы данных и проектирующие их в
|
|
|
-рамках лабораторных, курсовых и дипломных работ, искренне не понимают, зачем нужны какие-то уровни, если можно просто «взять и спроектировать базу».
|
|
|
-
|
|
|
-Можно. В том случае, если база примитивная (до нескольких десятков таблиц), предметная область ограничивается уровнем сложности университетской работы, исходные требования просты и не меняются. Т.е. если вы проектируете однотипные и/или простые базы данных, вся
|
|
|
-эта «научная заумь» вам не понадобится. (Особенно, если вы сами и заказчик, и исполнитель, и ничто не мешает опустить руки и поменять требования, как только возникнет достаточно сложная задача.)
|
|
|
-
|
|
|
-Но! Представьте, что предметная область вам совершенно неизвестна (например, вы проектируете не очередную базу данных библиотеки, а информационное хранилище для исследовательского центра кардиохирургии).
|
|
|
-
|
|
|
-Добавьте к этому тот факт, что сам заказчик (в лице представителей этого центра) не сильно разбирается в информационных технологиях, и многое объясняет вам «на пальцах», причём в процессе работы многократно выясняется, что что-то было забыто, что-то вы не так поняли, что-то поменялось, чего-то не знал сам заказчик и т.д.
|
|
|
-
|
|
|
-Причём в этой ситуации, как правило, не удастся отказаться от реализации того или иного требования просто потому, что оно слишком сложное и/или вы не очень понимаете, как его реализовать.
|
|
|
-
|
|
|
-Также добавьте к этому тот факт, что база данных может состоять из сотен (и даже тысяч) таблиц, что к ней предъявляются достаточно жёсткие требования по надёжности, производительности и иным показателям качества.
|
|
|
-
|
|
|
-Учтите, что проектировать такую базу вы будете не в одиночку, а в составе команды (и всем участникам надо будет гарантированно понимать друг друга, согласовывать свои действия, подменять друг друга).
|
|
|
-
|
|
|
-В такой ситуации структурированный, управляемый, регламентированный подход к моделированию и проектированию критически необходим — без него создать работоспособную базу данных не получится. Никак.
|
|
|
-
|
|
|
-Возвращаемся к уровням моделирования.
|
|
|
-
|
|
|
-
|
|
|
-
|
|
|
-**Инфологический (концептуальный) уровень (conceptual level)** моделирования ставит своей целью создание т.н. концептуальной модели (conceptual model), отражающей основные сущности предметной области, их атрибуты и связи (возможно, пока не все)
|
|
|
-между сущностями.
|
|
|
-
|
|
|
-*Упрощённо: описание предметов и явлений реального мира, данные о которых потом будут помещены в базу данных.*
|
|
|
-
|
|
|
-Если продлить рисунок «вверх», к ещё меньшему уровню детализации, от непосредствен о работы с базами данных мы перейдём к области бизнес-анализа (business analysis), выявления
|
|
|
-общих требований заказчика и параметров предметной области.
|
|
|
-
|
|
|
-**Даталогический уровень (часто его называют просто «логическим», logical level)** моделирования детализирует инфологическую модель, превращая её в логическую схему, на которой ранее выявленные сущности, атрибуты и связи оформляются согласно правилам моделирования для выбранного вида базы данных (возможно,
|
|
|
-даже с учётом конкретной СУБД).
|
|
|
-
|
|
|
-*Упрощённо: описание предметов и явлений реального мира по правилам выбранной СУБД.*
|
|
|
-
|
|
|
-Во многих средствах проектирования баз данных, поддерживающих разделение лишь на «логическое» и «физическое» проектирование именно этот уровень называется «логическим».
|
|
|
-
|
|
|
-**Физический уровень (physical level)** моделирования продолжает детализацию и позволяет создать т.н. физическую схему, на которой максимально учитываются технические особенности работы конкретной СУБД и её возможности по организации и управлению структурами разрабатываемой базы данных и данными в ней.
|
|
|
-
|
|
|
-*Упрощённо: описание составных частей базы данных таким образом, чтобы на его основе можно было автоматически сгенерировать SQL-код для создания базы данных.*
|
|
|
-
|
|
|
-Если продлить рисунок «вниз», к ещё большему уровню детализации, от непосредственно работы с базами данных мы перейдём к области системного администрирования (конфигурирования СУБД, операционной системы, сетевой инфраструктуры и т.д.)
|
|
|
-
|
|
|
-Требования предъявляемые к любой базе данных (и, соответственно, её моделям):
|
|
|
-* адекватность предметной области;
|
|
|
-* удобство использования;
|
|
|
-* производительность;
|
|
|
-* защищённость данных.
|
|
|
-
|
|
|
-**Адекватность предметной области** выражается в том, что база данных должна позволять выполнять все необходимые операции, которые объективно нужны в реальной жизни в контексте той работы, для которой предназначена база данных.
|
|
|
-
|
|
|
-Лучше всего выполнить это требование позволяет моделирование на инфологическом уровне (т.к. этот уровень ближе всего находится к предметной области и требованиям заказчика), но для выявления некоторых ошибок неизбежно придётся анализировать и модели на других уровнях.
|
|
|
-
|
|
|
-А суть этого требования наиболее наглядно отражают примеры его нарушения.
|
|
|
-
|
|
|
-Сначала рассмотрим совершенно тривиальный пример. Допустим, для хранения информации о человеке было спроектировано отношение, представленное следующей схемой:
|
|
|
-
|
|
|
-
|
|
|
-
|
|
|
-Сразу же бросается в глаза, что `cpu_frequency` (частота процессора) не является характеристикой человека (по крайней мере, на сегодняшний день). А потому совершенно непонятно, что писать в это поле.
|
|
|
-
|
|
|
-Если немного подумать, также становится очевидным, что в этом отношении не хватает многих свойств, ведь характеристики человека не заканчиваются на фамилии, имени и отчестве.
|
|
|
-
|
|
|
-Рассмотрим чуть более близкий к реальности пример ошибки проектирования (здесь даже обойдёмся без рисунка). Допустим, мы разрабатываем базу данных для автоматизации работы
|
|
|
-деканата университета. Соответствующее приложение уже введено в эксплуатацию, прошло какое-то время, и тут нам звонят заказчики и спрашивают: «А как отметить, что студент ушёл в академический отпуск?»
|
|
|
-
|
|
|
-И мы вдруг понимаем, что... никак. Что мы не подумали о такой ситуации, и ни приложение (с которым работают сотрудники деканата), ни наша база данных не имеют возможности сохранить соответствующие данные.
|
|
|
-
|
|
|
-Эта ситуация является неприятной (придётся много переделывать), но она меркнет по сравнению со следующей — худшей из того, что может случиться.
|
|
|
-
|
|
|
-Рассмотрим третий (по-настоящему страшный) пример, продолжив тему автоматизации работы деканата. Допустим, что информация о взаимосвязи предметов, преподавателей и студентов хранилась в базе данных, представленной (упрощённо) следующей схемой:
|
|
|
-
|
|
|
-
|
|
|
-
|
|
|
-Все три отношения попарно соединены связями «многие ко многим», ведь действительно:
|
|
|
-* каждый студент изучает много предметов, и каждый предмет изучает много студентов;
|
|
|
-* каждый предмет может вести много преподавателей, и каждый преподаватель может вести много предметов;
|
|
|
-* каждый студент обучается у многих преподавателей, и каждый преподаватель обучает многих студентов.
|
|
|
-
|
|
|
-Допустим, разработанный продукт успешно введён в эксплуатацию, прошло много лет, и тут заказчик звонит и интересуется, как для очень важного отчёта показать список студентов, у которых профессор Иванов вёл высшую математику.
|
|
|
-
|
|
|
-Никак. Эта информация не сохранялась в базе данных. Там есть лишь информация о том, что профессор Иванов (вместе с ещё тремя десятками коллег) вёл высшую математику (и ещё восемь предметов). Есть информация о том, какие студенты учились у профессора Иванова, и какие студенты изучали высшую математику. Но никак невозможно определить, что вот именно этот конкретный студент изучал именно высшую математику (а не другой предмет) именно у профессора Иванова (а не у кого-то из его коллег).
|
|
|
-
|
|
|
-Этот пример потому и назван самым страшным, что тут ничего нельзя исправить. Даже если мы доработаем приложение и базу данных, требуемая заказчиком информация всё равно останется утерянной навсегда. А ведь заказчик был полностью уверен, что она есть и доступна.
|
|
|
-
|
|
|
-В принципе, при грамотном подходе к сбору требований такие ошибки (как в примерах про деканат) выявляются и при нисходящем проектировании, но намного легче заметить их при восходящем проектировании, когда мы задумываемся о том, какие конкретно задачи будет решать пользователь, и к выполнению каких запросов к базе данных это приведёт.
|
|
|
-
|
|
|
-Существует ещё одна форма нарушения адекватности предметной области — нарушения нормализации, которые приводят к возникновению аномалий операций с данными. Но этот вопрос настолько важен и обширен, что ему посвящён отдельный раздел.
|
|
|
-
|
|
|
-**Удобство использования** (в контексте проектирования баз данных) не связано с удобством для конечного пользователя (который может даже не знать, что в мире существуют какие-то базы данных). Этот термин относится к использованию базы данных в следующих ситуациях:
|
|
|
-
|
|
|
-* при взаимодействии с приложениями (в основном, здесь упор делается на простоту и лёгкость написания безошибочных запросов);
|
|
|
-* в процессе её дальнейшего развития (и тогда говорят о таких показателях качества, как поддерживаемость и сопровождаемость).
|
|
|
-
|
|
|
-Таким образом, речь идёт об «удобстве для программиста». Почему это важно? Чем лучше база данных отвечает данному требованию, тем проще и быстрее программисты могут организовать взаимодействие с ней, допуская минимум ошибок и с меньшими затратами решая вопросы
|
|
|
-быстродействия, безопасности и т.д.
|
|
|
-
|
|
|
-Прекрасной иллюстрацией разницы в удобстве использования базы данных в зависимости от её модели, может быть пример с определением номера дня недели и номера недели в месяце на основе указанной даты.
|
|
|
-Пока дата хранится в виде единого значения, приходится использовать запрос на целый экран, причём для каждой СУБД в нём появляется своя «магия» в виде числовых констант, слабо документированных параметров функций и тому подобных крайне опасных с точки зрения возможности допустить ошибку моментов.
|
|
|
-
|
|
|
-Но модель базы данных можно изменить. Можно хранить искомые значения в самой таблице (и вычислять их триггерами) или создать представление (и «замаскировать» соответствующий запрос в нём). Тогда для программиста, организующего взаимодействие приложения
|
|
|
-с базой данных задача сведётся к тривиальному SELECT длиной в пару строк.
|
|
|
-
|
|
|
-Рассмотрим ещё один очень простой и наглядный пример нарушения удобства использования. Предположим, что в некоторой базе данных фамилии и инициалы людей сохранены следующим образом:
|
|
|
-
|
|
|
-
|
|
|
-
|
|
|
-Здесь фамилия и инициалы сохранены в одной колонке, причём инициалы идут перед фамилией (и для наглядности представлены в нескольких вариантах, что вполне может встретиться в реальной жизни). Как теперь упорядочить список людей по алфавиту по фамилии?
|
|
|
-
|
|
|
-Теоретически можно написать функцию, учитывающую множество вариантов написания инициалов (например, «А.А.», «АА», «А. А. », «А .» и т.д. и т.п.), убирающую эту информацию и возвращающую только фамилию. И использовать эту функцию в запросах следующего вида:
|
|
|
-
|
|
|
-```sql
|
|
|
--- Упорядочивание списка людей по фамилии по алфавиту с удалением инициалов
|
|
|
-SELECT *
|
|
|
-FROM `person`
|
|
|
-ORDER BY REMOVE_INITIALS(`p_name`) ASC
|
|
|
-```
|
|
|
-
|
|
|
-Но такая функция будет сложной, медленной, может не учитывать некоторые варианты написания инициалов, а также сделает невозможным использование индексов для ускорения выполнения запроса (или потребует создания отдельного индекса над результатами своих вы-
|
|
|
-числений).
|
|
|
-
|
|
|
-Но всего лишь стоит поместить фамилии и инициалы в раздельные колонки, и ситуация мгновенно упрощается:
|
|
|
-
|
|
|
-
|
|
|
-
|
|
|
-Теперь нет необходимости как бы то ни было предварительно обрабатывать информацию, и значение фамилии можно использовать напрямую, что устраняет все недостатки решения с использованием функции. И запрос упрощается до следующего вида:
|
|
|
-
|
|
|
-```sql
|
|
|
--- Упорядочивание списка людей по фамилии по алфавиту с удалением инициалов
|
|
|
-SELECT *
|
|
|
-FROM `person`
|
|
|
-ORDER BY `p_surname` ASC
|
|
|
-```
|
|
|
-
|
|
|
-Подобные ситуации могут встречаться чаще, чем кажется. И их продумывание позволяет ощутимо повысить удобство использования базы данных.
|
|
|
-
|
|
|
-**Производительность** можно смело считать одним из самых больных вопросов в работе с базами данных, и решение соответствующих задач может быть описано несколькими отдельными книгами. Что стоит делать на любой стадии проектирования — так это как минимум помнить о
|
|
|
-производительности и не допускать создания таких моделей, в которых на ней будет поставлен крест изначально.
|
|
|
-
|
|
|
-Например, мы знаем, что для работы приложения понадобится очень часто выяснять количество записей в разных таблицах (как общее, так и количество неких особенных записей). В общем случае такие операции будут работать очень медленно, но с использованием кэширующих таблиц и материализованных представлений можно ценой небольшой потери производительности других операций в этом конкретном случае свести время выполнения запроса почти к нулю.
|
|
|
-
|
|
|
-Как правило, проблемы с удобством использования приводят к увеличению количества проблем с производительностью, т.к. сложные запросы тяжелее оптимизировать.
|
|
|
-
|
|
|
-**Защищённость данных** стоит воспринимать не только в контексте безопасности (ограничения доступа), но и в том смысле, что с данными не должно происходить никаких случайных непредвиденных изменений. Для достижения этой цели порой приходится продумывать огромное количество ограничений, реализуемых через специфические объекты базы данных и даже через отдельный интерфейс в виде набора хранимых процедур.
|
|
|
-
|
|
|
-## Реляционная модель данных
|
|
|
-
|
|
|
-**Реляционная модель (relational model)** — математическая теория, описывающая структуры данных, логику контроля целостности данных и правила управления данными.
|
|
|
-
|
|
|
-*Упрощённо: модель для описания реляционных баз данных.*
|
|
|
-
|
|
|
-На момент изобретения именно эта модель предоставила полный комплекс решений по описанию базы данных, контролю целостности данных и управлению данными — в отличие от множества других альтернативных подходов, позволяющих реализовать лишь часть задач. Сейчас кажется странным, что были какие-то другие «неполноценные решения», но напомним: это было в те времена, когда компьютер занимал несколько комнат и стоил, как половина здания, в кото-
|
|
|
-ром находится.
|
|
|
-
|
|
|
-## Создание базы данных и таблиц
|
|
|
-
|
|
|
-Для качественного проектирования базы данных существуют различные методики, различные последовательности шагов или этапов, которые во многом похожи. И в целом мы можем выделить следующие этапы:
|
|
|
-
|
|
|
-* Выделение *сущностей* и их *атрибутов*, которые будут храниться в базе данных, и формирование по ним таблиц. Атомизация сложных атрибутов на более простые.
|
|
|
-
|
|
|
-* Определение уникальных идентификаторов (первичных ключей) объектов, которые хранятся в строках таблицы
|
|
|
-
|
|
|
-* Определение отношений между таблицами с помощью внешних ключей
|
|
|
-
|
|
|
-* Нормализация базы данных
|
|
|
-
|
|
|
-На первом этапе происходит выделение *сущностей*. **Сущность** (entity) представляет тип объектов, которые должны храниться в базе данных. Каждая таблица в базе данных должна представлять одну сущность. Как правило, сущности соответствуют объектам из реального мира.
|
|
|
-
|
|
|
-У каждой сущности определяют набор *атрибутов*. **Атрибут** представляет свойство, которое описывает некоторую характеристику объекта.
|
|
|
-
|
|
|
-Каждый столбец должен хранить один атрибут сущности. А каждая строка представляет отдельный объект или экземпляр сущности.
|
|
|
-
|
|
|
-### Восходящий и нисходящий подходы
|
|
|
-
|
|
|
-При проектировании базы данных на этапе выделения сущностей и их атрибутов мы можем использовать два подхода: восходящий и нисходящий.
|
|
|
-
|
|
|
-Восходящий подход предусматривает выделение необходимых атрибутов, которые надо сохранить в бд. Затем выделенные атрибуты группируются в сущности, для которых впоследствии создается таблицы. Такой подход больше подходит для проектирования небольших баз данных с небольшим количеством атрибутов.
|
|
|
-
|
|
|
-Например, нам дана следующая информация:
|
|
|
-
|
|
|
-```
|
|
|
-Том посещает курс по математике, который преподает профессор Смит.
|
|
|
-Сэм посещает курс по математике, которые преподает профессор Смит.
|
|
|
-Том посещает курс по языку JavaScript, который преподает ассистент Адамс.
|
|
|
-Боб посещает курс по алгоритмам, который преподает ассистент Адамс.
|
|
|
-Сэм имеет следующие электронный адрес sam@gmail.com и телефон +1235768789.
|
|
|
-```
|
|
|
-
|
|
|
-Какие данные из этой информации мы можем сохранить:
|
|
|
-* имя студента,
|
|
|
-* название курса,
|
|
|
-* должность преподавателя,
|
|
|
-* имя преподавателя,
|
|
|
-* электронный адрес студента
|
|
|
-* телефон стулента.
|
|
|
-
|
|
|
-Затем мы можем выполнить группировку по сущностям, к которым относятся эти данные:
|
|
|
-
|
|
|
-Студент
|
|
|
-
|
|
|
-Преподаватель
|
|
|
-
|
|
|
-Курс
|
|
|
-
|
|
|
-Имя студента
|
|
|
-
|
|
|
-Название курса
|
|
|
-
|
|
|
-Дата рождения студента
|
|
|
-
|
|
|
-Электронный адрес студента
|
|
|
-
|
|
|
-Телефон студента
|
|
|
-
|
|
|
-Имя преподавателя
|
|
|
-
|
|
|
-Должность преподавателя
|
|
|
-
|
|
|
-Название курса
|
|
|
-
|
|
|
-Имя студента
|
|
|
-
|
|
|
-Имя преподавателя
|
|
|
-
|
|
|
-Название курса
|
|
|
-
|
|
|
-Так, те данные, которые имеются позволяют выделить три сущности: студент, преподаватель и курс. При этом мы вполне можем добавлять какие-то недостающие данные. Также следует отметить, что какие-то данные могут иметь отношение к разным сущностям. Например, курс хранит информацию о студенте, которые его посещает. А студент хранит информацию о посещаемом курсе. Подобная избыточность данных решается на последующих шагах проектирования в процессе нормализации базы данных.
|
|
|
-
|
|
|
-Но подобных атрибутов может оказаться очень много: сотни и даже тысячи. И в этом случае более оптимальным будет нисходящий подход. Данный подход подразумевает выявление сущностей. Затем происходит анализ сущностей, выявляются связи между ними, а потом и атрибуты сущностей.
|
|
|
-
|
|
|
-То есть в данном случае мы могли бы сразу определить, что нам надо хранить данные по студентам, курсам и преподавателям. Затем в рамках каждой сущности выявить атрибуты
|
|
|
-
|
|
|
-Например, у сущности "Студент" мы могли бы выделить такие атрибуты, как имя студента, его адрес, телефон, рост, вес, год его рождения. В тоже время нам надо учитывать не вообще все свойства, которые в принципе могут быть у сущности "Студент", а только те, которые имеют значение в рамках описываемой системы. Вряд ли в данном случае играют роль такие свойства как рост или вес студента, поэтому мы можем их вычеркнуть из списка атрибутов при проектировании таблицы.
|
|
|
-
|
|
|
-Иногда подходы комбинируются. Для описания разных частей системы могут использоваться разные подходы. А затем их результаты объединяются.
|
|
|
-
|
|
|
-Атомизация атрибутов
|
|
|
-При определении атрибутов происходит разделение сложных комплексных элементов на более простые. Так, в случае с именем студента мы можем его разбить на собственно имя и фамилию. Это позволит впоследствии выполнять операции с эти подэлементами отдельно, например, сортировать студентов только по фамилии.
|
|
|
-
|
|
|
-То же самое касается адреса - мы можем сохранить весь адрес целиком, а можем разбить его на части - дом, улицу, город и т.д.
|
|
|
-
|
|
|
-В то же время возможность разделения одного элемента на подэлементы не всегда может быть востребованной. В ряде задач это может быть просто не нужно. Выделять необходимо только те элементы, которые действительно нужны.
|
|
|
-
|
|
|
-В соответствии с этим аспектом мы можем выделить у сущности "Студент" следующие атрибуты: имя студента, фамилия студента, год рождения, город, улица, дом, телефон.
|
|
|
-
|
|
|
-Домен
|
|
|
-Каждый атрибут имеет домен (domain). Домен представляет набор допустимых значений для одного или нескольких атрибутов. По сути домен определяет смысл и источник значений, которые могут иметь атрибуты.
|
|
|
-
|
|
|
-Домены могут отличаться для разных атрибутов, но также несколько атрибутов могут иметь один домен.
|
|
|
-
|
|
|
-Например, выше были определены атрибуты сущности Студент. Определим используемые домены:
|
|
|
-
|
|
|
-Имя. Домен представляет все возможные имена, которые могут использоваться. Каждое имя представляет строку длиной максимум 20 символов (маловероятно, что нам могут встретиться имена свыше 20 символов).
|
|
|
-
|
|
|
-Фамилия. Домен представляет все возможные фамилии, которые могут использоваться. Каждая фамилия представляет строку длиной максимум 20 символов.
|
|
|
-
|
|
|
-Год рождения. Домен представляет все года рождения. Каждый год является числовым значением от 1950 до 2017.
|
|
|
-
|
|
|
-Город. Домен представляет все города текущей страны. Каждый город представляет строку длиной максимум 50 символов.
|
|
|
-
|
|
|
-Улица. Домен представляет все улицы текущей страны. Каждая улица представляет строку длиной максимум 50 символов.
|
|
|
-
|
|
|
-Дом. Домен представляет все возможные номера домов. Каждый номер дома является числом от 1 до, скажем, 10000.
|
|
|
-
|
|
|
-Телефон. Домен представляет все возможные телефонные номера. Каждый номер является строкой длиной в 11 символов.
|
|
|
-
|
|
|
-Определяя домен, мы сразу видим, какие данные и каких типов будут хранить атрибуты. Какое-то другое значение, которое не соответствует домену, атрибут иметь не может.
|
|
|
-
|
|
|
-В примере выше каждый атрибут имеет свой домен. Но, домены могут совпадать. Например, если бы сущность содержала бы следующие два атрибута: город рождения и город проживания, то домен бы совпадал и был бы одним и тем же для обоих атрибутов.
|
|
|
-
|
|
|
-Определитель NULL
|
|
|
-При определении атрибутов и их домена необходимо проанализировать, а может ли у атрибута отсутствовать значение. Определитель NULL позволяет задать отсутствие значения. Например, в примере выше у студента обязательно должно быть какое-либо имя, поэтому недопустима ситуация, когда у атрибута, который представляет имя, отсутствует значение.
|
|
|
-
|
|
|
-В то же время студент может не иметь телефонного номера или в рамках системы телефон не обязателен. Поэтому на этапе проектирования таблицы можно указать, что данный атрибут позволяет значение NULL.
|
|
|
-
|
|
|
-Как правило, большинство современных реляционных СУБД поддерживают определитель NULL и позволяют задать его допустимость для столбца таблицы.
|
