Создание БД. Этапы проектирования

Ключи.

Основные понятия реляционных БД: нормализация, связи и ключи

Принципы нормализации:

· В каждой таблице БД не должно быть повторяющихся полей;

· В каждой таблице должен быть уникальный идентификатор (первичный ключ);

· Каждому значению первичного ключа должна соответствовать достаточная информация о типе сущности или об объекте таблицы (например, информация об успеваемости, о группе или студентах);

· Изменение значений в полях таблицы не должно влиять на информацию в других полях (кроме изменений в полях ключа).

Виды логической связи.

Связь устанавливается между двумя общими полями (столбцами) двух таблиц. Существуют связи с отношением «один-к-одному», «один-ко-многим» и «многие-ко-многим».

Отношения, которые могут существовать между записями двух таблиц:

· один – к - одному, каждой записи из одной таблицы соответствует одна запись в другой таблице;

· один – ко - многим, каждой записи из одной таблицы соответствует несколько записей другой таблицы;

· многие – к - одному, множеству записей из одной таблице соответствует одна запись в другой таблице;

· многие – ко - многим, множеству записей из одной таблицы соответствует несколько записей в другой таблице.

Тип отношения в создаваемой связи зависит от способа определения связываемых полей:

· Отношение «один-ко-многим» создается в том случае, когда только одно из полей является полем первичного ключа или уникального индекса.

· Отношение «один-к-одному» создается в том случае, когда оба связываемых поля являются ключевыми или имеют уникальные индексы.

· Отношение «многие-ко-многим» фактически является двумя отношениями «один-ко-многим» с третьей таблицей, первичный ключ которой состоит из полей внешнего ключа двух других таблиц

Ключ– это столбец (может быть несколько столбцов), добавляемый к таблице и позволяющий установить связь с записями в другой таблице. Существуют ключи двух типов: первичные и вторичные или внешние.

Первичный ключ – это одно или несколько полей (столбцов), комбинация значений которых однозначно идентифицирует каждую запись в таблице. Первичный ключ не допускает значений Null и всегда должен иметь уникальный индекс. Первичный ключ исп ользуется для связывания таблицы с внешними ключами в других таблицах.

Внешний (вторичный) ключ - это одно или несколько полей (столбцов) в таблице, содержащих ссылку на поле или поля первичного ключа в другой таблице. Внешний ключ определяет способ объединения таблиц.

Из двух логически связанных таблиц одну называют таблицей первичного ключа или главной таблицей, а другую таблицей вторичного (внешнего) ключа или подчиненной таблицей. СУБД позволяют сопоставить родственные записи из обеих таблиц и совместно вывести их в форме, отчете или запросе.

Существует три типа первичных ключей: ключевые поля счетчика (счетчик), простой ключ и составной ключ.

Поле счетчика (Тип данных «Счетчик»). Тип данных поля в базе данных, в котором для каждой добавляемой в таблицу записи в поле автоматически заносится уникальное числовое значение.

Простой ключ. Если поле содержит уникальные значения, такие как коды или инвентарные номера, то это поле можно определить как первичный ключ. В качестве ключа можно определить любое поле, содержащее данные, если это поле не содержит повторяющиеся значения или значения Null.

Составной ключ. В случаях, когда невозможно гарантировать уникальность значений каждого поля, существует возможность создать ключ, состоящий из нескольких полей. Чаще всего такая ситуация возникает для таблицы, используемой для связывания двух таблиц многие - ко - многим.

Необходимо еще раз отметить, что в поле первичного ключа должны быть только уникальные значения в каждой строке таблицы, т.е. совпадение не допускается, а в поле вторичного или внешнего ключа совпадение значений в строках таблицы допускается.

Если возникают затруднения с выбором подходящего типа первичного ключа, то в качестве ключа целесообразно выбрать поле счетчика.

Создание БД начинается с проектирования. Этапы проектирования БД:

· Исследование предметной области;

· Анализ данных (сущностей и их атрибутов);

· Определение отношений между сущностями и определение первичных и вторичных (внешних) ключей.

В процессе проектирования определяется структура реляционной БД (состав таблиц, их структура и логические связи). Структура таблицы определяется составом столбцов, типом данных и размерами столбцов, ключами таблицы.

