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

(Реляционные базы данных.)
Большие корпоративные вычислительные центры используют сложные программные продукты для работы с базами данных. Но есть пользователи, кото- рые поддерживают информационные массивы средних размеров. И тем и другим необходимы программные продукты, которые помогали бы ориентироваться в со- ответствующих базах данных. Начнём с введения в реляционные базы данных и проектирование приложений в реляционном мире.
База данных – это организованное собрание данных, где данные хранятся с некоторым назначением. Простым примером неэлектронной базы данных явля- ется обычная библиотека, в которой хранятся книги, периодические издания и прочие документы.
Согласно нашему определению, база данных является организованным собранием данных. Реляционная же база данных организовывает данные в табли- цы и обеспечивает операции извлечения , генерирующие новые таблицы из уже имеющихся. В результате пользователь видит всю базу данных в виде таблиц. Нам необходим некий способ взаимодействия с базой данных. Нужно определять таблицы, а также извлекать, добавлять и удалять данные. SQL (Structure Query Language – язык структурированных запросов) является компьютерным языком, используемым для выражения операций с базой данных, организованной в реляционной форме. SQL является принятым в отрасли стандартом языка, на котором говорит большинство программистов баз данных. Вообще, базы данных существуют для того, чтобы люди могли с ними взаимодействовать. В случае электронных баз данных взаимодействие происходит не непосредственно с базой данных, а косвенно – с помощью программного обеспечения.
Область, в которой развитие баз данных имело особо взрывной характер – это разработка приложений для Интернет. База данных сервера может поддерживать многие важные функции в Интернете. Фактически, любое содержание веб – страниц может управляться базой данных.Вот как веб – страница обычно взаимодействует с базой данных. База данных находится на нашем веб – сервере или другой машине, с которой наш сервер может обмениваться данными. Мы помещаем на веб – страницу форму, в которую пользователь вводит свой запрос или данные, которые нужно передать. После передачи формы на сервер последний запускает написанную нами программу, которая извлекает переданные пользователем данные. Эти программы делаются чаще всего в виде CGI – сценариев или серверных приложениий на Java. Теперь программа знает, какие данные нужны пользователю или что он хочет внести в базу данных. Программа формирует команду SQL для выборки или изменения данных, а база данных делает всё остальное. Результаты, получаемые от базы данных, программа может оформить в виде новой HTML – странички и отправить обратно пользователю.
Проектирование баз данных
Проектирование баз данных – серьёзный вопрос. И здесь необходимо определить следующие термины: - сущность это важная вещь или объект сведение о котором нужно сохранить.
Сущность – это отличимый объект, где объект, о котором идёт речь, может быть настолько конкретным или абстрактным, насколько нам нравится.
Сведения о сущностях имеют вид атрибутов и/или связей. Если некий кандитат на то, чтобы быть сущностью, не имеет атрибутов или связей, то в действительности он не является сущностью. - связью называется ассоциирование двух или более сущностей. Примерами связей является зачисление служащих в отделы (связь “многие – к одной”) и поставка деталей поставщикам (связь “многие – ко многим”). - атрибут (свойство) – это однозначный факт о некоторой сущности, то есть данные о сущности, которые нужно сохранить. Укаждой сущности ноль или более атрибутов.И каждый атрибут описывает в точности одну сущность. Каждый экземпляр сущности ( строка таблицы ) имеет в точности одно значение, возможно, равное NULL. Термин “проектирование баз данных” используется в смысле логического проектирования. Это не значит, что физическое проектирование не считается столь важным. Дело в том, что оно представляет собой самостоятельную задачу, которой можно и нужно заниматься отдельно после того, как выполнено логическое проектирование.
Будем различать сущности трёх основных классов: стержневые, ассоциативные и характеристические. Стержневая сущность – это независимая сущность ( ей свойственно независимое существование ). Ассоциативная сущность рассматривается как связь между двумя или более другими сущностями вида “многие – ко – многим”. Характеристическая – это такая, цель которой состоит в описании или уточнении некоторой другой сущности. Ассоциации и характеристики не являются независимыми , так как они предполагают существование некоторой другой сущности или сущностей, которые будут ассоциироваться или “характеризоваться”. Основой приведённой выше классификационной схемы служит тот факт, что связи между сущностями можно единственным образом разделить на две различные категории, а именно: связи вида “многие – ко – многим”, которые мы называем ассоциациями, и связи вида “многие – к – одной” , которые мы называем обозначениями. Ассоциации рассматриваются как полноправные сущности: они могут обладать свойствами , могут участвовать в других ассоциациях и так далее, точно также, как стержневые сущности. Вместо этого свойства обозначения в большинстве случаев считаются свойствами обозначаемой сущности.
Существуют такие понятия , как первичные и внешние ключи, а также такое понятие как нормализация. Для большего понимания рассмотрим конкретную базу данных. В нашем примере база данных будет ссылаться на ряд объектов – компакт диски (CD), название CD, название группы и название фирмы звукозаписи. На этом примере станет ясно, что есть сущность, а что – атрибут. Мы определяем несколько видов данных, относящихся к каждому CD, и без которых описать CD невозможно. Поэтому CD является одним из тех объектов, которые мы хотим описать, и, следовательно, является сущностью. По общепринятому соглашению об именовании сущностей имя сущности должно быть в единственном числе. Поэтому таблицу назовём “CD”, а не “CDs”. | CD | | |
Ниже – таблица с атрибутами CD, которые описывают CD:
| CD | | CD Title | | Band Name | | Record name | | Songs |
Эта диаграмма проста, но ещё не закончена. А именно – целью моделирования является устранение избыточности с помощью приёма, называемого нормализацией. Необходимо нормализовать нашу базу данных. Задача нормализации – устранить из базы данных некоторые нежелательные характеристики. В частности, ставится задача устранить некоторые виды избыточности данных и благодаря этому избежать аномалий при изменении данных. Аномалии изменения данных – это сложности при операциях вставки, изменения и удаления данных, возникающие из-за структуры базы данных. В результате нормализации модель данных становится более ясной.
Первая нормальная форма.
Общее понятие нормализации подразделяется на несколько “нормальных” форм” . Говорят, что сущность находится в первой нормальной форме, когда все её атрибуты имеют единственное значение. Если в каком-либо атрибуте есть повторяющееся значение, то сущность не находится в первой нормальной форме (1NF). В нашем случае в атрибуте Song есть повторяющиеся значения. Следовательно, Song – это ещё один объект, о котором мы собираем данные, и, возможно, он является сущностью. | CD | | CD Title | | Record Label | | Band Name | | Song | | Song Name | | Song Length|
Теперь у нас появилась модель данных с двумя сущностями в 1NF. Но у нас ещё не указаны способы связи для CD и Song. Прежде чем обсудить связи, мы должны применить к сущностям ещё одно правило. У каждой сущности должен быть однозначный идентификатор ID. Это такой атрибут сущности, к которому применимы следующие правила: - он уникален для каждого экземпляра сущности - для каждого экземпляра сущности он имеет значение, отличное от NULL в течение всего срока существования экземпляра - его значение не меняется в течение всего срока существования экземпляра Выбор идентификатора существенен, так как он используется для модеоирования связей. Ниже к каждой из нашей сущностей добавлен уникальный идентификатор:
| CD | | CD_ID | | CD Title | | Record Label| | Band name | | Song | | Song_ID | | Song Name | | Song Length |
Идентификаторы наших сущностей позволяют моделировать их связи.Связь описывает бинарное отношение между двумя сущностями. Связь может также существовать внутри одной сущности. Такая связь называется рекурсивной. Каждая сущность, участвующая в связи, описывает другую и описывается ею. Каждая строка связи имеет два составляющих – имя и степень. Степень, называемая также кардинальным числом, показывает, сколько экземпляров описываемой сущности должны описывать один экземпляр описываемой сущности. Степень выражается с помощью двух разных значений – “один – к – одному” и “один – ко - многим”. Для нашего примера это будет:
| CD | |CD_ID | |CD Title | |Record Label | |Band Name |
| Song | | Song_ID | | Song Name | | Song Length|
Вторая нормальная форма.
Теперь скажем о второй нормальной форме. Говорят, что сущность находится во второй нормальной форме, если она уже находится в первой нормальной форме, и каждый неидентифицирующий атрибут зависит от всего уникального идентификатора сущности. Если некий атрибут не зависит полностью от уникального идентификатора сущности, значит, он внесён ошибочно и должен быть удалён. Нормализовать такой атрибут можно либо найдя сущность, к которой он относится, либо создав новую сущность, в которую он должен быть помещён. Для нашего примера имеем следующее. Название группы – Band Name – может быть для двух разных CD. Следовательно, Band Name не полностью зависит от идентификатора CD_ID. Следовательно, Band Name должно быть частью новой сущности, связанной с CD. У нас будет тогда новая модель: | Song | |Song_ID | |Song Name | |Song Length |
| Artist | |Artist_ID | |Artist Name | | CD | |CD_ID | |CD Title | |Record Label |
Но лучше, если будет такой вид: | Song | |Song_ID | |Song Name | |Song Length |
| Artist | |Artist_ID | |Artist Name | | CD | |CD_ID | |CD Title | |Record Label |
Эта модель лучше, так как у каждого Artist есть одна или много Song, а каждая Song исполняется одним и только одним Artist.