MySQL. Реляционная база данных. Нормализация данных. Связи между данными
Web-разработки, реклама и информация
[19-01-2004] Джо
MySQL -система управления реляционными базами данных. Реляционная база данных представляет из себя набор таблиц данных, связанных между собой. Relatio (лат) - отношение, порядок расположения ячеек таблицы, одинаковый для всех ее строк, задает отношение между данными строки таблицы. Пример реляционной таблицы:
| Магазин снаряжения | ||||
|---|---|---|---|---|
| Магазин | Адрес | Метро | Телефон | Ассортимент |
| Терра у Горьковской | Кронверкский пр, 31 | Горьковская | 2336303 | туристическая одежда, обувь,палатки, рюкзаки, спальники |
| Терра у Лесной | Парголовская ул, 7 | Лесная | 2451290 | обвязки, веревки, туристическая одежда, треккинговая обувь, палатки, рюкзаки, спальники |
| Снаряжение | Марата ул, 12 | Маяковская | 3110760 | обвязки, веревки, туристическая одежда, треккинговая обувь, палатки, рюкзаки, спальники |
| Снаряжение | Перекупной пер, 7/9 | Площадь Александра Невского | 1107993 | NULL |
NULL означает, что значение не внесено.
Таблицу называют сущностью, заголовки столбцов таблицы ( наименования полей ) - атрибутами, строку таблицы (запись) - экземпляром сущности, ячейки таблицы ( поля ) - значениями атрибутов.
Существуют так называемые правила нормализации, позволяющие избегать избыточности данных в базах.
1. Значение атрибута для экземпляра сущности должно быть единственным ( 1-я нормальная форма (НФ) сущности );
2. для сущности, уже находящейся в 1НФ, значение каждого неидентифицирующего атрибута должно полностью зависеть от всего уникального идентификатора сущности ( 2-я нормальная форма (НФ) сущности );
3. для сущности, уже находящейся в 2НФ, значение каждого неидентифицирующего атрибута не должно зависеть от значения другого неидентифицирующего атрибута ( 3-я нормальная форма (НФ) сущности );
Попробуем применить эти правила к сущности Магазин снаряжения. Для начала - об идентифицирующих атрибутах. Чтобы избежать путаницы, каждый экземпляр сущности должен иметь идентифицирующий атрибут ( составной идентифицирующий атрибут, состоящий из нескольких неидентифицирующих ). На практике это означает, что в таблице должен присутствовать столбец, все значения в ячейках которого уникальны, не равны NULL и не меняются. В нашей таблице нет ни одного столбца, значения которого были бы уникальны. Самый простой выход - добавить столбец Код, в котором перенумеровать строки по порядку. Первому правилу нормализации явно не удовлетворяет атрибут Ассортимент - в одной ячейке - несколько значений. Чтобы разрешить эту ситуацию необходимо создать новую сущность Вид снаряжения.
| Магазин снаряжения | ||||
|---|---|---|---|---|
| Код магазина | Магазин | Адрес | Метро | Телефон |
| 1 | Терра у Горьковской | Кронверкский пр, 31 | Горьковская | 2336303 |
| 2 | Терра у Лесной | Парголовская ул, 7 | Лесная | 2451290 |
| 3 | Снаряжение | Марата ул, 12 | Маяковская | 3110760 |
| 4 | Снаряжение | Перекупной пер, 7/9 | Площадь Александра Невского | 1107993 |
| Вид снаряжения | |
|---|---|
| Код вида снаряжения | Наименование вида снаряжения |
| 1 | туристическая одежда |
| 2 | треккинговая обувь |
| 3 | палатки |
| 4 | рюкзаки |
| 5 | спальники |
| 6 | обвязки |
| 7 | веревки |
При такой организации нет дублирования данных - каждый вид снаряжения вводится только один раз. Очевидно, что между двумя сущностями есть связь. Связи между сущностями обычно бывают 2 типов - "один ко многим" или "многие ко многим". В рассматриваемом примере - связь "многие ко многим" - в каждом магазине несколько видов снаряжения, один и тот же вид снаряжения может быть в нескольких магазинах. Типичный пример связи "один ко многим" - ситуация сотрудник - предприятие (если пренебречь совместительствами) или ситуация отец - дети ( если мать точно знает, кто отец ). Если между сущностями связь "один к одному" - значит одна сущность лишняя.
2-е правило нормализации означает, что мы должны что-то что-то сделать с названиями магазинов Снаряжение. В этом случае атрибут Магазин не полностью зависит от идентифицирующего атрибута Код Магазина. Т. е. в экземплярах сущности с Кодом магазина 3 и 4 содержатся одинаковые значения атрибута Магазин. Но советовать фирме Снаряжение переименовать свои магазины для того, чтобы уложиться в схему нормализации - как-то неправильно, а городить новые сущности для частного случая - только усложнять структуру базы данных. В данном конкретном случае, если все же нормализацию доводить до победного конца, нужно создать еще сущность Название магазина с атрибутами Код магазина и Название.
3-е правило нормализации можно проиллюстрировать так. Допустим, нам надо в описание магазина добавить еще Город и Телефонный код города - два неидентифицирующих атрибута. Но Телефонный код зависит от Города, стало быть, надо создать новую сущность Город с атрибутами - Код ( идентифицирующий ), Название города, Телефонный Код и связать ее с сущностью Магазин снаряжения.
Теперь нужно организовать связь между сущностями Магазин снаряжения и Вид снаряжения. Для этого создаем сущность-связь Магазин >-< Вид снаряжения :
| Магазин >-< Вид снаряжения | ||
|---|---|---|
| Код | Код магазина | Код вида снаряжения |
| 1 | 1 | 1 |
| 2 | 1 | 2 |
| 3 | 2 | 1 |
| 4 | 2 | 2 |
В этой таблице указаны не все указанные выше связи, чтобы не городить слишком большую таблицу.
Теперь, чтобы узнать, например, какие виды снаряжения есть в магазине Ирбис на Фонтанке, нужно сделать запрос к базе данных. Но это уже совсем другая история.
И напоследок правило ( "бритва" ) Оккама:
Не создавайте сущности без необходимости.
