Создание Базы Данных Института

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

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

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

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

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

1.2 Характеристика реляционной модели  данных

     Основы  реляционной модели данных были впервые изложены в статье Е.Кодда в 1970 г. Эта работа послужила стимулом для большого количества статей и книг, в которых реляционная модель получила дальнейшее развитие. Наиболее распространенная трактовка реляционной модели данных принадлежит К.Дейту. Согласно Дейту, реляционная модель состоит из трех частей:

• структурной части;
• целостной части;
• манипуляционной части.

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

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

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

     Реляционная модель данных (РМД) некоторой предметной области представляет собой набор  отношений, изменяющихся во времени.

     При создании информационной системы совокупность отношений позволяет хранить данные об объектах предметной области и моделировать связи между ними. Элементы РМД и формы их представления приведены в таблице 1.

Таблица 1 – Элементы реляционной модели

     Отношение является важнейшим понятием и представляет собой двумерную таблицу, содержащую некоторые данные.

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

     Атрибуты представляют собой свойства, характеризующие сущность. Их наименования должны быть уникальными для конкретного типа сущности, но могут быть одинаковыми для различного типа сущностей (например, ЦВЕТ может быть определен для многих сущностей: СОБАКА, АВТОМОБИЛЬ, ДЫМ и т.д.). Атрибуты используются для определения того, какая информация должна быть собрана о сущности. В структуре таблицы каждый атрибут именуется и ему соответствует заголовок некоторого столбца таблицы.

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

     Кортеж  состоит из элементов, каждый из которых выбирается из соответствующего домена. Каждому кортежу соответствует строка таблицы. В общем случае порядок кортежей в отношении, как и в любом множестве, не определен. Однако в реляционных СУБД для удобства кортежи все же упорядочивают. Чаще всего для этого выбирают некоторый атрибут, по которому система автоматически сортирует кортежи по возрастанию или убыванию. Если пользователь не назначает атрибута упорядочения, система автоматически присваивает номер кортежам в порядке их ввода. Формально, если переставить атрибуты в отношении, то получается повое отношение. Однако в реляционных БД перестановка атрибутов не приводит к образованию нового отношения.

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

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

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

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

     Ключи обычно используют для достижения следующих целей:

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

     Пусть в отношении R1 имеется не ключевой атрибут А, значения которого являются значениями ключевого атрибута В другого отношения R2. Тогда говорят, что атрибут А отношения R1 есть внешний ключ. С помощью внешних ключей устанавливаются связи между отношениями. Реляционная модель накладывает на внешние ключи ограничение для обеспечения целостности данных, называемое ссылочной целостностью. Это означает, что каждому значению внешнего ключа должны соответствовать строки в связываемых отношениях.

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

     все строки таблицы должны быть уникальны, т.е. не может быть строк с одинаковыми  первичными ключами;

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

     все строки одной таблицы должны иметь одну структуру, соответствующую именам и типам столбцов;

     порядок размещения строк в таблице может  быть произвольным.

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

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

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

     Если  задаваемое таблицей отношение имеет  ключ, то считается, что таблица тоже имеет ключ, и ее называют ключевой или таблицей с ключевыми полями.

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

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

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

1.3 Этапы разработки базы данных

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

• реляционная модель данных - удобный способ представления данных предметной области;
• язык SQL - универсальный способ манипулирования такими данными.

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

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

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