СРС / 1 - Создание БД

6

Проектирование базы данных с использованием ER-технологии

Теоретические сведения

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

Разработка логической модели с использованием ER-технологии предполагает выполнение следующих шагов:

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

2. анализ связей и определение их характеристик – степени связи, мощности и класса принадлежности;

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

4. подготовка списка всех неключевых атрибутов и распределение этих атрибутов по предварительным отношениям;

5. проверка нахождения всех полученных отношений в нормальной форме Бойса-Кодда;

6. построение модели данных.

Пример выполнения работы

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

• тематические каталоги, по которым сгруппированы книги;

• предлагаемые книги (название, автор, год издания, цена, имеющееся на складе количество);

• зарегистрированные покупатели (имя, отчество, фамилия, телефон, адрес электронной почты, статус – авторизованный, неавторизованный, заблокированный, активный с хорошей кредитной историей);

• покупки, совершенные в магазине (время совершения покупки, число приобретенных экземпляров книги).

Логическая модель данных предметной области в стандарте IDEF1X представлена на рис. 1. Выделены сущности КАТАЛОГ, КНИГА, КЛИЕНТ, ЗАКАЗ, между которыми установлены неидентифицирующие связи мощностью oдин-ко-многим, определяемые спецификой предметной области.

Рис. 1. Логическая модель данных предметной области

Физическая модель данных предметной области в стандарте IDEF1X для целевой СУБД MS SQL Server представлена на рис. 2.

Рис. 2. Физическая модель предметной области

База данных Book состоит из четырех таблиц:

• Catalogs – список тематических каталогов;

• Books – список предлагаемых книг;

• Users – список зарегистрированных пользователей магазина;

• Orders – список заказов (осуществленных сделок).

Таблица Catalogs состоит из двух полей:

• cat_ID – уникальный код каталога;

• cat_name – имя каталога.

Оба поля должны быть снабжены атрибутом not null, поскольку неопределенное значение для них недо­пустимо.

Таблица Books состоит из семи полей:

• book_ID – уникальный код книги;

• b_name – название книги;

• b_author – автор книги;

• b_year – год издания;

• b_price – цена книги;

• b_count – количество книг на складе;

• b_cat_ID – код каталога из таблицы Catalogs.

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

Поле b_cat_ID устанавливает связь между таблицами Catalogs и Books. Это поле должно быть объявлено как внешний ключ (FK) с правилом каскадного удаления и обновления. Обновление таблицы Catalogs вызовет автоматическое обновление таблицы Books. Удаление каталога в таблице Catalogs приведет к автоматическому удалению всех записей в таблице Books, соответствующих каталогу.

Таблица Users состоит из семи полей:

• user_ID – уникальный код покупателя;

• u_name – имя покупателя;

• u_patronymic – отчество покупателя;

• u_surname – фамилия покупателя;

• u_phone – телефон покупателя (если есть);

• u_email – e-mail покупателя (если есть);

• u_status – статус покупателя.

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

• active – авторизованный покупатель, который может осуществлять покупки через Интернет;

• passive – неавторизованный покупатель (значение по умолчанию), который осуществил процедуру регистрации, но не подтвердил ее и пока не может осуществлять покупки через Интернет, ему доступны каталоги для просмотра;

• lock – заблокированный покупатель, не может осуществлять покупки и просматривать каталоги магазина;

• gold – активный покупатель с хорошей кредитной историей, которому предоставляется скидка при следующих покупках в магазине.

Поля u_phone и u_email могут принимать неопределенные значения null. Остальные поля должны получить атрибут not null.

Таблица Orders вклю­чает пять полей:

• order_ID – уникальный номер сделки;

• o_user_ID – номер пользователя из таблицы Users;

• o_book_ID – номер товарной позиции из таблицы Books;

• o_time – дата и время совершения сделки;

• o_number – количество приобретенных книг.

Поля таблицы Orders должны быть снабжены атрибутом not null, т. к. при совершении покупки вся информация должна быть занесена в таблицу.

В таблице Orders устанавливается связь с таблицами Users (за счет поля o_user_id) и Books (за счет поля o_book_id). Эти поля объявлены как внешние ключи (FK) с правилом каскадного удаления и обновления. Обновление таблиц Users и Books приведет к автоматическому обновлению таблицы Orders. Удаление любого пользователя в таблице Users приведет к автоматическому удалению всех записей в таблице Orders, соответствующих этому пользователю. Удаление любой книги в таблице Books приведет к автоматическому удалению всех записей в таблице Orders, ссылающихся на эту книгу.

