Лекции по "Информатике"

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

 

Преимущества БД

1. Централизованное управление информацией целого предприятия.
2. Возможность сокращения избыточности данных.

3. Возможность устранения (до некоторой  степени) противоречивости.

     Противоречивость БД  будет иметь место тогда когда в БД имеется более одной записи об одном и том же факте и в этих записях информация отличается.

4. Возможность общего доступа к данным.

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

 

Независимость данных

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

В системах баз данных эта проблема решается с помощью СУБД. Независимость данных можно определить как иммунитет приложений к изменениям в структуре хранения и методах доступа к данным. В базе данных администратор должен иметь возможность изменять структуры хранения данных без необходимости переписывать имеющиеся прикладные программы.

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

Введем следующие понятия:

Хранимое поле – наименьшая единица хранимых данных (например, "Год рождения").

Хранимая запись – это набор связанных хранимых полей (например, "Ф.И.О.", "Год рождения", "Адрес").

Хранимый файл – набор всех хранимых записей одного типа.

Логическая запись – это запись в том виде, как ее представляет себе пользователь.

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

 

Архитектура клиент/сервер

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

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

 

Реляционные базы данных

К реляционным БД относятся такие, которые обладают двумя свойствами:

1. данные воспринимаются пользователем как таблицы;
2. В распоряжении пользователя имеются операторы для выборки данных из этих таблиц, а также для вставки новых данным, обновления и удаления имеющихся данных.

Рассмотрим простую систему, в которой две таблицы: "Студенты" и "Успеваемость".

 

Таблица "Студенты"

 

Номер зачетной книжки	Ф.И.О.	Серия паспорта	Номер паспорта
55500	Иванов Иван Петрович	02  04	645327
55800	Климов Андрей Иванович	02  03	673211
55865	Новиков Николай Юрьевич	02 04	554390

 

           Таблица "Успеваемость"

 

Номер зачетной книжки	Предмет	Учебный год	Семестр	Оценка
55500	Физика	2000/2001	1	5
55500	Математика	2000/2001	1	4
55800	Физика	2000/2001	1	4
55800	Физика	2000/2001	2	5

 

Строки таких таблиц называются записями, а столбцы – полями. На пересечении строк и столбцов должны находиться "атомарные" значения, которые нельзя разбить на какие-либо элементы без потери смысла.

В теории баз данных такие таблицы называются отношениями (relation) – поэтому и базы данных называются реляционными. При определении свойств таких отношений используется теория множеств.

 

Целостность

Одним из аспектов БД является понятие целостности данных. При вводе данных в БД часто приходится следовать различным ограничениям. В нашем случае это такие ограничения:

• номер зачетной книжки состоит из пяти цифр и не может быть отрицательным;
• номер семестра может принимать только два значения – 1 и 2;
• оценка может принимать только три значения – 3, 4 и 5.

 

Эти ограничения являются специфическими для нашей БД. Однако есть и ограничения, общие для всех БД. Это потенциальные и внешние ключи.

В таблице не может быть двух идентичных записей, то есть записи должны различаться между собой хотя бы по одному полю. Чтобы обеспечить уникальность каждой записи, используется понятие «ключ». Ключ – это уникальная метка, которая однозначно определяет каждую запись таблицы (например, автомобиль однозначно определяется своим номером).

 

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

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

Ключевое поле всегда должны стоять перед остальными полями таблицы!

 

Внешние ключи

