Лекции №3,4 (14 и 16.09.2004)

Слабые сущности.
Иногда, ключ формируется не только из собственных атрибутов
объекта, но и из ключей одного или более объектов, связанных с
данным как один-ко-многим.
 Такое множество объектов (сущностей) называется слабым.
 Слабое множество представляется двойным прямоугольником,
двойным ромбом - каждая из связей с другими множествами,
ключи которых используются в данном (такую связь будем
называть поддерживающей).
 Важно то, что связь от слабой сущности к сильной должна
быть «многие-к-ровно-одному(включая, в частности, связь
«один-к-ровно-одному»).
 Для связи «многие-ко-многим» мы не знали бы, какая
сущность участвует в формировании ключа слабой
сущности.
 «к-ровно-одному» также важно, иначе поддерживающая связь
не гарантировала бы формирования ключа слабой сущности.
Пример: Логины (E-mail адреса).
Имя входа (логина) = имя пользователя+имя компьютера.
 Сущность «логин» соответствует имени пользователя на
определенном главном компьютере, но список паролей не
хранит имя этого компьютера.
 Ключ «Логин» = имя пользователя (является уникальным для
данного главного компьютера) + IP- адрес (является
уникальным для всей сети).
name
Logins
name
@
Hosts

Вопрос: Можно ли сделать «имя пользователя» и «имя
компьютера» свойствами объекта «Логин» и не вводить
слабый объект?
Пример: Цепочка «Слабостей».
IP–адрес включает имя домена 1 уровня + имя домена 2 уровня +
имя компьютера в сети.
Имя
Имя
Компью
тер
В2
Домен 2
уровня
Имя
В1
Домен 1
уровня
 Ключ «Домена 1 уровня» = его имя.
 Ключ «Домена 2 уровня» = его имя + имя домена 1 уровня.
 Ключ «Компьютера» = его имя + ключ «Домена 2 уровня».
Множество объектов-связей, используемое для декомпозиции
множественной связи на несколько бинарных – слабое
множество.
BarBeerPrice
TheBar
Bars
name
addr
TheBeer
ThePrice
Beers
Prices
name
manf
price
 В случае когда «Bar» и «Beer» определяют цену, можно
опустить цену из ключа и убрать двойной ромб у «ThePrice».
 Лучший вариант: цена – свойство (атрибут) «BarBeerPrice» без
сущности «Prices».
Принципы разработки проекта базы данных.
Установка:
Заказчик (клиент) имеет идеи (представления,
возможно, нереализуемые) о том, что он(она) хочет получить в
результате. Вы должны разработать базу данных так, чтобы она
реализовала эти мысли и только эти мысли.
Избегайте избыточности
= повторение того же самого больше одного раза (дублирование).
 Приводит к использованию лишней памяти и несовместности.
Пример.
Хороший вариант:
addr
name
name
Beers
Manfs
ManfBy
Плохой вариант: «адрес производителя» будет дублироваться для
каждого «производителя».
name
Manfs
Beers
addr
Плохой вариант: «имя производителя» дублируется.
name
name
Beers
manf
ManfBy
addr
Manfs
Используйте схему (диаграмму), чтобы показать
ограничения целостности.
Схема проекта должна позволить выявить как можно больше
ограничений.
 Не полагайтесь на предложения пользователей.
Пример:
Если регистратор хочет связывать только одного преподавателя с
предметом, не рассчитывайте, что для множества объектов
«Преподаватели» он будет вводить только одного преподавателя
на предмет, покажите это на схеме с помощью стрелки или даже
круглой стрелки.
Объекты или атрибуты?
Не просто разобраться, какие понятия из предметной области
должны стать объектами, а какие – просто атрибутами других
объектов.
 Имеется соблазн создать много бесполезных объектов,
которые сделают проект «больше».
Неправильно:
name
name
Beers
Manfs
ManfBy
Правильно:
name
Beers
manf
Интуитивное правило для выбора Объект или Атрибут.
Определите понятие как объект только если оно:
1. Определяется не только названием чего-либо, то есть имеет
неключевые атрибуты или связи с несколькими другими
объектами, или
2. Является «многим» в связи «многие-к-одному».
Пример:
 иллюстрирует использование приведенных правил.
name
name
Beers
ManfBy
addr
Manfs
 Производитель – объект, так как имеет атрибут «адрес»,
который не является ключом.
 Сорт пива – объект, так как конец связи «многие».
 Если бы это было не так, то надо было бы сделать
«множество сортов пива» атрибутом «Производителя». Мы
будем стараться избегать этого, хотя некоторые считают это
вполне допустимым.
Не переусердствуйте со слабыми объектами.
 Иногда очень трудно идентифицировать объект во множестве
подобных объектов без определения связи.
 Практически всегда, в таких случаях вводится атрибут с
уникальными значениями, подобный ID.
 Слабый объект необходимо ввести только, если:
 Невозможно легко определить уникальный атрибут,
например, идентификатор семейства в классификации
животных или растений (семейство – слабое множество,
имеющее поддерживающую связь с соответствующим
родом).
 Нет глобального администратора, создающего и
поддерживающего уникальные идентификаторы.
Пример разработки проекта.