Логическое проектирование баз данных

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

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

Этап логического проектирования иногда делят на концептуальную и логическую часть, но это отличие чисто номинально. Концептуальное проектирование базы данных (conceptual database design) обычно предшествует этапу логического проектирования и подразумевает моделирование информации без использования какой-либо базовой модели данных. Что касается этапа логического проектирования, то он уже предполагает явное применение конкретной модели данных, например, реляционной, и фокусирование внимания на логических отношениях, которые были определены на этапе концептуального проектирования. В частности, логическое проектирование заключается в концептуальном моделировании базы данных и гарантии того, что данные в таблицах проходят проверку на целостность и не являются избыточными. Для удовлетворения этих требований реализуются принципы нормализации данных, о которых будет более подробно рассказываться чуть позже.

Методика, которую чаще всего применяют для логического представления и анализа компонентов бизнес-системы и моделирования подходящего решения после завершения анализа требований, называется ER-моделированием (Entity Relationship Modeling — создание моделей типа “сущность-отношение”). ER-модели легко конструировать, а, благодаря акценту на графическом представлении, еще и очень легко понимать. Тем не менее, создавать настоящую РСУБД на основании одной только ER-модели предприятия нельзя. Польза ER-моделирования заключается в проектировании, а не в реализации баз данных. Образовывать основу для высокоуровневого языка манипулирования данными вроде SQL ER-моделирование не позволяет, поэтому та модель, которую проектировщики создают с помощью ER-моделирования, для реализации преобразуется в реляционную модель. То есть за счет преобразования абстрактной структуры с сущностями и отношениями в схему реляционной базы данных реляционная модель помогает преобразовывать ER-модель в реляционную СУБД.

ER-моделирование в логическом моделировании базы

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