Рассмотрим наши таблицы "Студенты" и "Успеваемость". Предположим, что в таблице "Студенты" нет записи с номером зачетной книжки 55900, тогда включать запись с таким номером зачетной книжки в таблицу "Успеваемость" не имело бы смысла. Таким образом, значения поля "Номер зачетной книжки" в таблице "Успеваемость" должны быть согласованы со значениями такого же поля в таблице "Студенты". Поле "Номер зачетной книжки" в таблице "Успеваемость" является примером того, что называется внешним ключом. Внешний ключ может быть составным, т.е. включать более одного поля. Внешний ключ не обязан быть уникальным. Проблема обеспечения того, чтобы БД не содержала неверных значений внешних ключей, известна как проблема ссылочной целостности. Первичный ключ – поле или группа полей, являющиеся уникальным идентификатором каждой записи в таблице. Внешний ключ – поле или группа полей таблицы, значения которых соответствуют значениям первичного ключа в другой связанной таблице. Таблица, связанная по первичному ключу, называется главной (ссылочной), а связанная по внешнему ключу – подчиненной (ссылающейся). Говорят, что "внешний ключ ссылается на потенциальный ключ в ссылочной (главной) таблице".

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

Правило ссылочной целостности: БД не должна содержать несогласованных значений внешних ключей.

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

Иногда применяются и другие подходы. Например, вместо удаления записей из ссылающейся таблицы просто заменяют значения полей, входящих во внешний ключ, так называемыми NULL-значениями. Это специальные значения, означающие "ничто", или отсутствие значения, они не совпадают со значением "нуль" или "пустая строка". NULL-значения применяются в БД и как значения по умолчанию, когда пользователь не ввел никакого значения. Первичные ключи не могут содержать NULL-значений, а альтернативные ключи – могут.

 

Улучшенная структура БД

Мы можем улучшить структуру нашей БД. Для этого мы создадим еще одну таблицу – "Учебные дисциплины".

 

Таблица " Учебные дисциплины"

Код учебной дисциплины	Наименование учебной дисциплины"
1	Физика
2	Математика
3	Технология программирования

 

Тогда в таблице "Успеваемость" можно вместо поля "Учебная дисциплина" ввести поле "Код учебной дисциплины". А при выборке информации из этой таблицы можно брать наименование дисциплины из нашей новой таблицы. В данном случае поле "Код учебной дисциплины" в таблице "Успеваемость" будет внешним ключом.

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

 

 

 

 

 

 

 

 

 

 

Таблица "Студенты"

 

Номер зачетной книжки	Ф.И.О.	Серия паспорта	Номер паспорта
55500	Иванов Иван Петрович	02  04	645327
55800	Климов Андрей Иванович	02  03	673211
55865	Новиков Николай Юрьевич	02 04	554390

 

           Таблица "Успеваемость"

 

Номер зачетной книжки	Код учебной дисциплины	Учебный год	Семестр	Оценка
55500	1	2000/2001	1	5
55500	2	2000/2001	1	4
55800	1	2000/2001	1	4
55800	1	2000/2001	2	5

Таблица " Учебные дисциплины"

Код учебной дисциплины	Наименование учебной дисциплины"
1	Физика
2	Математика
3	Технология программирования

 

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

Например, при проведении в банке оплаты за купленный товар: деньги снимаются со счета фирмы покупателя и зачисляются на счет фирмы-поставщика. В дано случае в транзакции участвуют таблицы:  «Остаток на счете», «Проводки» (операции). Выполняется 4 операции (команды) с таблицами БД:

1. В таблицу «Проводки» добавляется запись о снятии Х рублей со счета фирмы-покупателя.
2. Корректируется запись для фирмы-покупателя в таблице «Остаток на счете», т.е. остаток уменьшается на величину Х.
3. В таблицу «Проводки» добавляется запись о зачислении  Х рублей на счет фирмы-поставщика.
4. Корректируется запись для фирмы-поставщика в таблице «Остаток на счете», т.е. остаток увеличивается на величину Х.

Это пример транзакции, она должна выполняется либо полностью, либо не должна выполнятся вообще. Современные СУБД гарантируют такую обработку транзакций . (либо все – либо нечего, например транзакция на пол пути прервалась, например свет погас). В случае не удачного проведения транзакции СУБД производит так называемый откат транзакции. После чего транзакция выполняется снова.