/* Создание базы данных Book */

USE master;

GO

IF DB_ID('Book') IS NOT NULL

DROP DATABASE Book;

GO

CREATE DATABASE Book

ON PRIMARY (NAME = Book_dat, FILENAME = 'E:\Book\book.mdf',

SIZE = 5 MB, MAXSIZE = UNLIMITED,

FILEGROWTH = 1 MB )

LOG ON (NAME = Book_log, FILENAME = 'E:\Book\book.ldf',

SIZE = 1 MB , MAXSIZE = 30 MB,

FILEGROWTH = 1 MB )

COLLATE Cyrillic_General_CI_AS;

GO

Скрипт создает обычную (неавтономную) базу данных с логическим именем Book. Файл данных и файл журнала транзакций располагаются на диске E: в каталоге Book. На диске каталог с этим именем уже должен существовать. Файлы book.mdf и book.ldf должны отсутствовать в указанном каталоге.

База данных содержит только первичную файловую группу. Для файла данных установлен начальный размер 5 Мбайт, приращение – 1 Мбайт, максимальный размер не ограничен, т. е. файл может расти до исчерпания объема дискового пространства или до 16 Гбайт. Начальный размер файла журнала транзакций – 1 Мбайт, максимальный – 30 Мбайт, а квант увеличения размера – 1 Мбайт.

Для базы данных задан порядок сортировки Cyrillic_General_CI_AS.

/* Создание таблицы Catalogs */

USE Book;

GO

IF EXISTS (SELECT * FROM sys.tables WHERE NAME = 'Catalogs')

DROP TABLE Catalogs;

CREATE TABLE Catalogs

(cat_ID INT NOT NULL,

cat_name VARCHAR(20) NOT NULL,

CONSTRAINT PK_Catalogs PRIMARY KEY (cat_ID) ) ;

GO

/* Создание таблицы Books */

USE Book;

GO

IF EXISTS (SELECT * FROM sys.tables WHERE NAME = 'Books')

DROP TABLE Books;

CREATE TABLE Books

( book_ID int NOT NULL,

b_name varchar(100) NOT NULL,

b_author varchar(100) NOT NULL,

b_year int NOT NULL,

b_price money NOT NULL DEFAULT 0.00,

b_count int NOT NULL DEFAULT 0,

b_cat_ID int NOT NULL,

CONSTRAINT PK_Books PRIMARY KEY (book_ID),

CONSTRAINT FK_Books_Catalogs

FOREIGN KEY (b_cat_ID) REFERENCES Catalogs (cat_ID)

ON UPDATE CASCADE ON DELETE CASCADE );

GO

/* Создание таблицы Users */

USE Book;

GO

IF EXISTS (SELECT * FROM sys.tables WHERE NAME = 'Users')

DROP TABLE Users;

CREATE TABLE Users

( user_ID int NOT NULL,

u_name varchar(20) NOT NULL,

u_patronymic varchar(20) NOT NULL,

u_surname varchar(20) NOT NULL,

u_phone varchar(15),

u_email varchar(20),

u_status varchar(10) NOT NULL,

CONSTRAINT PK_Users PRIMARY KEY (user_ID),

CONSTRAINT CH_Users CHECK( u_status IN ('gold', 'lock', 'passive', 'active')) );

GO

/* Создание таблицы Orders */

USE Book;

GO

IF EXISTS (SELECT * FROM sys.tables WHERE NAME = 'Orders')

DROP TABLE Orders;

CREATE TABLE Orders

( order_ID Int NOT NULL,

o_user_ID int NOT NULL,

o_book_ID int NOT NULL,

o_time datetime NOT NULL,

o_number int NOT NULL DEFAULT 0,

CONSTRAINT PK_Orders PRIMARY KEY (order_ID),

CONSTRAINT FK_Orders_Books

FOREIGN KEY (o_book_ID) REFERENCES Books (book_ID)

ON UPDATE CASCADE ON DELETE CASCADE ,

CONSTRAINT FK_Orders_Users

FOREIGN KEY (o_user_ID) REFERENCES Users (user_ID)

ON UPDATE CASCADE ON DELETE CASCADE );

GO