Составители:
Рубрика:
10
Добавленные стрелочки указывают, какой из объектов должен указывать
на связанный с ним. Разберемся, как выбирать объекты, которые будут
хранить информацию о связях между объектами. У Телефонного номера один
Владелец, но у Владельца может быть несколько Телефонных номеров. Это
значит, что если информацию о ссылке хранить объектеТелефонный номер,
то для него
достаточно отвести одно дополнительное поле, содержащее
значение ключевого поля объекта Владелец телефона. Если ссылки
натобъекты Телефонный номер хранить в объекте Владелец телефона, то
либо на каждую ссылку нужно заводить отдельный атрибут, либо хранить в
одном поле несколько ссылок (например список , разделенный запятой), и
предусмотреть механизм выделения нужной ссылки, что представляется
нецелесообразным
. Такой тип связи получил название "один-ко-многом".
Аналогичная ситуация получается в при организации связи Адреса и Улицы -
в Адресе указывается одна Улица, но Улица может встречаться в нескольких
Адресах. В рассмотренной нами модели предметной области Владелец
телефона связывается с одной Организацией, что в других ситуациях может
не соответствовать требованиям
задачи.
Другая ситуация складывается при описании связи Адреса и Владельца
телефона. С одним адресом может быть связано несколько Владельцев
телефонов - следовательно хранить информацию о связи в объекте Адрес
нецелесообразно. С другой стороны Владелец телефона может быть связан с
несколькими Адресами, что делает нецелесообразным хранение информации
о связях и в объекте Владелец
телефона. Такие связи получили название
"многие-ко-многим". Решение задачи хранения информации о связях такого
типа обычно связано с созданием дополнительного промежуточного объекта
хранения, в котором хранится информация об обоих связанных объектах и
связь "многие-ко-многим" таким образом заменяется парой связей "один-ко-
многим"
Прежде чем изображать получившуюся блок
-схему отметим различие
между имеющимися связями. Телефон обязательно имеет Владельца, в
Адресе обязательно должна быть указана Улица, а вот Владелец телефона
может быть не связан ни с одной организацией. И та и другая ситуация
требует внимательного отношения при реализации проекта.
Изобразим получившуюся блок-схему.
11
Данную схему данных можно положить в основу создаваемой базы
данных. Для осуществления следующего шага дадим объектам и их
атрибутам имена, которые могут использоваться при создании базы данных.
В качестве сервера базы данных мы будем использовать MySQL. Для имен
лучше использовать осмысленные названия, состоящие из одного слова,
набранные латинскими буквами. Если предполагается
использовать сервер
базы данных, работающий в под управлением операционной системы LINUX,
то необходимо учитывать и регистр, в котором набираются имена.
Сведем полученную нами информацию в таблички
Имя объекта: provider
Имя атрибута Тип данных атрибута Дополнительные условия
id_provider
Целое число Первичный ключ
provider_na
me
Строка переменной
длины
Имя объекта: phone
Имя атрибута Тип данных атрибута Дополнительные условия
id_phone
Целое число Первичный ключ
phone_numb
er
Строка фиксированной
длины
id_provider
Целое число Ссылается на первичный ключ
объекта provider
Имя объекта: organization
Имя атрибута Тип данных атрибута Дополнительные
условия
id_organisation
Целое число Первичный ключ
orgatisation_name
Строка переменной длины
Владелец
телефона
Телефон-
ный номер
Организация
Адрес
Улица
Связь
Адрес -
Владелец
Провайдер
Страницы
- « первая
- ‹ предыдущая
- …
- 4
- 5
- 6
- 7
- 8
- …
- следующая ›
- последняя »
