Тип связи между сущностями

@kirill88 · Регистрация: 22.12.2014

Студворк — интернет-сервис помощи студентам

Здравствуйте! начинаю осваивать БД, помогите разобраться на примере базы данных банка. Данные о клиенте включают его имя, адрес, номер телефона и идентификационный номер налогоплательщика (ИНН). Счет описывается атрибутами номера, типа (например, «накопительный», «чековый» и т.п.) и остатка.

У меня возникли такие вопросы:
1) может ли ИНН быть первичным ключом или лучше добавить атрибут ID_клиента?
2) счет может принадлежать только одному клиенту-это идентифицируемая связь один-ко-многим? То есть счет только одному клиенту, но у клиента может быть несколько счетов? правильно я понимаю?

@pincet · 30.03.2016, 11:41

Сообщение от kirill88

может ли ИНН быть первичным ключом или лучше добавить атрибут ID_клиента?

если в вашей предметной области номер налогоплательщика уникальный - да. ID_клиента ключ суррогатный

Сообщение от kirill88

счет может принадлежать только одному клиенту

А как еще-то? Да, 1:n. Только хранить остаток-недостаточно - нужно хранить движения по счету, а остаток вычислять (но можно и хранить - ситуации разные бывают)

@kirill88 · 30.03.2016, 13:57 **[ТС]**

Понял, спасибо) далее нужно вот что (правильно ли я рассуждаю?):

3) клиент может иметь несколько адресов, описываемых записями вида «улица—город—страна», и множество номеров телефонов. Значит нужно создать еще таблицу с атрибутами улица, город, страна (связь один-ко-многим) и таблицу номеров телефонов?
4) клиент может иметь несколько адресов, а за каждым адресом закреплено множество номеров телефонов. Здесь нужна связь таблиц адреса и номера телефона много-ко-многим?

@pincet · 30.03.2016, 14:17

Клиент-Адрес 1:n. Как реализовывать сущность Адрес - дело хозяйское, смотря как использовать мечтается (хоть 3 таблицы, хоть одна иерархическая, хот еще как)
Номер телефона - уникален (если взглянуть в worldwide смысле) - иначе на"ер он нужон такой. В подавляющем большинстве случаев - просто текстовое поле (повесить уникальный индекс не помешает). Однако, сегодня у человека один номер, завтра - другой (а первый уже у третьего лица). То же касается и стационарных (привязанных к адресу). Это нужно учесть

@kirill88 · 30.03.2016, 14:24 **[ТС]**

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

@Grossmeister · 30.03.2016, 14:42

Сообщение от kirill88

про адреса все понял, а вот с телефонами непонятки

По моему ты слишком глубоко копаешь. В реале обычно используются 2 адреса: адрес регистрации (это обычно для налоговой) и почтовый (это для связи). Телефонов тоже парочка, поскольку если у него будет 10, то все равно все их обзванивать никто не будет. Ну и email нонче для связи тоже используется.
По поводу ИНН. Его можно использовать в качестве PK, но он все таки 12-разрядный, поэтому id обычно короче.

@kirill88 · 30.03.2016, 14:44 **[ТС]**

это не я придумал, а задание такое про много адресов и номеров, вот и лоиаю голову как это реализовать... с телефонами вообще беда

@pincet · 30.03.2016, 14:58

Сообщение от kirill88

с телефонами вообще беда

как говорится - "когда поймешь умом" (с)

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

@Grossmeister · 30.03.2016, 15:03

Сообщение от kirill88

про много адресов и номеров

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

@Пытливый · 31.03.2016, 10:41

Есть довольно удачная реализация схемы подобных отношений:
Объект(КодОбъекта, ТипОбъекта) - таблица которая выдает уникальные номера в рамках базы, для всех Объектов (Лицо,Адрес,Телефон и т.д.).
Есть таблицы для конкретных объектов например Лицо(КодОбъекта, ФИО), Телефон(КодОбъекта,Номер) и т.д.
И наконец есть таблица связей между объектами - Связь(КодОбъекта1,КодОбъекта2,ТипСвязи)
Допустим есть: Иванов И.И. живущий в Питере у него есть в квартире телефон 8122445644 и есть сотовый 9187555544
В базе будет:
Объект(1, Лицо),Объект(2, Адрес),Объект(3, Телефон),Объект(4, Телефон)
Лицо(1,Иванов И.И),Адрес(2,Питер),Телефон(3,8122445644 ),Телефон(4,9187555544)
Связь(1,2,Проживает),Связь(2,3,Установле н),Связь(1,4,Владеет)