ER-моделирование впервые было предложено Питером Ченом (Peter Chen) в 1976 г. и теперь является очень часто применяемой методикой для проектирования баз данных. (Загрузить копию исходного документа Чена в виде PDF-файла можно по адресу http://citeseer.ist.psu.edu/519283.html.) Несмотря на это, помимо ER-моделирования для использования доступно еще несколько методик проектирования. В частности, в течение вот уже нескольких лет исследователи пытаются моделировать настоящий мир более реалистично с применением так называемых семантических моделей данных (semantic data models), которые, по идее, должны позволять даже выходить за рамки возможностей традиционного ER-моделирования.


Важно! Члены консорциума W3C (World Wide Web Consortium) сейчас занимаются разработкой совместного проекта под названием Semantic Web, который представляет собой общий каркас для совместного и повторного использования данных за пределами приложений и общественных границ. В его основе лежит каркас RDF (Resource Description Framework — каркас описания ресурсов), который позволяет использовать общие форматы для интеграции данных, извлекаемых из разных источников. Кроме того, Semantic Web представляет собой унифицированный язык, помогающий фиксировать то, каким образом данные соотносятся с реальными объектами. В общем, идея состоит в том, чтобы попробовать привнести хоть какое-то значение в огромное количество доступных данных и информации. Информация, выкладываемая в Интернете, рассчитана на людей и потому представляется в соответствующем формате, но в Semantic Web данные будут форматироваться таким образом, чтобы их могли понимать не только люди, но и компьютеры. В Semantic Web для выполнения поиска данных и информации нужно будет пользоваться программными агентами. Узнать больше о проекте Semantic Web можно по адресу http://www.w3.org/2001/sw/. Еще есть одна замечательная посвященная этому проекту статья Тима Бернерса-Ли (Tim Berners-Lee), Джеймса Хендлера (James Hendler) и Ора Лассила (Ora Lassila), которая называется “The Semantic Web” и доступна по адресу http://www.scientificamerican.com/article.cfm?articleID=00048144-10D2-1C70-84A9809EC588EF21&catID=2.


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

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

Атрибутами сущностей называются свойства сущностей, которые представляют интерес. Например, у сущности, представляющей студента, атрибутами могут быть идентификационный номер студента (Student ID), его адрес (Address), номер телефона (Phone Number) и т.п.

Далее в ER-моделировании описываются отношения (relationships) между всеми бизнес-сущностями. Эти отношения отображают то, каким образом различные сущности связаны (или соотносятся) между собой. Например, сотрудник может представлять собой сущность, обладающую атрибутами вроде имени (Name) и адреса (Address), и быть связанным в модели с другой сущностью под названием “Отдел” (Department) на основании того факта, что он работает в этом отделе. В данном случае глагол “работает” как раз и описывает отношение между сотрудником и отделом.

Типы отношений

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

Мощность (cardinality), или количество элементов, отношения показывает, сколько экземпляров одной сущности может соотноситься с экземпляром другой сущности. Тот факт, что бинарное отношение отражает взаимоотношения между двумя сущностями, вовсе не означает, что между ними всегда существует отношение типа “один к одному”.

Отношения между сущностями могут представлять собой и отношения типа “один к од- ному”, и “один ко многим”, и “многие ко многим” или отношения еще какого-то другого типа. Чаще всего встречаются отношения следующих типов (при условии наличия двух сущностей, A и B).

  • Один ко многим. В таких отношениях каждый экземпляр сущности A может иметь отношение с несколькими членами другой сущности B. Например, сущность под названием Клиент может брать много книг из библиотеки, но каждая книга за раз может выдаваться только одному единственному Клиенту. Соответственно получается, что между сущностями Клиент и Книга должно существовать отношение типа “один ко многим”. Разумеется, такое отношение может и не существовать при наличии Клиента, который еще не брал никакой Книги. То есть фактически отношение должно гласить следующее: “один Клиент может брать ноль, одну или более Книг”.
  • Один к одному. В таких отношениях только один экземпляр любой из сущностей может иметь отношение с экземпляром другой сущности. Например, у каждого человека может быть только один действительный номер карточки социального страхования (Social Security Number — SSN), а каждый номер карточки социального страхования может ссылаться только на одного человека.
  • Многие ко многим. В таких отношениях каждый экземпляр сущности A может иметь отношение с одним и более экземплярами сущности B, а каждый экземпляр сущности B - с одним и более экземплярами сущности A. В качестве примера возьмем сущность под названием Кинозвезда и сущность под названием Кинофильм. Каждая кинозвезда может сниматься в нескольких Кинофильмах, и в каждом Кинофильме может принимать участие несколько Кинозвезд. В реальной жизни отношения типа “многие ко многим” обычно разбиваются на более простые отношения типа “один ко многим”, которые, как сложилось, являются наиболее распространенной формой отношений между сущностями.

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

Потенциальные ключи и уникальные идентификаторы

Потенциальными ключами (candidate keys) являются атрибуты, которые способны уникальным образом идентифицировать строку в таблице, и в каждой таблице таких ключей может быть несколько. Например, достаточно часто в таблице сотрудников присутствует как генерируемый уникальный порядковый номер, так и еще какой-то идентификатор, вроде номера сотрудника (или номера его карточки социального страхования). (Разумеется, любая целая строка сама тоже может служить потенциальным ключом, поскольку в реляционной модели по определению не может существовать никаких дублированных кортежей. Однако целая строка редко применяется в качестве ключа, потому что сам смысл ключа состоит в обеспечении легкого доступа к строке.)

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

Ключи начинают играть очень важную роль, когда дело доходит до физического построения ER-моделей. Первичный ключ, состоящий из элементов данных или атрибутов сущностей, называется естественным (natural). Практически во всех современных реляционных базах данных, в том числе и базах данных Oracle, в качестве альтернативы естественному первичному ключу также предлагаются простые системные или порядковые номера, генерируемые и обслуживаемые РСУБД (наподобие порядкового номера для идентификации заказов). Такие ключи часто называются суррогатными (surrogate) или искусственными (artificial) первичными ключами.

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

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

Вас заинтересует / Intresting for you:

Перенос корпоративных баз данн...
Перенос корпоративных баз данн... 1256 просмотров Дэн Fri, 27 Sep 2019, 07:52:18
База данных как объект правово...
База данных как объект правово... 751 просмотров Денис Wed, 27 Mar 2019, 03:16:24
Оптимизация структур баз данны...
Оптимизация структур баз данны... 941 просмотров Ирина Светлова Sun, 24 Mar 2019, 06:25:41
База данных и СУБД: основные п...
База данных и СУБД: основные п... 10096 просмотров Дэйзи ак-Макарова Fri, 24 Nov 2017, 05:30:03
Войдите чтобы комментировать

1dz аватар
1dz ответил в теме #8330 25 март 2017 15:47

apv пишет: Согласен. Проектирование баз данных и наука, и исскуство. Хорошо спроектированная Бд даст большую фору программистам и пользователям в последствии.

Золотые слова!
apv аватар
apv ответил в теме #8306 22 март 2017 07:23
Согласен. Проектирование баз данных и наука, и исскуство. Хорошо спроектированная Бд даст большую фору программистам и пользователям в последствии.