1

У меня есть три типа пользователей, которые будут храниться в базе данных.Дизайн базы данных: несколько унарных отношений на одном объекте

  • школы
  • консультация
  • студентов (физические лица)

Идея заключается в том, что студент может обратиться в школу непосредственно или обратиться через консультацию.

Все они имеют одинаковые атрибуты и, следовательно, хранятся в таблице пользователей . Концептуально каждый из этих типов пользователей имеет отношения с двумя другими типами пользователей. Отношения являются

  1. Consultancy и студент: 0..1 в 0..M
  2. школа и консультации: 1..m в 0..M
  3. школы и студент: 0..M к 0..M (1 студент может иметь 0 школу, поскольку они не связаны                                                                                                                  непосредственно в случае, если приложение отправлено через консультацию).

Мне нужна помощь в формировании этих отношений между одним и тем же объектом, то есть пользователем, желательно с демонстрационной диаграммой er.

+0

@philipxy: Конструкция мудрая, боюсь, я нахожусь в начальной точке. Я надеюсь, что вы действительно имели в виду документы. У меня есть прототип приложения и SRS. И я не мог не заметить цитаты вокруг «формирования отношений». Пожалуйста, дайте мне знать, если я должен использовать некоторые другие условия. Я всего лишь ученик-учитель, и поэтому помощь в каждой мелочи очень ценится. –

+0

Неясно, что означает «формирование этих отношений между одним и тем же объектом, то есть пользователем». Возможно, путем «формирования» вы просто подразумеваете проектирование. Я полагаю, вы имеете в виду решение о столбцах, ключах-кандидатах, внешних ключах и т. Д., Но, пожалуйста, просто скажите, что вы пытаетесь доставить. Пожалуйста, приложите все усилия к результатам. Также есть много методов моделирования и диаграмм, и какие из них вы используете? PS Ваш вопрос по существу просят главы дизайна/диаграммы учебника. Это слишком широкий вопрос. Найдите учебник в качестве справочника. (Многие из них в сети.) – philipxy

ответ

0

Таблица представляет собой связь приложения между значениями и/или объектами, идентифицированными ими. «Отношения» путается/запутанно также используется для обозначения «внешнего ключа».

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

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

Student(p) -- P identifies a student 
School(s) -- S identifies a school 
... 
User(u, ...) -- U identifies a user and ... 
... 
Representation(c, p, ...) -- consultancy C represents student P and ... 
Application(p, s, ...) -- student P has applied to school S and ... 

таблица имеет строки, которые делают предикат в своем комментарии в истинное утверждение. Вам необходимы достаточные сущности & и соответствующие таблицы, чтобы полностью описать любую ситуацию, которая может возникнуть.

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

Вы должны выбрать конкретную ссылку и следовать ей.

Смежные вопросы