Графические нотации, применяемые в проектировании БД

Графические нотации, применяемые в проектировании БД

В проектировании баз данных принято использовать графические нотации. Наиболее известные нотации:Чена, Crow’sFoot,IDEF1x, UML.

Нотация Чена

В данной нотации сущность представляет собой множество экземпляров реальных или абстрактных объектов (людей, событий, состояний, идей, предметов и т.п.), обладающих общими атрибутами или характеристиками. Любой объект системы может быть представлен только одной сущностью, которая должна быть уникально идентифицирована. При этом имя сущности должно отражать тип или класс объекта, а не его конкретный экземпляр (например, Аэропорт, а не Внуково)[4].

Отношение в самом общем виде представляет собой связь между двумя и более сущностями. Именование отношения осуществляется с помощью грамматического оборота глагола (имеет, определяет, может владеть и т.п.).

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

1. обеспечение хранения информации в единственном месте (даже если она используется в различных комбинациях);

2. использование этой информации различными приложениями.

Основные элементы, используемые при построении ИЛМ (информационно-логической модели) по нотации Ченапредставлены в таблице 1.

 

Таблица 1- Основные элементы в нотации Чена

Элемент диаграммы	Обозначает
1	2
имя	Независимая сущность
имя	Зависимая сущность
имя	Родительская сущность в иерархической связи
	связь
	Идентифицирующая связь
	Атрибут
	Первичный ключ (внешний ключ с одной чертой)

 

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

 

Рисунок 1.

2 Нотация Crow ’ sFoot (Мартина)

Список атрибутов приводится внутри прямоугольника, обозначающего сущность. Ключевые атрибуты подчеркиваются. Связи изображаются линиями, соединяющими сущности, вид линии в месте соединения с сущностью определяет кардинальность связи[5].

Основные элементы которой приведены в таблице 2.

 

Таблица 2 - Основные элементы нотаций Мартина

Элемент диаграммы	Обозначает
имя	Независимая сущность
имя	Зависимая сущность
имя	Родительская сущность в иерархической связи

Таблица 3- Кардинальность связи в нотациях Мартина

Обозначение	Кардинальность
	нет
	1,1
	0,1
	M,N
	0,N
	1,N

 

 

Нотация IDEF 1 x

Сущность в IDEF1X описывает собой совокупность или набор экземпляров похожих по свойствам, но однозначно отличаемых друг от друга по одному или нескольким признакам. Каждый экземпляр является реализацией сущности. Таким образом, сущность в IDEF1X описывает конкретный набор экземпляров реального мира[6].

Таблица 4 - Обозначения сущностей:

Элемент диаграммы	Обозначает
	Независимая сущность
	Зависимая сущность

 

Таблица 5 - Обозначение связей:

Обозначение	Обозначает
	1,1
	0,М
Z	0,1
P	1,M
N	Ровно N (N – произвольное число)

 

Нотация UML

Унифицированный язык моделирования (UML) – это набор структур и методик для моделирования и проектирования объектно-ориентированных программ (ООП) и приложений. UML – это одновременно и методология разработки систем ООП, и набор инструментов для разработки таких систем[2].

На рисунке 2 приведено UML-представление структур. Каждая сущность представлена классом сущностей, который изображен в виде прямоугольника с 3 сегментами. В верхнем сегменте указано имя сущности. Во втором перечислены имена атрибутов сущности, а в третьем описаны ограничения и методы (программные процедуры), относящиеся к данной сущности.

Рисунок 2. Представление различных типов связей в UML:а – связь 1:1; б – связь 1:N; в – N:M

 

ER -модель

Построение модели торгового предприятия в нотации Чена (рисунок 2).

Рисунок 2. Нотация Чена

 

Построение модели базы данных торгового предприятия в нотации Crow’sFoot(Мартина)(Рисунок 3).

Рисунок 3. Нотация Crow’sFoot

 

Построение модели базы данных торгового предприятия в нотации IDEF1x (рисунок 4).

 

Рисунок 4. Нотация IDEF1x

 

Построение модели базы данных в нотации UML(рисунок 5)

Рисунок 5. Нотация UML

Логическое проектирование

Физическое проектирование

По построенным схемам создаются таблицы в конкретной СУБД. В данном случае это Oracle. Дабы упростить процесс переноса базы данных в СУБД генерируется скрипт при помощи программы AllFusionERwinDataModeler.На Листинге 1 представлен сгенерированный скрипт базы данных торгового предприятия, который может быть использован в среде OracleApplicationExpress.

Листинг 1.

CREATE TABLE Clients

(

ID_client       INTEGER NOT NULL,

Client_nameVARCHAR2(100) NULL,

Client_addressVARCHAR2(200) NULL,

Phone_numberVARCHAR2(50) NULL

);

