Файл: Операции, производимые с данными (История развития баз данных).pdf

• целостной (все данные должны быть связаны, не должно быть ссылок на несуществующие в базе данные) [12,с.72].

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

В качестве значений полей в записях могут храниться некоторые числа, строки, картинки и т.д. Таблицы баз данных хранятся на жёстком диске (на локальном компьютере или на сервере баз данных – в зависимости от типа БД) [4,с.186].

Одной таблице соответствуют обычно несколько файлов – один основной и несколько вспомогательных.

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

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

1.3 Работа с базой данных

Одним из основных требований к СУБД является надежность хранения данных во внешней памяти. Под надежностью хранения понимается то, что СУБД должна быть в состоянии восстановить последнее согласованное состояние БД после любого аппаратного или программного сбоя[17,с.49].

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

Примерами программных сбоев могут быть: аварийное завершение работы СУБД (по причине ошибки в программе или в результате некоторого аппаратного сбоя) или аварийное завершение пользовательской программы, в результате чего некоторая транзакция остается незавершенной. Первую ситуацию можно рассматривать - как особый вид мягкого аппаратного сбоя; при возникновении последней требуется ликвидировать последствия только одной транзакции. Понятно, что в любом случае для восстановления БД нужно располагать некоторой дополнительной информацией[6,с.177].

---

Другими словами, поддержание надежности хранения данных в БД требует избыточности хранения данных, причем та часть данных, которая используется для восстановления, должна храниться особо надежно. Наиболее распространенным методом поддержания такой избыточной информации является ведение журнала изменений БД[8,с.53].

Журнал - это особая часть БД, недоступная пользователям СУБД и поддерживаемая с особой тщательностью (иногда поддерживаются две копии журнала, располагаемые на разных физических дисках), в которую поступают записи обо всех изменениях основной части БД. В разных СУБД изменения БД журнализируются на разных уровнях[12,с.144]: иногда запись в журнале соответствует некоторой логической операции изменения БД (например, операции удаления строки из таблицы реляционной БД), иногда - минимальной внутренней операции модификации страницы внешней памяти; в некоторых системах одновременно используются оба подхода. Во всех случаях придерживаются стратегии "упреждающей" записи в журнал (так называемого протокола Write Ahead Log - WAL). Грубо говоря, эта стратегия заключается в том, что запись об изменении любого объекта БД должна попасть во внешнюю память журнала раньше, чем измененный объект попадет во внешнюю память основной части БД. Известно, что если в СУБД корректно соблюдается протокол WAL, то с помощью журнала можно решить все проблемы восстановления БД после любого сбоя.

Самая простая ситуация восстановления - индивидуальный откат транзакции. Строго говоря, для этого не требуется общесистемный журнал изменений БД. Достаточно для каждой транзакции поддерживать локальный журнал операций модификации БД, выполненных в этой транзакции, и производить откат транзакции, путем выполнения обратных операций, следуя от конца локального журнала[2,с.76]. В некоторых СУБД так и делают, но в большинстве систем локальные журналы не поддерживают, а индивидуальный откат транзакции выполняют по общесистемному журналу, для чего все записи от одной транзакции связывают обратным списком (от конца к началу) [17,с.183]. При мягком сбое во внешней памяти основной части БД могут находиться объекты, модифицированные транзакциями, не закончившимися к моменту сбоя, и могут отсутствовать объекты, модифицированные транзакциями, которые к моменту сбоя успешно завершились (по причине использования буферов оперативной памяти, содержимое которых при мягком сбое пропадает) [11,с.177].

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

---

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

Конечно, для нормального восстановления БД после жесткого сбоя необходимо, чтобы журнал не пропал. Как уже отмечалось, к сохранности журнала во внешней памяти в СУБД предъявляются особо повышенные требования. Тогда восстановление БД состоит в том, что исходя из архивной копии, по журналу воспроизводится работа всех транзакций, которые закончились к моменту сбоя. В принципе, можно даже воспроизвести работу незавершенных транзакций и продолжить их работу после завершения восстановления. Однако в реальных системах это обычно не делается, поскольку процесс восстановления после жесткого сбоя является достаточно длительным[16,с.209].

Таким образом, в ходе написания первой главы курсовой работы было определено следующее. Ключи чрезвычайно полезны для связи таблиц. Записывая значения ключа в отведённые поля подчинённой таблицы и тем самым, задавая ссылку, обеспечиваем связь двух записей – записи в главной таблице и записи в подчинённой таблице. В одной записи подчинённой таблицы может находиться порядка нескольких ссылок на записи главной таблицы. Так, для работы с базами данных используются специальные языки, в целом называемые языками баз данных[15,с.43].

В ранних СУБД поддерживалось несколько специализированных по своим функциям языков. Чаще всего выделялись два языка: язык определения схемы БД (SDL - Schema Definition Language) и язык манипулирования данными (DML - Data Manipulation Language). SDL служил главным образом для определения логической структуры БД, т.е. той структуры БД, какой она представляется пользователям [9,с.96].

2. Практические аспекты применения операций, производимых с данными

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

---

Каждый столбец в таблице базы данных должен иметь имя и тип данных[16,с.283].

Рисунок 1 – Структура иерархической модели баз данных [12,с.83].

