Базы данных

Определение ключа класса


Для того чтобы уникальным образом определить состоявшуюся в прошлом операцию проката, следует добавить к ключу дополнительный атрибут. Этот атрибут, называемый дискриминатором или частичным ключом, должен уникальным образом идентифицировать сущность среди всех сущностей, связанных с конкретной сущностью другого класса посредством определяющего типа связи. В этом случае атрибут dateRented и ключ связанной видеокассеты формируют составной ключ, уникальным образом определяющий сущности класса PreviousRental. Атрибут dateRented дает возможность различать состоявшиеся в прошлом операции проката конкретной видеокассеты. На ER-диаграмме (2.8) имя частичного ключа подчеркнуто пунктирной линией.

Такое определение ключа класса сущности PreviousRental может создать некоторые проблемы для точек проката компании BigHit Video. В частности, при таком определении видеокассету нельзя взять напрокат дважды в течение одного дня. Простейшим способом избежать этой проблемы можно, заменив атрибут dateRented атрибутом dateTimeRented, включающим и дату, и время. Если подобная модификация по каким-либо причинам не подходит, можно создать искусственный атрибут rentalid, который будет служить ключом класса сущности.

Такая стратегия обработки текущих и прошлых операций проката обнаруживает некоторую ограниченность ER-моделей. Тип связи “один к одному” между классами Rental и videotape определяет, что видеокассета может участвовать не более чем в одной текущей операции проката. Однако при возврате видеокассеты соответствующая сущность класса Rental удаляется, а аналогичная сущность класса PreviouslyRental должна быть создана. В некотором смысле можно говорить, что сущность класса Rental преобразуется в сущность класса PreviouslyRental. К сожалению, ER-диаграммы не располагают средствами представления такого преобразования.

Альтернативным решением является использование единого класса сущностей Rental, связанного с классом Customer посредством типа связи “многие ко многим”. При такой стратегии текущие операции проката представляются сущностями со значением даты возврата null. Однако при таком структурном решении ER-диаграмма не может отразить существование требования участия видеокассеты не более чем в одной связи с текущей операцией проката. Разработчики должны принять решение о том, что важнее: обеспечение того, что существует не более одной текущей операции проката определенной видеокассеты, или же гарантия того, что прошлые операции проката обрабатываются правильно. Модель, представленная на 2.8, является компромиссной.

Комментарии закрыты