Обычная практика в проектировании баз данных? - PullRequest
Новая
       5

Обычная практика в проектировании баз данных?

0 голосов
/ 14 мая 2018

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

  1. Допустим, у одного человека может быть одно электронное письмоадрес , но кратный номер телефона , (т. е. отношение 1: 1 с email и отношение 1: n с телефон ).Должен ли я включить атрибут email в таблицу person и создать одну дополнительную таблицу для tel ?Будет ли следующая схема считаться «нечистой», поскольку в отдельной таблице хранятся только тел-нр? 

    ╔════════╗   ╔══════════╗  
║ person ║   ║ pers_tel ║
╠════════╣   ╠══════════╣
║ pid    ║   ║ pid      ║
║ ...    ║   ║ tel      ║ 
║ email  ║   ╚══════════╝ 
╚════════╝

  2. Если это так, мне нужно только объявить pid вpers_tel таблица (FK ссылается на person.pid) как PK или tel должна быть также PK?

Ответы [ 2 ]

0 голосов
/ 14 мая 2018

Ваш дизайн "чистый" - или, более формально, денормализованный.Единственные атрибуты объекта (например, адрес электронной почты) хранятся в виде столбцов;несколько атрибутов (например, номера телефонов) хранятся в связанных таблицах с использованием отношения один ко многим.Идентификатором этого отношения является первичный ключ.

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

Если есть другой дискриминатор (например, «тип телефона»), вы можете включить его как часть первичного ключа с PID, если бизнес-домен говорит «у человека может быть несколько телефонов, и каждый телефон имеетуникальный идентификатор типа (например, «домашний», «мобильный» и т. д.).

Объединение PID и TEL в один первичный ключ не является распространенным конструктивным решением - значение атрибута таблицы «персона»не подходит для первичного ключа.

0 голосов
/ 14 мая 2018

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

Таблица: person
ПК: PID

+-----+-----+------------------+
| PID | --- |      email       |
+-----+-----+------------------+
|  01 | --- | john@email.com   |
|  02 | --- | Bishoy@email.com |
|  03 | --- | Atul@email.com   |
+-----+-----+------------------+

Таблица: pers_tel
ПК: PID и Tel

+-----+-----+
| PID | Tel |
+-----+-----+
|  01 | 123 |
|  01 | 426 |
|  01 | 752 |
|  02 | 456 |
|  03 | 789 |
+-----+-----+

Database Relationship

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

Перед созданием таблицы, пожалуйста, взгляните на нормализацию базы данных. Особенно 1-й (1NF), 2-й (2NF) и 3-й (3NF) формы нормализации.

...