К базовым понятиями модели БД «сущность – связь» относятся: сущности, связи между ними и их атрибуты (свойства).

Сущность – любой конкретный или абстрактный объект в рассматриваемой предметной области. Сущности – это базовые типы информации, которые хранятся в БД (в реляционной БД каждой сущности назначается таблица). К сущностям могут относиться: студенты, клиенты, подразделения и т.д. Экземпляр сущности и тип сущности - это разные понятия. Понятие тип сущности относится к набору однородных личностей, предметов или событий, выступающих как целое (например, студент, клиент и т.д.). Экземпляр сущности относится, например, к конкретной личности в наборе. Типом сущности может быть студент, а экземпляром – Петров, Сидоров и т. д.

Атрибут – это свойство сущности в предметной области. Его наименование должно быть уникальным для конкретного типа сущности. Например, для сущности студент могут быть использованы следующие атрибуты: фамилия, имя, отчество, дата и место рождения, паспортные данные и т.д. В реляционной БД атрибуты хранятся в полях таблиц.

Связь – взаимосвязь между сущностями в предметной области. Связи представляют собой соединения между частями БД (в реляционной БД – это соединение между записями таблиц).

Сущности – это данные, которые классифицируются по типу, а связи показывают, как эти типы данных соотносятся один с другим. Если описать некоторую предметную область в терминах сущности – связь, то получим модель сущность - связь для этой БД.

Рассмотрим предметную область: Торговый центр.

Торговый центр осуществляет продажу товаров как оптом так и клиентам. Любая фирма, занимающаяся продажей товаров в розницу, закупает необходимые ей товары в торговом центре, который служит посредником между производителями и продавцами.

В торговый центр товар поступает от некоторой фирмы-поставщика, в свою очередь торговый центр продает товар фирме-покупателю, заключая с ней сделку о продаже товара.

Деятельность торгового центра характеризуется следующей информацией, которую можно объединить в группы следующим образом:

· поставщики (код поставщика, название фирмы-поставщика, адрес, телефон);

· покупатели (код покупателя, название фирмы-покупателя, адрес, телефон);

· товар (код товара, поставщик, название товара, количество, стоимость за единицу товара);

· сделки о продаже (код товара, покупатель, количество проданного товара);

· поставки товара (поставщик, товар, дата поставки, количество)

· сотрудники (код сотрудника, фамилия, имя, отчество, должность, внутренний телефон, рабочий и личный телефон).

На основании описанных данных необходимо вести учет поставщиков, покупателей, продаж, а также информацию о сотрудниках. Кроме того, можно делать выводы о работе торгового центра, спросе на определенные товары, выгодности работы с некоторыми поставщиками и покупателями.

Проектирование базы данных начнём с определения сущностей:

· Поставщики;

· Товары;

· Покупатели;

· Сотрудники.

В нашей задаче данные о связях сущностей сведем в таблицу 1 следующего вида:

Таблица 1 – Связи между сущностями

Тип сущности	Тип связи	Тип сущности	Класс принадлежности	Степень связи
поставщики	поставляют	товары	н: о	М: М
покупатели	покупают	товары	о: н	М: М
сотрудники	оформляют покупку	товаров	н: о	1:М

Поясним степень связи:

1 Каждый поставщик может поставлять несколько видов товара, а один вид товара может поставляться несколькими поставщиками;

2 Каждый покупатель может купить несколько товаров, а один вид товара могут купить несколько покупателей;

3 Один сотрудник может оформить несколько сделок на покупку товаров, но каждую сделку оформляет только один сотрудник.

Поясним класс принадлежности экземпляра сущности к связи:

1 Каждый поставщик не обязательно поставляет какой-либо товар (могут быть поставщики, которые временно не работают), а товар обязательно имеет поставщика;

2 Любой покупатель обязательно покупает товар, а определенный товар может быть не куплен ни одним покупателем;

3 Сотрудники торгового центра не обязательно оформляют сделки о продажах (например, водитель), но каждая сделка обязательно оформляется.

Далее необходимо определить атрибуты каждой сущности.

Таблица 2 – Атрибуты сущностей

