#sql #sql-server #foreign-keys #relationship #database-diagram
#sql #sql-сервер #внешние ключи #отношение #база данных-диаграмма
Вопрос:
Привет, укладчики!
Я создал базу данных библиотеки, мне было интересно.. я устанавливаю взаимно однозначное отношение между копиями и заимствованиями. и отношение «один ко многим» от пользователей к займам.
Поскольку копии книги должно быть разрешено назначать только один кредит за раз, а кредит должен содержать только одну копию книги. если они арендуют другие книги, это несколько кредитов.
и пользователь должен иметь возможность делать несколько кредитов, но кредит может быть назначен только одному конкретному пользователю.
верны ли мои текущие отношения между этими тремя таблицами? если нет, я хотел бы знать, как это исправить, и причину моей неудачной логики по этому вопросу.
заранее благодарю вас!
Комментарии:
1. для меня это выглядит хорошо, однако для проверки вашей логики вам может понадобиться условный уникальный индекс в таблице Loans
2. Это неправильно — и вы на самом деле ничего не изменили по сравнению с вашим предыдущим вопросом в отношении отношений. Но у вас должны быть некоторые базовые варианты использования для оценки вашего дизайна. Одним из них должно быть что-то вроде: пользователь x проверяет книгу y и возвращает ее. Пользователь Y проверяет эту же книгу на следующий день после ее возврата. Поддерживает ли ваш дизайн это? Примените тот же процесс для создания ваших вариантов использования и проверки всех других отношений.
3. И я использую термин «неправильный», потому что это одна из основных целей библиотеки — предоставлять одну и ту же книгу снова, снова и снова. С течением времени для работы этой системы необходимо учитывать множество других факторов. Книги теряются, распродаются, изымаются из обращения и т. Д. Кредит не возвращается вовремя. Кредит продлевается. И книги — это не единственные вещи, которые предоставляют библиотеки. Некоторые вещи они вообще не предоставляют — например, периодические издания. Это очевидные сложности базового дизайна, но никто не знает, какова ваша конечная цель.
Ответ №1:
Следуя предыдущему ответу. Если вы добавите таблицу User_Roles, это может / (будет) препятствовать попаданию в ловушку членства. Если вы предполагаете, что пользователь с ролью администратора может выполнять все функции пользователя только с базовой ролью, то каждая функция, требующая проверки ролей, должна иметь список допустимых ролей (Admin Basic). Во многих случаях более эффективно просто напрямую назначать все разные роли, то есть Базовые И административные, отдельным пользователям. Затем, когда функция требует базовой авторизации роли, все пользователи могут обрабатываться одинаково. В долгосрочной перспективе это проще.
Таблица Loans имеет ряд проблем. Во-первых, нет первичного ключа, чтобы соответствовать остальной части вашего дизайна, это может быть LoanID . CopyID должен быть внешним ключом к таблице копий (возможно, это то, что в данный момент нарисовано).
Одним из «продвинутых» или современных подходов к вашей модели данных может быть использование временной таблицы для моделирования копий. Поскольку одна копия может быть предоставлена только 1 раз, свойства loan могут быть добавлены в таблицу Copies. Тогда при каждом внесении изменений в таблицу копий версии системы таблица Copies_history автоматически сохраняла бы полный учет всей предыдущей кредитной активности.
Ответ №2:
Модель выглядит хорошо для меня. Возможно, вам потребуется применить некоторые из них в логике, чтобы заставить пользователя иметь только один кредит с той же копией книги.
Пользователь сможет одалживать копию снова и снова? затем отношение к loan для копирования 1: M
Комментарии:
1. Хорошо.. он сможет одолжить его .. но если он захочет повторно одолжить его, ему придется сделать это после изменения статуса с loaned на not loaned .. я имею в виду, тогда он должен одолжить его еще раз .. но это делает его другим кредитом, я полагаю? кроме того, благодаря этому я смогу отслеживать, сколько кредитов он сделал, даже если это относится к той же копии книги?