ALTER TABLE Clients

ADD CONSTRAINT XPKClients PRIMARY KEY (ID_client);

CREATE TABLE Departments

(

ID_department   INTEGER NOT NULL,

Dep_nameVARCHAR2(100) NULL,

Description     VARCHAR2(200) NULL

);

ALTER TABLE Departments

ADD CONSTRAINT XPKDepartments PRIMARY KEY (ID_department);

CREATE TABLE Emploees

(

ID_emploee      INTEGER NOT NULL,

FIO             VARCHAR2(100) NULL,

Address         VARCHAR2(200) NULL,

Date_birth      DATE NULL,

Salary          INTEGER NULL,

ID_department   INTEGER NULL,

ID_post         INTEGER NULL

);

ALTER TABLE Emploees

ADD CONSTRAINT XPKEmploees PRIMARY KEY (ID_emploee);

CREATE TABLE Orders

(

ID_order        INTEGER NOT NULL,

Order_date      DATE NULL,

ID_emploee      INTEGER NULL,

ID_client       INTEGER NULL

);

ALTER TABLE Orders

ADD CONSTRAINT XPKOrders PRIMARY KEY (ID_order);

CREATE TABLE Posts

(

ID_post         INTEGER NOT NULL,

Post_nameVARCHAR2(100) NULL,

Description     VARCHAR2(200) NULL

);

ALTER TABLE Posts

ADD CONSTRAINT XPKPosts PRIMARY KEY (ID_post);

CREATE TABLE Product_group

(

Vendor_code     INTEGER NOT NULL,

Group_name      INTEGER NULL

);

CREATE UNIQUE INDEX XPKProduct_group ON Product_group

(Vendor_code ASC);

ALTER TABLE Product_group

ADD CONSTRAINT XPKProduct_group PRIMARY KEY (Vendor_code);

CREATE TABLE Products

(

ID_product      INTEGER NOT NULL,

Product_nameVARCHAR2(100) NULL,

Price           INTEGER NULL,

Storage         INTEGER NULL,

Vendor_code     INTEGER NULL,

ID_supply       INTEGER NULL

);

ALTER TABLE Products

ADD CONSTRAINT XPKProducts PRIMARY KEY (ID_product);

CREATE TABLE Providers

(

ID_provider     INTEGER NOT NULL,

Provider_nameVARCHAR2(100) NULL,

Provider_addressVARCHAR2(200) NULL,

Phone_numberVARCHAR2(50) NULL

);

ALTER TABLE Providers

ADD CONSTRAINT XPKProviders PRIMARY KEY (ID_provider);

CREATE TABLE Sales

(

ID_sale         INTEGER NOT NULL,

Quantity        INTEGER NULL,

ID_product      INTEGER NULL,

ID_order        INTEGER NULL

);

ALTER TABLE Sales

ADD CONSTRAINT XPKSales PRIMARY KEY (ID_sale);

CREATE TABLE Supply

(

ID_supply       INTEGER NOT NULL,

Supply_date     DATE NULL,

ID_provider     INTEGER NULL

);

ALTER TABLE Supply

ADD CONSTRAINT XPKSupply PRIMARY KEY (ID_supply);

ALTER TABLE Emploees

ADD (CONSTRAINT R_1 FOREIGN KEY (ID_department) REFERENCES Departments (ID_department) ON DELETE SET NULL);

ALTER TABLE Emploees

ADD (CONSTRAINT R_2 FOREIGN KEY (ID_post) REFERENCES Posts (ID_post) ON DELETE SET NULL);

ALTER TABLE Orders

ADD (CONSTRAINT R_3 FOREIGN KEY (ID_emploee) REFERENCES Emploees (ID_emploee) ON DELETE SET NULL);

ALTER TABLE Orders

ADD (CONSTRAINT R_4 FOREIGN KEY (ID_client) REFERENCES Clients (ID_client) ON DELETE SET NULL);

ALTER TABLE Products

ADD (CONSTRAINT R_5 FOREIGN KEY (Vendor_code) REFERENCES Product_group (Vendor_code) ON DELETE SET NULL);

ALTER TABLE Products

ADD (CONSTRAINT R_7 FOREIGN KEY (ID_supply) REFERENCES Supply (ID_supply) ON DELETE SET NULL);

ALTER TABLE Sales

ADD (CONSTRAINT R_8 FOREIGN KEY (ID_product) REFERENCES Products (ID_product) ON DELETE SET NULL);

ALTER TABLE Sales

ADD (CONSTRAINT R_9 FOREIGN KEY (ID_order) REFERENCES Orders (ID_order) ON DELETE SET NULL);

ALTER TABLE Supply