Сущность	Первичный ключ	Атрибуты
поставщики	номер поставщика	номер поставщика название адрес телефон оператор
товары	номер товара	номер товара наименование стоимость единицы
покупатели	номер покупателя	номер покупателя фамилия имя отчество адрес телефон оператор
сотрудники	код сотрудника	код сотрудника фамилия имя отчество должность рабочий телефон личный телефон

На основании выше приведённых данных построим ER-диаграмму базы данных торгового центра.

Рисунок 1 – ER-диаграмма базы данных

Далее построенную ER – диаграмму необходимо преобразовать в набор безаномальных отношений. Выделенные поля являются ключевыми.

1) Сущности поставщики - товары имеют степень связь М:М, значит их можно преобразовать в три безаномальные отношения: ТОВАРЫ, ПОСТАВЩИКИ И ПОСТАВЩИКИ_ТОВАР.

ТОВАРЫ

№товара

наименование

стоимость

ПОСТАВЩИКИ

№ поставщика

название

адрес

телефон

оператор

ПОСТАВЩИКИ_ТОВАР

№поставщика

№ товара

количество

дата

2) Сущности товары – клиенты имеют степень связи М:М, значит их можно преобразовать в три безаномальные отношения: ТОВАРЫ, ПОКУПАТЕЛЬ и ПОКУПАТЕЛЬ_ТОВАР.

ПОКУПАТЕЛЬ

№ клиента

Фамилия имя отчество

пол

адрес

телефон

оператор

ПОКУПАТЕЛЬ_ТОВАР

№ клиента

№ товара

дата

количество

доставка

Отношение ТОВАРЫ уже существует.

3) Сущности сотрудники – товары имеют степень связи 1:М значит, их можно преобразовать в два безаномальные отношения (класс принадлежности М-связного экземпляра сущности обязательный): ТОВАРЫ, СОТРУДНИКИ и ПОКУПАТЕЛЬ_ТОВАР

В отношение ПОКУПАТЕЛЬ_ТОВАР необходимо добавить поле № сотрудника для связи с отношением СОТРУДНИКИ.

№ клиента

№ товара

дата

количество

доставка

№ сотрудника

СОТРУДНИКИ

№ сотрудника

Фамилия

имя

отчество

должность

Рабочий телефон

Личный телефон

Составим проекты таблиц, которые будут в дальнейшем реализовываться в СУБД. База данных «Торгового центра» будет содержать 6 следующих таблиц:

Таблица 3 – Структура таблицы ПОСТАВЩИКИ

наименование поля	размер	тип
№поставщика	целое	числовой
название		текстовый
адрес		текстовый
телефон		текстовый
оператор		текстовый

Таблица 4 – Структура таблицы ПОСТАВЩИКИ_ТОВАР

наименование поля	размер	тип
№товара		числовой (мастером подстановки из таблицы товары)
№поставщика		числовой(мастером подстановки из таблицы поставщики)
Дата	Короткий формат даты	дата/время
количество		числовой

Таблица 5 – Структура таблицы ПОКУПАТЕЛЬ_ТОВАР

наименование поля	размер	тип
№покупателя		числовой(мастером подстановки из таблицы покупатели)
№товара		числовой(мастером подстановки из таблицы товары)
дата	Короткий формат даты	дата/время
количество		числовой
доставка		логический
№сотрудника		числовой(мастером подстановки из таблицы сотрудники)

Таблица 6 – Структура таблицы ТОВАРЫ

наименование поля	размер	тип
№товара		счетчик
наименование		текстовый
стоимость		денежный

Таблица 7 – Структура таблицы ПОКУПАТЕЛИ

наименование поля	размер	тип
№клиента		счетчик
Фамилия имя отчество		текстовый
пол		Текстовый (список значений)
адрес		текстовый
телефон		текстовый
оператор		Текстовый (список значений)

Таблица 8 – Структура таблицы СОТРУДНИКИ

наименование поля	размер	тип
№сотрудника		счетчик
фамилия		текстовый
имя		текстовый
отчество		текстовый
пол		Текстовый (список значений)
должность		текстовый
адрес		текстовый
рабочий телефон		текстовый

Дата добавления: 2015-05-09