Модель базы данных, отражающая реальную систему, требует времени и усилий, строить и дорабатывать. Вам нужно принять решение о таблицах, которые вам нужно создать, какие поля они будут содержать и как таблицы могут быть связаны друг с другом.
Хорошая база данных, разработанная в соответствии с реляционной моделью, дает много преимуществ. Хороший дизайн делает ввод, обновление и удаление данных эффективными, а также упрощает поиск и обобщение данных. Поскольку большая часть данных хранится в базе данных, а не в приложении, база данных должна быть достаточно самодокументируемой.
Хороший дизайн базы данных должен также учитывать будущие изменения в реальных требованиях и должен быть гибким, чтобы допускать изменения в схеме базы данных.
Таблицы и ключи
Таблица — это базовая сущность реляционной модели. Каждая таблица должна представлять сущность в реальном мире, и эти сущности могут быть реальными объектами или событиями. Например, покупатель — это объект реального мира, а заказ, сделанный покупателем, — это событие.
Таблица состоит из строк и столбцов. Реляционная модель требует, чтобы каждая строка в таблице была уникальной, чтобы к ней можно было однозначно обращаться с помощью программирования. Уникальность строки гарантируется определением первичного ключа для таблицы. Первичный ключ таблицы состоит из одного или нескольких полей, которые однозначно идентифицируют строку. Каждая таблица может иметь только один первичный ключ. Все поля, из которых извлекается первичный ключ, называются ключами-кандидатами. Из других полей таблицы можно извлечь несколько вторичных ключей.
Вторичные ключи могут быть уникальными или неуникальными. Вторичные ключи обычно используются для определения вторичных индексов для таблицы, чтобы ускорить поиск данных. Ключи могут быть простыми или составными. Если ключ состоит из одного поля, он называется простым ключом; если ключ состоит из двух или более полей, он называется составным ключом.
При моделировании таблицы вы должны решить, какие ключи-кандидаты образуют первичный ключ таблицы, исходя из бизнес-требований; нет жестких и быстрых правил для определения первичного ключа таблицы. В своей книге под названием SQL and Relational Basics Фабиан Паскаль отмечает, что такое решение должно быть основано на принципах минимализма (выберите наименьшее количество необходимых полей), стабильности (выберите ключ
который редко меняется) и простота/привычность (выберите ключ, который одновременно прост и знаком пользователям).
Например, если у вас есть таблица для хранения сведений о сотрудниках, таких как идентификатор сотрудника, имя, фамилия, адрес, номер телефона и почтовый индекс, какие из этих полей подойдут для хорошего первичного ключа? Следуя указаниям Паскаля, адрес и номер телефона можно исключить, поскольку они часто меняются. Также есть вероятность смены фамилии работника в связи с женитьбой или другими причинами; кроме того, имена могут быть написаны с ошибками, и существует высокая вероятность того, что у двух сотрудников будут одинаковые имена или фамилии.
Поскольку идентификатор сотрудника уникален для всей организации, он лучше всего подходит для использования в качестве первичного ключа. Несмотря на отсутствие фиксированных правил выбора первичного ключа, большинство разработчиков предпочитают использовать числовой первичный ключ, поскольку поиск по числовым полям более эффективен, чем поиск по текстовым полям.
Во многих случаях рекомендуется использовать статические числа, такие как идентификатор сотрудника, идентификатор клиента, номер документа и т. д., в качестве первичных ключей и избегать текстовых описаний.
Внешние ключи и домены
Несмотря на то, что первичные ключи определены в отдельных таблицах, может возникнуть необходимость определить отношения с различными таблицами базы данных с использованием отношений внешних ключей. Внешний ключ — это поле в таблице, которое используется для ссылки на первичный ключ в другой таблице. Давайте посмотрим на пример. Таблица клиентов, в которой хранятся сведения о клиентах. Первичным ключом этой таблицы является столбец Cust ID, который однозначно идентифицирует каждую строку.| Cust ID | Name | Address | ZIP | Phone |
|---|---|---|---|---|
| 1 | Joey | 171 CE | 110099 | 99889900 |
| 2 | James | 345 DE | 118899 | 88997788 |
| 3 | John | 563 WE | 442299 | 88993354 |
| Order ID | Cust ID | Item | Qty | UoM |
|---|---|---|---|---|
| 2230 | 1 | Pen | 10 | Pieces |
| 2231 | 2 | Pencil | 10 | Pieces |
В этом примере поле идентификатора клиента(Таблица заказов - Cust ID) считается внешним ключом таблицы, поскольку его можно использовать для ссылки на таблицу клиентов ( Таблица клиентов - Cust ID ).
Важно, чтобы и первичные, и внешние ключи, используемые для формирования связи, имели одно и то же значение и домен. Домен определяет возможный набор значений для поля.
Например, если допустимым значением идентификатора клиента может быть число от 1 до 10 000, то поля идентификатора клиента в обеих таблицах должны соответствовать этому диапазону. Внедрив проверку внешнего ключа, мы также можем гарантировать, что поле Cust ID в таблице заказов состоит только из значений, доступных в поле Cust ID таблицы клиентов.
Отношение
Внешние ключи моделируют отношения между реальными сущностями. Такие объекты реального мира могут иметь сложные отношения — например, один объект может иметь несколько отношений с другими объектами. В реляционной базе данных отношения определяются между парой таблиц. Эти таблицы могут быть связаны одним из трех способов:
Отношения один к одному (One-to-one relationship)
Две таблицы называются взаимно однозначными, если на каждую строку первой таблицы приходится не более одной строки второй таблицы. Отношения один к одному редко используются для моделирования объектов реального мира; они в основном используются для разделения данных на несколько таблиц из-за ограничений программного обеспечения.
Например, вы можете разделить данные на две таблицы, если количество полей превышает ограничение в 249 на таблицу, или вы можете смоделировать две таблицы с данными о клиентах, если одна из таблиц может хранить более конфиденциальную информацию о клиенте. У вас есть лучший доступ к управлению ограничениями для этой таблицы по сравнению с таблицей, в которой хранится общая информация о клиенте. Таблицы в отношении «один к одному» должны иметь одинаковые первичные ключи.
Отношения один ко многим (One-to-many relationship)
Говорят, что две таблицы находятся в отношениях «один ко многим», если для каждой строки в первой таблице может быть ноль, одна или несколько строк во второй таблице, но для каждой строки во второй таблице имеется ровно одна строка. в первой таблице.
Наиболее часто моделируются отношения «один ко многим». Таблицы в отношении «один ко многим» также называются родительско-дочерними таблицами или таблицами заголовков и элементов. Общие таблицы с отношениями «один ко многим» в системе SAP включают таблицы заказов, такие как VBAK-VBAP, в которых хранятся сведения о заголовках и позициях заказов на продажу, и EKKO-EKPO, в которых хранятся сведения о заголовках и позициях заказов на покупку.
Отношение «один ко многим» также используется для связи базовой таблицы с таблицей поиска. Например, в таблице заказов вы можете сохранить двухсимвольное сокращение для единицы измерения, и эта информация может быть связана с таблицей поиска, в которой хранятся описания сокращений.
Отношения многие ко многим (Many-to-many relationship)
Говорят, что две таблицы находятся в отношениях «многие ко многим», когда для каждой строки в первой таблице может быть много строк во второй таблице, а для каждой строки во второй таблице может быть много строк в первой таблице. Отношения «многие ко многим» не могут быть напрямую смоделированы в реляционной базе данных, и они обычно разбиваются на несколько отношений «один ко многим».
Перевод книги #Complete ABAP / Kiran Bandari
Комментарии
Отправить комментарий