Связь сущностей — проектирование БД

Я пытаюсь придумать лучший дизайн для тренеров и базы данных клиентов.

Моя первоначальная мысль была такой:

  1. Сущность person с общими атрибутами клиентов и тренеров (имя, доб и т.д.). У клиента может быть только один тренер. У одного тренера может быть много клиентов.

  2. Интересно, создавать ли объект user для управления привилегиями клиентов и тренеров или просто добавить атрибут Role в person

Еще одна вещь, которую я рассматривал, заключалась в том, чтобы иметь все в едином объекте с рекурсивными отношениями?

Любое предложение?

Спасибо.


database entity specialization
person Paragon    schedule 03.06.2012    source источник
comment
Спасибо всем за ваши комментарии, вот что я придумал: User(UserID, Name, Dob, Username, Password, здесь тоже будет адрес...) UserRole(UserId, RoleId) Role(RoleId, Role) RolePermission( RoleId, PermissionId) Permission(PermissionId, Permission) Client(ClientId, UserId, NextOfKin, ...) Trainer(TrainerId, UserId, Level, ...) ClientTrainer(ClientId, TrainerId) Прежде чем я продолжу, я хотел бы услышать ваше мнение. Спасибо.   -  person Paragon    schedule 03.06.2012

Ответы (2)


arrow_upward
0
arrow_downward

Тренеры и клиенты с точки зрения сущности, вероятно, имеют разные данные, которые вы хотите отслеживать о каждом из них. У вас все еще может быть глобальная таблица пользователей, но тренер и клиент должны иметь отношения 1:1 с сущностью пользователя. Затем у вас может быть объединенная таблица между клиентами и тренерами. Я бы предложил здесь отношения многие ко многим, на тот случай, если кто-то действительно хочет прийти в форму и хочет иметь 2 тренера.

person Nick    schedule 03.06.2012
comment
Будет ли это отображать глобальную таблицу, скажем, «пользователь», и вторую таблицу с атрибутами клиентов и тренеров и их ролью? Спасибо. - person Paragon; 03.06.2012
comment
Это зависит от того, насколько конкретно вы хотите быть. Если данные, которые вы хотите отслеживать, сильно отличаются от основных пользовательских данных, я бы рекомендовал две разные таблицы. Даже если кто-то является и тренером, и клиентом, у вас все равно нет избыточности, поскольку объект тренера должен иметь данные, специфичные для тренера, тогда как клиент — это данные, специфичные для клиента, а любые глобальные данные представлены в вашей пользовательской таблице. - person Nick; 04.06.2012
comment
Спасибо, Ник. Я выбрал две разные таблицы, позволяющие при необходимости добавлять более конкретные данные в будущем. И я буду использовать таблицу соединения между клиентом и тренером, чтобы сохранить дату, когда клиент начал тренироваться с новым тренером. - person Paragon; 04.06.2012

arrow_upward
0
arrow_downward

Могут ли тренеры иметь тренеров? Например, тренер, который специализируется на триатлонах, может быть слабым пловцом и иметь тренера по плаванию.

Мне самому нравится дизайн Role.

person duffymo    schedule 03.06.2012
comment
Да, у тренеров может быть тренер, которым может быть он сам или кто-то другой, что позволяет тренеру создавать программу упражнений для себя или для других тренеров. Спасибо за ваш вклад. - person Paragon; 03.06.2012
comment
Тогда вам определенно нужен дизайн «человек-роль», который представляет собой иерархию. - person duffymo; 03.06.2012