Все.

@pincet · 31.03.2016, 10:46

Сообщение от Пытливый

Есть таблицы для конкретных объектов например Лицо(КодОбъекта, ФИО), Телефон(КодОбъекта,Номер) и т.д.

самое узкое и одновременно толстое место. Может в плане универсальности оно и гуд - но универсальность всегда толсто выходит

@kirill88 · 31.03.2016, 10:48 **[ТС]**

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

Добавлено через 1 минуту
еще возник вопрос: если сказано что клинент может иметь только один счет, это означает либо не имеет вообще либо ровно один?

@Grossmeister · 31.03.2016, 10:57

Сообщение от kirill88

это означает либо не имеет вообще либо ровно один

Если клиент не имеет ни одного счета, он не является клиентом банка

@Пытливый · 31.03.2016, 11:28

Это реальная схема из базы которая ведется в подобном виде уже более 15 лет по всей России. Объемы записей в ней исчисляются десятками миллионов, а количество отношений между объектами я даже не представляю какое. За это время добавлялись только новые виды объектов, но схема отношений между ними осталась неизменной, что говорит о многом.

Новые блоги и статьи Все статьи Все блоги /
SDL3 для Web (WebAssembly): Реализация движения на Box2D v3 - трение и коллизии с повёрнутыми стенами 8Observer8 20.02.2026 Содержание блога Box2D позволяет легко создать главного героя, который не проходит сквозь стены и перемещается с заданным трением о препятствия, которые можно располагать под углом, как верхнее. . .	Конвертировать закладки radiotray-ng в m3u-плейлист damix 19.02.2026 Это можно сделать скриптом для PowerShell. Использование . \СonvertRadiotrayToM3U. ps1 <path_to_bookmarks. json> Рядом с файлом bookmarks. json появится файл bookmarks. m3u с результатом. # Check if. . .	Семь CDC на одном интерфейсе: 5 U[S]ARTов, 1 CAN и 1 SSI Eddy_Em 18.02.2026 Постепенно допиливаю свою "многоинтерфейсную плату". Выглядит вот так: https:/ / www. cyberforum. ru/ blog_attachment. php?attachmentid=11617&stc=1&d=1771445347 Основана на STM32F303RBT6. На борту пять. . .	Камера Toupcam IUA500KMA Eddy_Em 12.02.2026 Т. к. у всяких "хикроботов" слишком уж мелкий пиксель, для подсмотра в ESPriF они вообще плохо годятся: уже 14 величину можно рассмотреть еле-еле лишь на экспозициях под 3 секунды (а то и больше),. . .
И ясному Солнцу zbw 12.02.2026 И ясному Солнцу, и светлой Луне. В мире покоя нет и люди не могут жить в тишине. А жить им немного лет.	«Знание-Сила» zbw 12.02.2026 «Знание-Сила» «Время-Деньги» «Деньги -Пуля»	SDL3 для Web (WebAssembly): Подключение Box2D v3, физика и отрисовка коллайдеров 8Observer8 12.02.2026 Содержание блога Box2D - это библиотека для 2D физики для анимаций и игр. С её помощью можно определять были ли коллизии между конкретными объектами и вызывать обработчики событий столкновения. . . .	SDL3 для Web (WebAssembly): Загрузка PNG с прозрачным фоном с помощью SDL_LoadPNG (без SDL3_image) 8Observer8 11.02.2026 Содержание блога Библиотека SDL3 содержит встроенные инструменты для базовой работы с изображениями - без использования библиотеки SDL3_image. Пошагово создадим проект для загрузки изображения. . .

@kirill88 0 / 0 / 1 Регистрация: 22.12.2014 Сообщений: 210

	Тип связи между сущностями 30.03.2016, 10:56. Показов 2410. Ответов 13 Метки нет (Все метки) Здравствуйте! начинаю осваивать БД, помогите разобраться на примере базы данных банка. Данные о клиенте включают его имя, адрес, номер телефона и идентификационный номер налогоплательщика (ИНН). Счет описывается атрибутами номера, типа (например, «накопительный», «чековый» и т.п.) и остатка. У меня возникли такие вопросы: 1) может ли ИНН быть первичным ключом или лучше добавить атрибут ID_клиента? 2) счет может принадлежать только одному клиенту-это идентифицируемая связь один-ко-многим? То есть счет только одному клиенту, но у клиента может быть несколько счетов? правильно я понимаю? Миниатюры 0

