Графическое обозначение реляционной модели
Графически реляционную модель можно представить, как показано на рис. 4.9. Каждая таблица изображается в виде прямоугольника, в верхней части которого записано название таблицы (класса объектов). Ниже можно указать названия полей. Поля, являющиеся ключом, выделены. Соединительные линии между таблицами обозначают связи. Над связью в конкретной базе данных можно написать ее смысл, а также тип отношения: «один- ко-многим», «многие-ко-многим».
Рис. 4.9. Реляционная модель
Составим реляционную модель для базы данных Песни. Представим сведения о песнях в виде двух взаимосвязанных классов — Исполнители и Песни. Тогда вместо одной таблицы получится две (табл. 4.3, 4.4).
Будем рассматривать такую модель, где каждую песню исполняет только один исполнитель. Тогда можно сказать, что классы Исполнители и Песни связаны отношением «один-ко-многим». Естественно, что в таблице Исполнители будет меньше записей, чем в таблице Песни.
Таблица 4.3. Исполнители
Таблица 4.4. Песни
Если бы мы приняли условие, что каждая песня может быть исполнена несколькими исполнителями, то отношение между таблицами стало бы «многие-ко-многим», и это была бы уже другая модель.
Ключом в таблице Исполнители можно выбрать поле Исполнитель, так как названия исполнителей не повторяются. Это поле текстовое. При проектировании баз данных часто вводят дополнительное поле числового типа, в котором указывают порядковый номер каждой записи в таблице.
|
|
|
Как правило, это поле имеет имя Код <имя объекта>. Это поле вводится в расчете на дальнейшую компьютерную обработку данных. Дело в том, что программной среде «легче» работать с числами, чем с текстом. Порядковые номера не повторяются, поэтому такое поле можно выбрать в качестве ключевого.
Так в таблицу Исполнители можно ввести поле Код исполнителя числового типа, а в таблицу Песни — поле Код песни.
В таблицах, связанных отношением «один-ко-многим», связь между таблицами осуществляется по ключевому полю следующим образом. В таблицу Песни добавляется поле с названием Код исполнителя и для каждой песни в нем указываются соответствующие номера исполнителей. Такой номер, по сути, несет в себе всю информацию об исполнителе, представленную в соответствующей таблице. Это и означает, что связь между таблицами осуществлена по ключу Код исполнителя. Реляционная модель этой базы данных представлена на рис. 4.10.
Рис. 4.10. Реляционная модель базы данных Любимые песни
Возникает закономерный вопрос: зачем нужно было разделять одну таблицу на две? На первый взгляд может показаться, что одна таблица (см. табл. 4.1) удобнее для восприятия информации. Но в такой таблице нам надо было каждый раз полностью указывать название исполнителя и все его характеристики. Поскольку по свойству реляционных таблиц каждая запись (строка) считается независимой от других записей, то такая таблица не отражает в полной мере связь между песнями и исполнителями. Более того, если в какой-то строке вы записали исполнителя с ошибкой, то это будет восприниматься как новое значение. Если же исполнители выделены в отдельную таблицу, то такие операции как удаление или изменение данных можно производить намного легче и быстрее.
|
|
|
Надо заметить, что связь «многие-ко-многим» реализуется другим, более сложным, способом.
Дата добавления: 2016-01-03; просмотров: 77; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!