Определение цели создания базы данных.

На первом этапе проектирования базы данных необходимо определить цель создания базы данных, основные ее функции и информацию, которую она должна содержать.

Данная база данных разработана для торговой организации, занимающейся поставкой товаров – женской косметики через интернет – клиентам. Схема работы очень проста. Покупатели (все данные и контакты находятся в таблице «Покупатели ») делает заказ на определенный товар. Этот заказ заносится в таблицу «Заказанные товары », в торой отражается количество и наименование товара. Остальные таблицы, формы, запросы базы будут нужны для информационной, правильной, четкой, работы. Чтобы можно было сразу узнать кто заказал, кто производитель, посчитать суммы заказов, сделать отбор по определенным данным.

Определение таблиц, которые должна содержать база данных.

Один из наиболее сложных этапов в процессе создания базы данных - разработка таблиц, так как результаты, которые должна выдавать база данных не всегда дают полное представление о структуре таблицы.

Таблицы должны содержать всю информацию разрабатываемой базы. В данной работе это «Покупатели», «Заказ», «Заказанные товары», «Товар», «Поставщики». Все таблицы хранят максимально полную характеристику, информацию и описание для дальнейшей успешной работы с базой данных.

 

 

Присвоение ключевых полей.

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

Редактирование структуры базы данных.

Для проверки правильности работы базы необходимо создать несколько таблиц, определить связи между ними и ввести несколько записей в каждую таблицу, а затем посмотреть, отвечает ли база данных поставленным требованиям. А так же, необходимо исключить всевозможные повторения данных. Иначе база не будет работать и выдавать нужный запрос или информацию.

Добавление данных и создание других объектов базы данных.

Если структуры таблиц отвечают поставленным требованиям, то можно вводить все данные (в режиме конструктора таблиц). После ввода создаются любые запросы, формы, отчеты, макросы и модули.

 

Инфологическая модель.

Прежде чем начинать проектирование базы данных, необходимо разобраться, как функционирует предметная область создаваемой БД. Для этих целей используют искусственные формализованные языковые средства. В связи с этим под инфологической моделью понимают описание предметной области, выполненное с использованием специальных языковых средств, не зависящих от используемых в дальнейшем программных средств. Лучше сначала нарисовать на бумаге таблицы с данными, потом преобразовать их из «Первой нормальной формы» во «Вторую нормальную форму», и далее в «Третью нормальную форму».

Первая нормальная форма (1NF) — базовая нормальная форма отношения в реляционной модели данных.

Вторая нормальная форма (англ. Second normal form; сокращённо 2NF) — одна из возможных нормальных форм таблицы реляционной базы данных.

Третья нормальная форма (англ. Third normal form; сокращённо 3NF) — одна из возможных нормальных форм отношения реляционной базы данных.

Определяют три основные класса сущностей:

· стержневые

· ассоциативные

· характеристические.

Стержневая сущность – независимая сущность, которая имеет независимое существование, хотя может обозначать другие сущности.

Характеристическая сущность (характеристика) – это связь вида "многие-к-одному" или "одна-к-одной" между двумя сущностями (частный случай ассоциации). Цель характеристики состоит в описании или уточнении некоторой другой сущности предметной области. Ассоциативная сущность (ассоциация) – это связь вида "многие-ко-многим" между двумя или более сущностями или экземплярами сущности.

 

 

Даталогическая модель.

Структура моей базы данных.

Таблицы.

Моя БД содержит 5 таблиц:

1. «Покупатели».

2. «Заказ».

3. «Заказанные товары».

4. «Товар».

5. «Поставщики».

Во всех таблицах в режиме конструктора указываются первичные или внешние ключи.

Таблица «Покупатели» предназначена для хранения данных о покупателях, их ФИО и адрес поставки заказа (рис.1.).

Рис.1. Содержание таблицы «Покупатели».

Таблица «Заказ» отражает дату заказа и ID заказа (рис.2.).

Рис.2. Содержание таблицы «Заказ».

 

Таблица «Заказанные товары» показывает код товара, сумму и количество заказанного товара (рис.3.).

Рис.3. Содержание таблицы «Заказанные товары».

 

Таблица «Товар» предназначена для хранения имеющегося товара (рис.4).

Рис.4. Содержание таблицы «Товар».

 

 

Таблица «Поставщики» показывает поставщика товара (рис.5.).

Рис.5. Содержание таблицы «Поставщики».

 

Нормализация

Нормализация — процесс уменьшения избыточности информации в таблицах реляционной БД и, как следствие, построения оптимальной структуры таблиц и связей.

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

 

1. Каждое поле любой таблицы должно быть уникальным.

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

3. Для каждого значения первичного ключа должно быть одно и только одно значение любого из столбцов данных, и это значение должно относиться к объекту таблицы.

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

 

Первая нормальная форма:

Название таблицы.	Ключевое поле.
«Покупатели» «Заказ» «Заказанные товары» «Товар» «Поставщики»	Номер клиента Id заказа Артикул, Номер примера заказа Код товара Id поставщика

 

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

Третья нормальная форма: все не ключевые атрибуты отношения взаимно независимы и полностью зависят от первичного ключа.

Таким образом, база данных удовлетворяет всем требованиям нормализации таблиц и Третья нормальная форма – окончательный результат нормализации БД.

 

Схема данных.

Отношения – это правила, поддерживаемые на уровне механизма реализации СУБД. Различают три типа отношений:

- Отношение «один-к-одному»: для каждой строки в одной таблице существует не более одной строки связанной таблицы.

- Отношение «один-ко-многим»: одна таблица не содержит вообще или имеет набор связанных «дочерних» записей из другой таблицы.

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

При разработке БД необходимо принимать во внимание правила обеспечения целостности данных (обеспечивает каскадное обновление записей в связанных таблицах).

Рис.6. Схема данных.