2.1 Реляционные базы данных Microsoft Access 2010.

Автор Filip Sergienko
2.1 Реляционные базы данных Microsoft Access 2010.

реляционная база данных как мы уже знаем состоят из таблиц.

Каждая таблица состоит из столбцов их называют полями или инструк их называют записями или кортежами таблицы в реляционных базах данных обладают рядом свойств основными являются следующие свойства не может быть двух одинаковых строк в. Столбцы располагаются в определенном порядке которые создаются при создании таблицы таблицы может не быть ни одной строки, но обязательно должен быть хотя бы один столбец. У каждого столбца есть уникальное имя таблицы и все значения в одном столбце имеют один тип — это может быть число текст или дата пересечение каждого столбца и строки может находиться только атомарные значения одно значение из группы значений таблицы удовлетворяющие этому условию называют нормализованы me всё будет понятнее на примере предположим мы захотели создать базу данных для формы форма зарегистрированные пользователи которые создают тема.

И оставляют сообщение в этих темах — это информация и должна храниться в базе данных теоретически на бумаге мы можем.

Света расположен в одной таблице например так, но — это противоречит свойству атомарности одно значение в одной ячейке. А в столбцах все мои сообщения у нас предполагаются неограниченное количество значит нашу таблицу надо разбить на 3 пользователей системы и сообщение наша таблица пользователей удовлетворяет всем условиям нет ведь в таблице не может быть двух одинаковых строк а. Где гарантия, что один пользователь два одинаковых сообщения например так. Кроме того мы знаем, что каждое сообщение обязательно относится какой-либо теме. А как — это можно узнать из наших никак для решения этих проблем в реляционных базах данных существуют. Включи первичный ключ — это столбец значение которого во всех строках различные ключи могут быть логическими естественными и с рогатыми искусственными так для наших пользователей первичным ключом может вставить столбец емэйл ведь теоретически не может быть двух пользователей с одинаковым емэйл, но на практике лучше использовать суррогатные ключи так как их применение позволяет абстрагировать ключи от реальных данных. Кроме того первичные ключи менять нельзя. А, что если у пользователя изменится суррогатный ключ представляет собой дополнительное поле в базе данных как правило — это порядковый номер записи. Давайте внесем поля первичных ключей в нашей таблицы пользователей и соответственно сообщение. Я теперь каждая запись в наших таблицах уникальная нам осталось. Установить соответствие между темами и сообщениями делается — это также при помощи различных ключей в таблицу сообщения мы добавим ещё одно поле. Теперь понятно, что сообщение. С равно 2 принадлежит зимней рыбалки равняется единице с. Артёмом принадлежит такое поле называется внешний ключ каждое значение этого поля соответствует какому либо первичному ключу из таблицы темы так — это однозначное соответствие между сообщениями и темами к которым они относятся последнего у нас добавился новый пользователь. И зовут его тоже. Артём как мы узнаем какой именно. Артём оставил сообщение для этого поля автор в таблицах темы и сообщения мы сделаем так же с ними ключами наша база данных готова схематично её можно представить так в нашей маленькой базе данных всего три таблицы. А если бы их было 100 или 200 понятно, что сразу невозможно представить все таблицы связи которые нам могут понадобиться. Именно поэтому проектирование базы данных начинается с концептуальной модели которые мы и рассмотрим.

0 комментариев
0

Читайте также