На этом шаге мы рассмотрим реляционную модель базы данных.
В последние годы в большинстве БД используются реляционные модели данных, и практически все современные СУБД ориентированны именно на такое представление информации. Реляционную модель можно представить как особый метод рассмотрения данных, который включает как собственно данные (в виде таблиц), так и способы работы и манипуляции с ними (в виде связей). Другими словами, в реляционной БД используется несколько таблиц, между которыми устанавливаются связи. Таким образом, информация, введенная в одну таблицу, может быть связана с одной или несколькими записями из другой таблицы.
Между записями двух таблиц (например, таблиц А и В) могут существовать следующие основные виды связей:
- "один к одному" (каждой записи из А соответствует одна определенная запись из В, например, работник получает зарплату, и только одну);
- "один ко многим" (каждой записи из А соответствует несколько записей из В, например, в доме проживает много жильцов);
- "многие к одному" (множеству записей из А соответствует одна определенная запись из В, например, несколько студентов учатся в одной группе);
- "многие ко многим" (множеству записей из А соответствует множество записей из В, например, у нескольких студентов занятия ведут разные преподаватели).
Важным понятием в теории реляционных БД является нормализация, принципы которой можно сформулировать в виде следующих основных правил, используемых при разработке структуры БД:
- В каждом поле таблицы должен находиться уникальный вид информации, т.е. в одной и той же таблице не должны находиться повторяющиеся поля.
- В каждой таблице должен быть первичный ключ или уникальный идентификатор, который однозначно определяет данную запись среди множества записей таблицы.
- Каждому значению первичного ключа должна соответствовать исчерпывающая информация об объекте таблицы (в частности, объектом таблицы может быть студент, полная информация о котором представлена в таблице БД "Стипендия").
- Изменение значения любого поля таблицы, не входящего в состав первичного ключа, не должно влиять на информацию в других ее полях.
На следующем шаге мы рассмотрим особенности Access.