2.1 Проектирование базы данных

2.1.1 Создание таблиц с помощью SQL Server Management Studio

Введём имена столбцов, выберем типы данных и определим для каждого столбца, могут ли в нем присутствовать значения NULL. Определим также первичный ключ для каждой таблицы (Рис. 2 – Рис. 8).

Создадим SQL таблицу «Auto»

Рисунок 2 - Создание атрибутов таблицы «Auto»

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

CREATE TABLE [dbo].[Auto](

[ID] [int] IDENTITY(1,1) NOT NULL,

[ID_Tehnic] [int] NOT NULL,

[Name] [varchar](50) NOT NULL,

[Comments] [varchar](max) NOT NULL,

[ID_User] [int] NOT NULL,

CONSTRAINT [PK_Auto] PRIMARY KEY CLUSTERED

(

[ID] ASC

)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON,

ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]

) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]

GO

Создадим таблицу SQL «Comments»

Рисунок 3 - Создание атрибутов таблицы «Comments»

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

CREATE TABLE [dbo].[Comments](

[ID] [int] IDENTITY(1,1) NOT NULL,

[ID_User] [int] NOT NULL,

[Comments] [varchar](max) NULL,

[Rating] [int] NULL,

[ID_Zakaz] [int] NOT NULL,

[Like_dislike] [int] NOT NULL,

CONSTRAINT [PK_Comments] PRIMARY KEY CLUSTERED

(

[ID] ASC

)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]

) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]

GO

Создадим SQL таблицу «Report»

Рисунок 4 - Создание атрибутов таблицы «Report»

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

CREATE TABLE [dbo].[Report](

[ID] [int] IDENTITY(1,1) NOT NULL,

[ID_User] [int] NOT NULL,

[ID_Auto] [int] NOT NULL,

[Time] [datetime] NOT NULL,

[Activ] [int] NOT NULL,

[Cost] [int] NOT NULL,

CONSTRAINT [PK_Report] PRIMARY KEY CLUSTERED

(

[ID] ASC

)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]

) ON [PRIMARY]

GO

Создадим SQL таблицу «Tehnic»

Рисунок 5 - Создание атрибутов таблицы «Tehnic»

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

CREATE TABLE [dbo].[Tehnic](

[ID] [int] IDENTITY(1,1) NOT NULL,

[Name] [varchar](50) NOT NULL,

CONSTRAINT [PK_Tehnic] PRIMARY KEY CLUSTERED

---

(

[ID] ASC

)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]

) ON [PRIMARY]

GO

Создадим SQL таблицу «userr»

Рисунок 6 - Создание атрибутов таблицы «userr»

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

CREATE TABLE [dbo].[userr](

[ID] [int] IDENTITY(1,1) NOT NULL,

[name] [varchar](50) NOT NULL,

[Prodavec] [int] NOT NULL,

[Telefon] [nvarchar](50) NOT NULL,

[mail] [nvarchar](50) NOT NULL,

[Pasword] [char](10) NOT NULL,

[Rating] [int] NOT NULL,

[Activ] [int] NOT NULL,

CONSTRAINT [PK_user] PRIMARY KEY CLUSTERED

(

[ID] ASC

)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]

) ON [PRIMARY]

GO

Создадим SQL таблицу «Zakaz»

Рисунок 7 - Создание атрибутов таблицы «Zakaz»

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

CREATE TABLE [dbo].[Zakaz](

[ID] [int] IDENTITY(1,1) NOT NULL,

[ID_User] [int] NOT NULL,

[ID_Report] [int] NOT NULL,

[Date_IN] [datetime] NOT NULL,

[Date_Out] [datetime] NOT NULL,

CONSTRAINT [PK_Zakaz] PRIMARY KEY CLUSTERED

(

[ID] ASC

)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]

) ON [PRIMARY]

GO

Создадим SQL таблицу «Chat»

Рисунок 8 - Создание атрибутов таблицы «Chat»

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

CREATE TABLE [dbo].[Chat](

[ID] [int] IDENTITY(1,1) NOT NULL,

[ID_user1] [int] NOT NULL,

[ID_user2] [int] NOT NULL,

[Text] [varchar](max) NOT NULL,

[Time] [datetime] NOT NULL,

CONSTRAINT [PK_Chat] PRIMARY KEY CLUSTERED

(

[ID] ASC

)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]

) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]

GO

2.1.2 Создание логической диаграммы

Построим диаграмму базы данных и создадим связи между таблицами.

Рисунок 9 - Развёрнутая логическая диаграмма БД со связями

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

Таблица 1 – Объект «Comments»

Meaning	Designation	Example	Type
Уникальный идентификатор	ID	1	INT, NOT NULL, PRIMARY KEY
Ссылка на идентификатор пользователя	ID_User	1	INT, NOT NULL
Содержимое комментария	Comments	Исполнением заказа удовлетворен	TEXT, NULL
Оценка за заказ (0 - 10)	Rating	10	INT, NULL
Ссылка на идентификатор заказа	ID_Zakaz	1	INT, NOT NULL
Лайк или дизлайк(1 – лайк, 0 – дизлайк)	Like_dislike	1	INT, NOT NULL

---