Автоматизированный учет заказов в мебельном салоне

 

1      1     1      М    М     М

Рис.2 Виды связей

 

1. Связь типа один-к-одному означает, что один экземпляр первой сущности (левой) связан с одним экземпляром второй сущности (правой).
2. Связь типа один-ко-многим означает, что один экземпляр первой сущности (левой) связан с несколькими экземплярами второй сущности (правой). Это наиболее часто используемый тип связи, например один клиент может сделать много заказов.
3. Связь типа много-ко-многим означает, что каждый экземпляр первой сущности может быть связан с несколькими экземплярами второй сущности, и каждый экземпляр второй сущности может быть связан с несколькими экземплярами первой сущности. Тип связи много-ко-многим является временным типом связи, допустимым на ранних этапах разработки модели. В дальнейшем этот тип связи должен быть заменен двумя связями типа один-ко-многим путем создания промежуточной сущности.

Обозначенные на «Рис.3» связи между сущностями показывают, что:

               -      один клиент может сделать много заказов (один-ко-многим);

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

 

Рис.3 Концептуальная модель

 

 

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

 

 

2.2. Проектирование логической модели данных.

Вторым этапом в проектировании базы данных является построение логической модели данных.

Логическое (даталогическое) проектирование — создание схемы базы данных на основе конкретной модели данных, например, реляционной модели данных.

Основы реляционной модели данных были впервые изложены в статье Е.Кодда в 1970 г. Эта работа послужила стимулом для большого количества статей и книг, в которых реляционная модель получила дальнейшее развитие. Реляционная модель основана на математическом понятии отношения, физическим представлением которого является таблица.

Отношение – это плоская таблица, состоящая из столбцов и строк.

Атрибут - это поименованный столбец отношения.

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

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

В реляционной модели отношения используются для хранения информации об

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

При построении логической модели реляционной базы данных необходимо нормализовать отношения информационной модели предметной области и превратить ее объекты в логические таблицы базы данных.

На этапе проектирования логической модели произведем нормализацию таблиц и приведем их к третьей нормальной форме.

Первая нормальная форма требует, чтобы каждое поле таблицы БД было

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

Вторая нормальная форма требует, чтобы все поля таблицы зависели от

первичного ключа, то есть, чтобы первичный ключ однозначно определял запись и не

был избыточен. Если же в какой-либо таблице имеется зависимость каких-нибудь не

ключевых полей от части первичного ключа, следует выделить их в отдельную таблицу,

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

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

Третья нормальная форма требует, чтобы в таблицах не имелось транзитивных

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

входящего в первичный ключ, не зависело от значения другого поля, также не входящего

в первичный ключ.

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

КЛИЕНТ

Фамилия	Имя	Отчество	Телефон
Иванов	Иван	Иванович	222-22-22

ЗАКАЗ

Дата заказа	Дата поставки	Информация
10.12.2010	21.12.2010	материал - сталь обивка - кожа

ТОВАР

Наименование	Цена	Производитель	Расчетный счет	Контактный телефон
Стул	12000	Томск Мебель	000002589743001420123	333-33-33

 

Поскольку один производитель может выпускать много товаров (т.е. единиц мебели, например стул, стол, диван), то неизбежно повторение в столбцах производитель расчетный счет, контактный телефон. Такая структура записи данных не подходит для реляционной базы данных и запись приведенной информации не соответствует требованиям первой нормальной формы, поскольку содержит повторяющуюся группу столбцов. Поэтому эту таблицу разделим на две: ТОВАР и ПРОИЗВОДИТЕЛЬ.

ТОВАР

Наименование	Цена
Стул	12000

ПРОИЗВОДИТЕЛЬ

Фирма	Расчетный счет	Контактный телефон
Томск Мебель	000002589743001420123	333-33-33

 

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

Первичный ключ - поле или набор полей, однозначно идентифицирующих запись.