@kirill88 0 / 0 / 1 Регистрация: 22.12.2014 Сообщений: 210
	30.03.2016, 13:57 [ТС]
	Понял, спасибо) далее нужно вот что (правильно ли я рассуждаю?): 3) клиент может иметь несколько адресов, описываемых записями вида «улица—город—страна», и множество номеров телефонов. Значит нужно создать еще таблицу с атрибутами улица, город, страна (связь один-ко-многим) и таблицу номеров телефонов? 4) клиент может иметь несколько адресов, а за каждым адресом закреплено множество номеров телефонов. Здесь нужна связь таблиц адреса и номера телефона много-ко-многим? 0

@pincet 1654 / 1153 / 173 Регистрация: 23.07.2010 Сообщений: 6,910
	30.03.2016, 14:17
	Клиент-Адрес 1:n. Как реализовывать сущность Адрес - дело хозяйское, смотря как использовать мечтается (хоть 3 таблицы, хоть одна иерархическая, хот еще как) Номер телефона - уникален (если взглянуть в worldwide смысле) - иначе на"ер он нужон такой. В подавляющем большинстве случаев - просто текстовое поле (повесить уникальный индекс не помешает). Однако, сегодня у человека один номер, завтра - другой (а первый уже у третьего лица). То же касается и стационарных (привязанных к адресу). Это нужно учесть 0

@kirill88 0 / 0 / 1 Регистрация: 22.12.2014 Сообщений: 210
	30.03.2016, 14:24 [ТС]
	про адреса все понял, а вот с телефонами непонятки.... как же лучше сделать? если делать отдельной таблицей, то какие атрибуты выбрать? непосредственно номер и тип (моб или стац)? 0

@kirill88 0 / 0 / 1 Регистрация: 22.12.2014 Сообщений: 210
	30.03.2016, 14:44 [ТС]
	это не я придумал, а задание такое про много адресов и номеров, вот и лоиаю голову как это реализовать... с телефонами вообще беда 0

@Пытливый 3763 / 2267 / 705 Регистрация: 29.05.2013 Сообщений: 9,622
	31.03.2016, 10:41
	Есть довольно удачная реализация схемы подобных отношений: Объект(КодОбъекта, ТипОбъекта) - таблица которая выдает уникальные номера в рамках базы, для всех Объектов (Лицо,Адрес,Телефон и т.д.). Есть таблицы для конкретных объектов например Лицо(КодОбъекта, ФИО), Телефон(КодОбъекта,Номер) и т.д. И наконец есть таблица связей между объектами - Связь(КодОбъекта1,КодОбъекта2,ТипСвязи) Допустим есть: Иванов И.И. живущий в Питере у него есть в квартире телефон 8122445644 и есть сотовый 9187555544 В базе будет: Объект(1, Лицо),Объект(2, Адрес),Объект(3, Телефон),Объект(4, Телефон) Лицо(1,Иванов И.И),Адрес(2,Питер),Телефон(3,8122445644 ),Телефон(4,9187555544) Связь(1,2,Проживает),Связь(2,3,Установле н),Связь(1,4,Владеет) Все. 0

@kirill88 0 / 0 / 1 Регистрация: 22.12.2014 Сообщений: 210
	31.03.2016, 10:48 [ТС]
	Да, то есть получаем отдельные таблицы. Просто в моем задании нужно постепенно изменять диаграмму....сначала есть только клиент и счет со своими атрибутами, затем добавляется адрес и т.д. и каждый шаг необходимо сохранять. то что вы описали будет скорее окончательным вариантом, спасибо за подробное описание! Добавлено через 1 минуту еще возник вопрос: если сказано что клинент может иметь только один счет, это означает либо не имеет вообще либо ровно один? 0

@Пытливый 3763 / 2267 / 705 Регистрация: 29.05.2013 Сообщений: 9,622
	31.03.2016, 11:28
	Это реальная схема из базы которая ведется в подобном виде уже более 15 лет по всей России. Объемы записей в ней исчисляются десятками миллионов, а количество отношений между объектами я даже не представляю какое. За это время добавлялись только новые виды объектов, но схема отношений между ними осталась неизменной, что говорит о многом. 1