ADD (CONSTRAINT R_6 FOREIGN KEY (ID_provider) REFERENCES Providers (ID_provider) ON DELETE SET NULL);

 

Определение требований к операционной обстановке

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

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

где li – длина записи в i-й таблице (в байтах), Ni – примерное (максимально возможное) количество записей в i-й таблице, Na – количество записей в архиве i-й таблицы. Коэффициент 2 перед суммой нужен для того, чтобы выделить память для хранения индексов, промежуточных данных, для выполнения объёмных операций (например, сортировки) и т.п.

Из описания предметной области известно, что в штате предприятия 1000 сотрудников, 7 поставщиков, 20 клиентов. Будем считать, что в текущем году:

· На предприятии 10 отделов (по 0,1К);

· Количество товаров порядка 2000 наименований (по 0.2К);

· В день поступает в среднем порядка 200 экземпляров по каждому наименованию товара;

· Устаревшие данные переводятся в архив.

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

M = 2(1000*0,2+10*0.1+2000*0.2+200*0.2+7*0.1+20*0.2) ≈1250 К ≈ 1,2 М,

Объём памяти будет увеличиваться ежегодно на столько же при сохранении объёма работы[3].

 

Графические нотации, применяемые в проектировании БД

В проектировании баз данных принято использовать графические нотации. Наиболее известные нотации:Чена, Crow’sFoot,IDEF1x, UML.

Нотация Чена

В данной нотации сущность представляет собой множество экземпляров реальных или абстрактных объектов (людей, событий, состояний, идей, предметов и т.п.), обладающих общими атрибутами или характеристиками. Любой объект системы может быть представлен только одной сущностью, которая должна быть уникально идентифицирована. При этом имя сущности должно отражать тип или класс объекта, а не его конкретный экземпляр (например, Аэропорт, а не Внуково)[4].

Отношение в самом общем виде представляет собой связь между двумя и более сущностями. Именование отношения осуществляется с помощью грамматического оборота глагола (имеет, определяет, может владеть и т.п.).

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

1. обеспечение хранения информации в единственном месте (даже если она используется в различных комбинациях);

2. использование этой информации различными приложениями.

Основные элементы, используемые при построении ИЛМ (информационно-логической модели) по нотации Ченапредставлены в таблице 1.

 

Таблица 1- Основные элементы в нотации Чена

Элемент диаграммы	Обозначает
1	2
имя	Независимая сущность
имя	Зависимая сущность
имя	Родительская сущность в иерархической связи
	связь
	Идентифицирующая связь
	Атрибут
	Первичный ключ (внешний ключ с одной чертой)

 

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

 

Рисунок 1.

2 Нотация Crow ’ sFoot (Мартина)

Список атрибутов приводится внутри прямоугольника, обозначающего сущность. Ключевые атрибуты подчеркиваются. Связи изображаются линиями, соединяющими сущности, вид линии в месте соединения с сущностью определяет кардинальность связи[5].

Основные элементы которой приведены в таблице 2.

 

Таблица 2 - Основные элементы нотаций Мартина

Элемент диаграммы	Обозначает
имя	Независимая сущность
имя	Зависимая сущность
имя	Родительская сущность в иерархической связи

Таблица 3- Кардинальность связи в нотациях Мартина

Обозначение	Кардинальность
	нет
	1,1
	0,1
	M,N
	0,N
	1,N

 

 

Нотация IDEF 1 x

Сущность в IDEF1X описывает собой совокупность или набор экземпляров похожих по свойствам, но однозначно отличаемых друг от друга по одному или нескольким признакам. Каждый экземпляр является реализацией сущности. Таким образом, сущность в IDEF1X описывает конкретный набор экземпляров реального мира[6].

Таблица 4 - Обозначения сущностей:

Элемент диаграммы	Обозначает
	Независимая сущность
	Зависимая сущность

 

Таблица 5 - Обозначение связей:

Обозначение	Обозначает
	1,1
	0,М
Z	0,1
P	1,M
N	Ровно N (N – произвольное число)

 

Нотация UML

Унифицированный язык моделирования (UML) – это набор структур и методик для моделирования и проектирования объектно-ориентированных программ (ООП) и приложений. UML – это одновременно и методология разработки систем ООП, и набор инструментов для разработки таких систем[2].

На рисунке 2 приведено UML-представление структур. Каждая сущность представлена классом сущностей, который изображен в виде прямоугольника с 3 сегментами. В верхнем сегменте указано имя сущности. Во втором перечислены имена атрибутов сущности, а в третьем описаны ограничения и методы (программные процедуры), относящиеся к данной сущности.

Рисунок 2. Представление различных типов связей в UML:а – связь 1:1; б – связь 1:N; в – N:M