• для таблицы КЛИЕНТ – это № клиента;
• для таблицы ЗАКАЗ – это № заказа;
• для таблицы ТОВАР – это № производителя.

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

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

• для таблицы ЗАКАЗ – это № клиента, № товара;
• для таблицы ТОВАР – это № товара;
• для таблицы ПРОИЗВОДИТЕЛЬ – это № производителя.

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

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

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

 

Рис. 4 Логическая модель

 

На «рис.4» связь между таблицами обозначены в виде стрелок с указателями:

• 1      М   - связь один-ко-многим;
• 1       1    - связь один-к-одному.

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

 

  2.3.  Построение физической модели данных

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

Перед построением физической модели мы должны определить какую СУБД мы будем использовать. Так как построение базы данных будет производиться нами компонентом Delphi - Database Desktop в формате таблиц Paradox, то и модель будем строить ориентированную на эту СУБД. Среди многочисленных особенностей Paradox выделяют уникальное сочетание необычайной простоты и прозрачности с огромными возможностями функционально завершенной системы управления данными.

Database Desktop - это редактор файлов баз данных dBASE и Paradox от фирмы Borland.

Создадим физическую модель наших данных в формате таблиц Paradox:

Рис.5 Физическая модель

В физической модели «Рис.5» обозначены типы данных для полей, выделены первичные ключи и те из них, которые служат для связи с внешними ключами, обозначены как «родительские». Связи  остались такими же, как и у логической модели. Ниже представим описание каждой создаваемой таблицы:

Таблица meb_client.dbf для размещения данных о клиентах салона.

Название поля (Fields name)	Наименование поля	Тип (Type)	Длина	Назначение
N_cli	№ клиента	I (Long Integer) целое число	целое	Поле для хранения номера клиента, является ключевым, т. к. содержит уникальную идентификацию записей и служит для точного разделения значений. Каждая запись имеет свой неповторяющийся номер.
Fam	Фамилия	A (Alpha) строковое поле	30	Поле для хранения фамилии клиента
Name	Имя	A (Alpha) строковое поле	30	Поле для хранения имени клиента
Otch	Отчество	A (Alpha) строковое поле	30	Поле для хранения отчества клиента
Tel	Телефон	A (Alpha) строковое поле	30	Поле для хранения номера телефона клиента

 

Таблица meb_zacaz.dbf для размещения данных о заказах салона.

Название поля (Fields name)	Наименование поля	Тип (Type)	Длина	Назначение
N_zac	№ заказа	+ (Autoincrement) целое число	При добавлении к таблице очередной записи в поле записывается число на единицу большее, чем находится в соответствующем поле последней добавленной записи	Поле для хранения номера заказа
N_cli	№ клиента	I (Long Integer) целое число	целое	Поле для хранения номера клиента
N_meb	№ мебели	I (Long Integer) целое число	целое	Поле для хранения номера товара
Dat_zac	Дата заказа	D (Date) дата	дд/мм/гггг	Поле для хранения даты заказа
Dat_post	Дата поставки	D (Date) дата	дд/мм/гггг	Поле для хранения даты поставки товара клиенту
Dop_info	Информация	A (Alpha) строковое поле	200	Поле для хранения информации о заказе

 

 

Название поля (Fields name)	Наименование поля	Тип (Type)	Длина	Назначение
N_meb	№ мебели	I (Long Integer) целое число	целое	Поле для хранения номера товара, является ключевым, т. к. содержит уникальную идентификацию записей и служит для точного разделения значений. Каждая запись имеет свой неповторяющийся номер.
Naimenovanie	Наименование товара (мебели)	A (Alpha) строковое поле	60	Поле для хранения названия товара (мебели)
Cena	Цена	$ (Money) число в денежном формате	целое	Поле для хранения цены товара (мебели)
N_pro	№ производителя	I (Long Integer) целое число	целое	Поле для хранения номера производителя