Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
ЭЛЕКТРОННЫЙ КОНСПЕКТ ЛЕКЦИЙ
ПО ДИСЦЕПЛИНЕ БАЗЫ ДАННЫХ.
База данных (БД) — это поименованная совокупность дан ных, организованных по определенным правилам, предусмат ривающим общие принципы описания, хранения, манипули рования данными, независимо от прикладных программ.
Основными функциями БД являются:
В операционных системах, в среде которых функциониру ет база данных, специальных средств для создания и обработ ки БД не предусмотрено. Поэтому необходим комплекс про грамм, кото рый бы обеспечивал автоматизацию функций БД; этот комплекс называется системой управления базой данных (СУБД) и представляет собой сово купность программ и языковых средств, предназначенных для создания, ведения и ис пользования БД. СУБД — это пакет прикладных программ, рас ширяющих возможности операци онной системы по обработке БД.
Описание предметной области, выполненное без ориентации на используемые в дальнейшем программные и технические средства, называется инфологической моделью предметной области. Такой информацией являются ведения о классах объектов предметной области и их количеств в каждом классе, о фиксируемых свойствах этих объектов, о связях между ними, динамике их изменения. Инфологическая модель служит связующим звеном между специалистами предметной области и проектировщиками БД.
Модель данных логического уровня, СУБД, называют даталогической моделью. Эта модель представляет собой отображение логических связей между элементами данных безотносительно к их содержанию и среде хранения. Даталогическая модель строится с учетом ограничений конкретной СУБД. При построении даталогической модели учитываются особенности отображаемой предметной области. База данных предполагает интегрированное и взаимосвязанное хранение данных, поэтому для проектирования данной модели необходимо иметь соответствующее описание предметной области.
В процессе развития теории и практического использования баз данных, а также средств вычислительной техники создавались СУБД, поддерживающие различные даталогические модели. Сначала стали использовать иерархические даталогические модели. Иерархические БД состоят из упорядоченного набора деревьев; более точно, из упорядоченного набора нескольких экземпляров одного типа дерева. Тип дерева состоит из одного “ корневого” типа записи и упорядоченного набора из нуля или более типов поддеревьев (каждый из которых является некоторым типом дерева). Тип дерева в целом представляет собой иерархически организованный набор типов записи. Пример типа дерева приведен на рис.9.
Рис. 9. Иерархическая модель данных.
Здесь Отдел является предком для Начальника и Сотрудники, а Начальник и Сотрудники – потомки отдела. Между типами записи поддерживаются связи. Никакой потомок не может существовать без своего родителя, причем предок должен быть один.
Простота организации, наличие заранее заданных связей между сущностями, сходство с физическими моделями данных позволяли добиваться приемлемой производительности иерархических СУБД на медленных ЭВМ с весьма ограниченными объемами памяти. Но, если данные не имели древовидной структуры, то возникала масса сложностей при построении иерархической модели и желании добиться нужной производительности.
Сетевые модели также создавались для мало ресурсных ЭВМ. Сетевой подход к организации данных является расширением иерархического. В этой модели потомок может иметь любое число предков. Сетевая БД (рис. 10) состоит из набора записей и набора связей между этими записями, а если говорить более точно, из наборов экземпляров каждого типа из заданного в схеме БД набора типов записи и набора экземпляров каждого типа из заданного набора типов связи. Тип связи определяется для двух типов записи: предка и потомка.
Рис.10. Сетевая модель данных.
При разработке сетевых моделей было выдумано множество "маленьких хитростей", позволяющих увеличить производительность СУБД, но существенно усложнивших последние. Прикладной программист должен знать массу терминов, изучить несколько внутренних языков СУБД, детально представлять логическую структуру базы данных для осуществления навигации среди различных экземпляров, наборов, записей и т.п. Сложность практического использования иерархических и сетевых СУБД заставляла искать иные способы представления данных. В конце 60-х годов появились СУБД на основе инвертированных файлов, отличающиеся простотой организации и наличием весьма удобных языков манипулирования данными. Однако такие СУБД обладают рядом ограничений на количество файлов для хранения данных, количество связей между ними, длину записи и количество ее полей.
Сегодня наиболее распространены реляционные (основанные на двумерных таблицах) модели данных, состоящих из строк (записей) и имено ванных столбцов (полей):
|
Ф.И.О. |
Отдел |
Долж ность |
№ ка бинета |
Телефон |
Имена полей |
|
Запись |
|||||
|
Поле |
Каждая таблица описывает некоторый класс объектов вы бранной предметной области, например служащих, а каждая строка-запись содержит информацию о конкретном объекте (служащем). Каждый же столбец-поле описывает один из ат рибутов данного объекта, например Ф.И.О.
Основными понятиями реляционных баз данных являются: тип данных, домен, атрибут, кортеж, первичный ключ и отношение.
Для начала покажем смысл этих понятий на примере от ношения СОТРУДНИКИ, содержащего некоторую информа цию о сотрудниках некоторой организации (рис. 11):
Рис. 11. Основные понятия реляционных баз данных.
Тип данных. Это понятие в реляционной модели данных полностью адекватно понятию типа данных в языках про граммирования. Обычно в современных реляционных БД до пускается хранение символьных и числовых данных, битовых строк, специализированных числовых данных (таких как «деньги»), а также специальных «темпоральных» данных (дата, время, временной интервал). В нашем примере мы имеем дело с данными трех типов: строки символов, целые числа и «деньги».
Домен. Понятие домена более специфично для баз данных, хотя и имеет некоторые аналогии с подтипами в некоторых языках программирования. В самом общем виде домен опре деляется заданием некоторого базового типа данных, к кото рому относятся элементы домена, и произвольного логическо го выражения, применяемого к элементу типа данных. Если вычисление этого логического выражения дает результат «ис тина», то элемент данных является элементом домена. Наибо лее правильная интуитивная трактовка понятия домена — понимание его как допустимого потенциального множества значений данного типа. Например, домен «Имена» в нашем примере определен на базовом типе строк символов, но в число его значений будут входить только те строки, которые могут изображать имя (в частности, такие строки не могут начинаться с мягкого знака). Следует отметить также семан тическую нагрузку понятия домена: данные считаются срав нимыми только в том случае, когда они относятся к одному домену. В нашем примере значения доменов «Номера пропус ков» и «Номера групп» относятся к типу целых чисел, но не являются сравнимыми. В большинстве реляционных СУБД понятие домена не используется.
Схема отношения, схема базы данных. Схема отношения — это именованное множество пар имя атрибута, имя домена (или типа, если понятие домена не поддерживается). Степень, или «арность», схемы отношения — мощность этого множест ва. Степень отношения СОТРУДНИКИ равна четырем, т. е. оно является 4-арным. Если все атрибуты одного отношения определены на разных доменах, целесообразно использовать для именования атрибутов имена соответствующих доменов (не забывая, конечно, о том, что это является всего лишь удобным способом именования и не устраняет различия меж ду понятиями домена и атрибута). Схема БД (в структурном смысле) — это набор именованных схем отношений.
Кортеж, отношение. Кортеж, соответствующий данной схеме отношения, — это множество пар имя атрибута, значе ние, которое содержит одно вхождение каждого имени атри бута, принадлежащего схеме отношения. «Значение» является допустимым значением домена данного атрибута (или типа данных, если понятие домена не поддерживается). Тем самым степень, или «арность», кортежа, т. е. число элементов в нем, совпадает с «арностью» соответствующей схемы отношения. То есть кортеж — это набор именованных значений заданного типа. Отношение — это множество кортежей, соответствую щих одной схеме отношения. Практически ориентированное понимание реляционной базы данных: обычным житейским представлением отношения является таблица, заголовок кото рой — схема отношения, а строки — кортежи отношения-эк земпляра; в этом случае имена атрибутов именуют столбцы этой таблицы. Поэтому иногда говорят «столбец таблицы», имея в виду «атрибут отношения». Этой терминологии при держиваются в большинстве коммерческих реляционных СУБД. Реляционная база данных — это набор отношений, имена которых совпадают с именами схем отношений в схеме БД. Как видно, основные структурные понятия реляционной модели данных (если не считать понятия домена) имеют очень простую интуитивную интерпретацию, хотя в теории реляци онных БД все они определяются абсолютно формально и точно.
К числу достоинств реляционного подхода можно отнести:
Для привязки даталогической модели к среде хранения используется физическая модель. Она определяет используемые запоминающие устройства, способ расположения элементов данных в памяти, способы физической реализации логических отношений между элементами данных. Модель физического уровня (или внутреннего уровня) строится с учетом ограничений СУБД и операционной системы.
Модель каждого из последующих уровней строится на основе фиксированных характеристик моделей предшествующих уровней (рис.12).
Рис. 12. Отражение предметной области в БД.
Указанные классы моделей имеют разный уровень абстракции. Выделение моделей разных уровней абстракции позволяет:
Выполнение функций БД обеспечивается комплексом средств, называемым обеспечивающим составом, или обеспе чением. Этот комплекс включает следующее:
Способы доступа к данным на протяжении нескольких по следних десятилетий развивались от громоздких, физически ориентированных методов начального периода обработки файлов к различным видам обработки баз данных. Одним из наиболее важных аспектов реляционной «революции» стала идея отделения логической структуры, как она понимается конечным пользователем, от физического представления, тре буемого компьютерным оборудованием. Это суть философии структуры данных, представленной в модели ANSI/SPARC.
Трехуровневая архитектура баз данных — это стандартная их структура, состоящая из концептуального, внешнего (уро вень логического проектирования) и внутреннего уровней.
На первом из названных уровне выполняется концепту альное проектирование БД. Оно включает анализ информаци онных потребностей пользователей и определение нужных им элементов данных. Результатом этого уровня является концеп туальная схема, единое логическое описание всех элементов данных и отношений между ними. Концептуальный уровень — структурный уровень баз данных, определяющий ее логи ческую схему.
Внешний уровень (уровень логического проектирования) составляют пользовательские представления данных БД. У каждой пользовательской группы свое представление данных в БД. Каждое такое представление имеет ориентированное на пользователя описание элементов данных и отношений между ними. Его можно напрямую вывести из концептуальной схемы. Совокупность всех таких пользовательских представ лений данных и есть внешний уровень. Внешний уровень — структурный уровень БД, определяющий пользовательские представления данных.
Внутренний уровень обеспечивает физический взгляд на БД: дисководы, физические адреса, индексы, указатели и т. д. За этот уровень отвечают проектировщики физической БД. Ни один пользователь не касается этого уровня. Внутренний уро вень — структурный уровень БД, определяющий физический вид БД.
Концептуальное проектирование БД.
Главным итоговым результатом концептуального проекти рования является определение основных информационных объ ектов предметной области и отношений между ними. Выде ление основных информационных объектов начинается с ана лиза документов и регламентаций (положения, инструкции, бланки, формализованные карточки, отчеты, формы, жур налы).
Анализ «бумажной» документации позволяет сформиро вать перечень атрибутов, характеризующих те или иные ин формационные объекты и отношения между ними.
В соответствии с технологической схемой обработки информации (см. рис.8) на основе предва рительного формирования общего представления о предметной области, а также дополнительного изучения документации (структура журналов регистрации и учета документов, порядок ведения номенклатурных дел и т. д.) можно выделить следующие по нятия и категории: жилой дом, квартиросьемщик, льготная категория граждан, ставка, лицевой счет, виды коммунальных оплат, и т.д.
В итоге перечень объектов и их атрибутов может быть следующим:
Таким образом, простая концептуальная модель БД разрабатываемой для технологической схемы (см. рис. 8) будет иметь следующий графический вид (рис.13).
Рис. 13. Пример концептуальной схемы БД.
Логическое проектирование и нормализация БД.
В процессе логического проектирования создается струк тура БД, соответствующая концептуальной схеме и предполагаемым автоматизируемым процедурам обработки информации. Адекват ность реализации концептуальной схемы определяется в ходе отладки и дальнейшей эксплуатации БД.
При проектировании можно выделить последователь ность процедур:
Технологически процесс проектирования разделяют на предварительное проектирование таблиц и связей между ними (п.п. 1—5) и последующую нормализацию таблиц — п. 6.
Нормализация таблиц определяется требованием рацио нальности группировки полей-атрибутов по различным табли цам. С содержательной точки зрения нормализацию таблиц можно рассматривать как некоторую доработку концептуаль ной схемы БД в тех случаях, когда концептуальное проекти рование произведено без достаточной доработки и в входе предварительного проектирования созданы таблицы, отра жающие данные сразу нескольких объектов сущностей пред метной области.
С формальной точки зрения нормализацию можно пред ставить как последовательный процесс разбиения и преобра зования некоторого набора таблиц для построения связанных таблиц в нормальных формах. Основатель реляционной моде ли Е. Кодд выделял три нормальные формы — первую, вто рую и третью. Этот набор был дополнен нормальной формой Бойса — Кодда и далее — четвертой и пятой нормальными формами. Наиболее простой нормальной формой является первая, суть которой определяется требованием неделимости полей и единственности значений по полям. В табл. 3. приведен пример ненормализованной структуры данных «Оплата коммунальных услуг» (см. концептуальную схему рис. 13), имеющей составное (делимое) поле «Оплата коммунальных услуг» с множест венными значениями по полям «Вид услуги», «Оплата», «Тариф».
Таблица. 3. Ненормализованная структура данных «Оплата коммунальных услуг».
|
№ |
Адрес |
Ф.И.О. |
Категория льготы |
Оплата коммунальных услуг |
||
|
Вид услуги |
Оплата |
Тариф |
||||
|
1 |
Ул. Центральная 2 Кв.1 |
Попов В. Е. |
Нет |
Отопление |
100 руб. |
1,54 |
|
Водоотведение |
50 руб. |
1,03 |
||||
|
2 |
Ул. Центральная 2 Кв. 2 |
Карасева Т. С. |
Ветеран войны |
Водоотведение |
70 руб. |
1,03 |
|
3 |
Ул. Центральная 3 Кв. 1 |
Иванов В. Е. |
Инвалид |
Отопление |
80 руб. |
0,9 |
|
Водоотведение |
70 руб. |
0,7 |
Продолжение таблицы 3.
|
№ |
Площадь |
Кол-во человек |
Дата оплаты |
|
1 |
30 |
2 |
11.01.09 |
|
2 |
50 |
2 |
11.01.09 |
|
3 |
45 |
2 |
11.01.09 |
Приведение таких таблиц к первой нормальной форме осуществляется путем образования составных ключей, при которых устраняются ситуации с множественными значения ми полей. На рисунке 14 показана такая таблица (жирным шрифтом выделены ключевые поля).
|
№ |
Адрес |
Вид услуги |
Оплата |
Тариф |
Ф.И.О. |
Категория льготы |
|
1 |
Ул. Центральная 2 Кв.1 |
Отопление |
100 руб. |
1,54 |
Попов В. Е. |
Нет |
|
2 |
Ул. Центральная 2 Кв.1 |
Водоотведение |
50 руб. |
1,03 |
Попов В. Е. |
Нет |
|
3 |
Ул. Центральная 2 Кв. 2 |
Водоотведение |
70 руб. |
1,03 |
Карасева Т. С. |
Ветеран войны |
|
4 |
Ул. Центральная 3 Кв. 1 |
Отопление |
80 руб. |
0,9 |
Иванов В. Е. |
Инвалид |
|
5 |
Ул. Центральная 3 Кв. 1 |
Водоотведение |
70 руб. |
0,7 |
Иванов В. Е. |
Инвалид |
Продолжение таблицы
|
№ |
Площадь |
Кол-во человек |
Дата оплаты |
|
1 |
30 |
2 |
11.01.09 |
|
2 |
30 |
2 |
11.01.09 |
|
3 |
50 |
2 |
11.01.09 |
|
4 |
45 |
2 |
11.01.09 |
|
5 |
45 |
2 |
11.01.09 |
Рис. 14. Таблица в первой нормальной форме.
Таблица в первой нормальной форме содержит многочис ленные ситуации дублирования данных. Кроме того, напри мер, удаляя запись о виде услуг, по конкретному адресу, можно удалить информацию вообще о квартиросъемщике и обслуживаемом жилье. По этому Коддом был разработан специальный механизм разбие ния таблиц для приведения их к более совершенным нормаль ным формам. Этот механизм основан на понятии функцио нальной зависимости полей-атрибутов.
Поле-атрибут Y функционально зависит от поля-атрибу та Х, если любому значению Х всегда соответствует только одно значение Y. К примеру, значение поля «Ф.И.О. (квартиросъемщика» всегда соответствует одному значению «Адрес». В таблице, находящейся в первой нормальной форме, все неключевые атрибуты функционально зависят от ключа таблицы.
Вторая нормальная форма основывается на понятии полной функциональной зависимости. Функциональная зави симость неключевого поля от составного ключа таблицы на зывается полной, если он функционально зависит в целом от составного ключа, но не зависит отдельно от любой его части. В примере значение поля «Ф. И. О» определяется только значением поля «Адрес» которое является частью составного ключа. Следовательно, полной функциональной зависимости нет. В полной функциональной зависимости от составного ключа находится поле «Оплачено», так как толь ко комбинация значений «Адрес» и «Вид оплаты» опре деляет конкретное значение поля «Оплачено».
Для перевода таблицы из первой нормальной формы во вторую необходимо:
Ниже показан пример приведения таблицы из первой нор мальной формы во вторую.
Проекция на составной ключ с полями, находящимися в полной функциональной зависимости от него (табл.4):
Табл.4. Проекция на составной ключ с полями, находящимися в полной функциональной зависимости.
|
Адрес |
Вид услуги |
Оплата |
Тариф |
Дата оплаты |
|
Ул. Центральная 2 Кв.1 |
Отопление |
100 руб. |
1,54 |
11.01.09 |
|
Ул. Центральная 2 Кв.1 |
Водоотведение |
50 руб. |
1,03 |
11.01.09 |
|
Ул. Центральная 2 Кв. 2 |
Водоотведение |
70 руб. |
1,03 |
11.01.09 |
|
Ул. Центральная 3 Кв. 1 |
Отопление |
80 руб. |
0,9 |
11.01.09 |
|
Ул. Центральная 3 Кв. 1 |
Водоотведение |
70 руб. |
0,7 |
11.01.09 |
Проекция на поле ключа с полями, находящимися с дан ным полем в функциональной зависимости (табл.5):
Табл. 5. Проекция на поле ключа с полями, находящимися с дан ным полем в функциональной зависимости.
|
Адрес |
Ф.И.О. |
Категория льготы |
Площадь |
Кол-во человек |
|
Ул. Центральная 2 Кв.1 |
Попов В. Е. |
Нет |
30 |
2 |
|
Ул. Центральная 2 Кв. 2 |
Карасева Т. С. |
Ветеран войны |
50 |
2 |
|
Ул. Центральная 3 Кв. 1 |
Иванов В. Е. |
Инвалид |
45 |
2 |
В таблицах, находящихся во второй нормальной форме, большинство аномалий, присущих первой форме, устранено. Однако по определенным атрибутам многочисленные ситуа ции дублирования данных могут сохраниться. Например, для приведенной ниже таблицы 6 «Информация о сотрудниках ЖКХ», находящейся во второй нормальной форме, про исходит дублирование информации о телефоне 529505 т.к. атрибут «Телефон» фактически зависит не от атрибута «Ф.И.О.», а от атрибута «Кабинет». Иначе говоря, наблюдается цепочка функциональной зависимости атрибутов «Ф.И.О.», - «Кабинет» - «Телефон», а функциональная зависимость атрибута «Телефон» от атрибута «Ф.И.О.» является лишь логическим следствием такой цепочки зависимостей. В таких ситуациях говорят о транзитивной зависимости атрибута «Телефон» от атрибута «Ф.И.О.».
Таблица 6. «Информация о сотрудниках ЖКХ»
|
Ф.И.О. |
Должность |
Кабинет |
Телефон |
|
Попова Т. Е. |
Бухгалтер |
100 |
514517 |
|
Карасева Т. А. |
Расчетчик |
303 |
529505 |
|
Иванова С. Е. |
Расчетчик |
303 |
529505 |
По определению таблица-отношение будет в третьей нор мальной форме, если она находится во второй нормальной форме и каждое ее неключевое поле-атрибут нетранзитивно зависит от первичного ключа. Или: третьей нормальной фор мой является взаимная независимость неключевых атрибутов и их полная функциональная зависимость от первичного ключа.
Для преобразования из второй в третью нормальную форму таблицу-отношение разделяют на несколько проекций так, чтобы конечные поля-атрибуты в цепочках транзитивной зависимости вынести в отдельные таблицы, связав разделив шиеся части таблицы внешними ключами по полям-атрибу там, находящимся внутри цепочек транзитивной зависимости.
Декомпозиция таблицы в третью нормальную форму пу тем разделения цепочки транзитивной зависимости «Ф.И.О» — «Кабинет» — «Телефон» представлена на рисунке 15. Внут реннее в этой цепочке поле «Кабинет» стало внешним ключом в первой таблице и первичным ключом во второй.
|
Ф.И.О |
Должность |
Кабинет |
|
Попова Т. Е. |
Бухгалтер |
100 |
|
Карасева Т. А. |
Расчетчик |
303 |
|
Иванова С. Е. |
Расчетчик |
303 |
|
Кабинет |
Телефон |
|
100 |
514517 |
|
303 |
529505 |
|
303 |
529505 |
Рис. 15. Таблица в третьей нормальной форме
На практике третья нормальная форма устраняет большин ство аномалий схем таблиц-отношений, а также ситуации дуб лирования данных, и после декомпозиции исходных таблиц-отношений до третьей нормальной формы процесс нормали зации заканчивается. Вместе с тем в некоторых случаях тре тью нормальную форму можно также «улучшить», в частно сти приведением таблицы-отношения в нормальную форму Бойса — Кодда.
Подобные ситуации связаны с наличием так называемых детерминантов — совокупности атрибутов (составных атрибу тов), от которых функционально полно зависят другие атрибу ты. В результате таблица может находится в третьей нормаль ной форме, т. е. все ее неключевые атрибуты взаимно функ ционально независимы, но имеется полная функциональная зависимость некоторых атрибутов от совокупности других атрибутов (детерминантов).
Таблица-отношение находится в нормальной форме Бойса — Кодда тогда и только тогда, когда каждый ее детерминант является возможным ключом. Очевидно, что если в таблице имеется всего один возможный ключ, то он одновременно является детерминантом и нормальная форма Бойса — Кодда совпадает с третьей нормальной формой. Поэтому иногда нормальную форму Бойса — Кодда называют частным случа ем третьей нормальной формы.
Для приведения таблицы в нормальную форму Бойса — Кодда необходимо произвести декомпозицию так, чтобы ис ключить случаи пересечения по некоторым полям-атрибутам имеющихся детерминантов.
Встречаются также случаи, требующие «улучшения» и нормальной формы Бойса — Кодда. Такие ситуации называют многозначной зависимостью атрибутов. Их устраняет четвер тая нормальная форма. Таблица-отношение находится в чет вертой нормальной форме тогда и только тогда, когда в слу чае существования многозначной зависимости атрибута Y от атри бута X все остальные атрибуты зависят только от атрибута X.
Наиболее сложной при нормализации является пятая нор мальная форма, связанная с наличием в таблице-отношении зави симостей соединения. Из-за нетривиальности зависимости соеди нения пятая нормальная форма практически не исполь зуется.
Нормализация таблиц при проектировании баз данных проводится для рационализации группировки полей-атрибутов в схемах таблиц с целью устранения аномалий и дублирования данных. Вместе с тем процесс нормализации приводит к де композиции исходных таблиц на множество связанных и не связанных более простых таблиц. В результате при обработке данных приходится осуществлять множество операций соеди нения таблиц, что выдвигает высокие требования к вычисли тельным ресурсам при больших объемах информации. Поэто му на практике в большинстве случаев при проектировании схем реляционных баз данных ограничиваются третьей нор мальной формой.
Результатом проектирования и нормализации таблиц явля ется законченная схема (логическая структура) базы данных. Технологически описание схемы БД помещается в каталог базы данных, который в реляционных СУБД пред ставляет также таблицу. Обычно каталог базы данных хранит ся в файле БД вместе с данными.
В некоторых СУБД имеются специальные инструменты визуального графического определения связей между табли цами и ограничений целостности по ним. Кроме того, появля ются также специальные анализаторы структуры таблиц БД с точки зрения рациональности и дублирования данных, кото рые позволяют в некоторой степени автоматизировать процес сы нормализации таблиц.
Под физической организацией БД понимают совокупность методов и средств размещения данных во внешней памяти и созданную на их основе внутреннюю (физическую) модель данных. Внутренняя модель является средством отображения логической модели данных в физическую среду хранения. В отличие от логических моделей, физическая модель данных связана со способами их организации на носителях методами доступа к ним. Она указывает, каким образом размещаются записи в БД, как они упорядочиваются, как организуются связи, каким путем можно локализовать записи и осуществить их выборку. Внутренняя модель разрабатывается средствами СУБД.
К внутренним моделям данных предъявляется ряд требо ваний, основными из которых являются:
Любая логическая модель может быть отражена множест вом внутренних моделей данных. Задача разработчика банка данных — найти оптимальный вариант внутренней модели.
Основными средствами физического моделирования в БД являются структура хранения данных, поисковые структуры и язык описания данных (ЯОД). В простейшем случае структуру хранения данных можно представить в виде структуры записи файла БД, включающей поля записи, порядок их размещения, типы и длины полей. Для сокращения времени поиска данных кроме структуры хранения разрабатываются также поисковые структуры. Структура хранения данных в основном предна значена для указания способа размещения записей и полей, поисковые структуры определяют способ быстрого нахожде ния этих записей. Поэтому можно выделить два принципа физической организации БД:
Конечным итогом разработки физической организации БД являются файлы данных — файл БД и файлы поисковых структур. В персональных компьютерах эти файлы могут быть последовательными (последовательного доступа) или прямы ми (прямого доступа).
Из множества типов поисковых структур в СУБД на пер сональных компьютерах чаще всего используются линейные и цепные списки, инвертированные и индексные файлы.
Линейный список — наиболее простой способ физической организации БД. В отличие от остальных трех способов он не требует создания дополнительных файлов. В соответствии с этим способом файл БД рассматривается как последователь ность невзаимосвязанных записей. Поиск любой из них вы полняется путем вычисления адреса записи по некоторому алгоритму. По критерию «минимум памяти» это самый эко номичный способ. Однако по быстродействию он проигрывает остальным, поскольку необходимо затрачивать определенное машинное время на вычисление адресов.
Цепной список представляет собой файл, записи которо го имеют ссылки на другие записи, образуя ассоциативную орга низацию данных. Средством связи (ссылкой) элементов спи ска являются указатели, встраиваемые в записи в виде допол нительных полей. Такой способ считывания можно назвать прямым (в отличие от косвенных связей). С помощью указате лей устанавливается любой требуемый порядок вы борки запи сей.
Поле, выделяемое для хранения указателя, называется ад ресом связи (АС). Чтобы войти в список, необходимо указать точку входа, т. е. адрес начала списка (АНС). Такой адрес хра нится, как правило, в отдельной записи — фиксаторе (заго ловке) списка (ФС) (рис. 16).
АНС
ФС АС АС АС
Рис. 16. Цепной список в графическом виде.
Если вместо АС поместить адрес фиксатора списка ФС, то цепной список становится кольцевым (циклическим) списком, обеспечивающим возврат к фиксатору и, таким образом, воз можность многократного просмотра этого списка либо пере хода к другому списку. Добавление в запись еще одного ука зателя (второго поля АС) позволяет сделать список двуна правленным, читаемым как в прямом, так и в обратном на правлении. В записи можно предусмотреть любое требуемое количество указателей k и, следовательно, иметь k вариантов выборки записей файла.
Цепные списки наиболее удобны для представления во внешней памяти ЭВМ сетевых моделей данных.
В базе данных записи, как правило, упорядочены по одно му из полей (основному ключу), что позволяет сократить пе ребор записей при чтении файла БД. Для уменьшения времени поиска данных по неключевым полям создаются инвертиро ванные файлы. Инвертированным называется файл, записи которого упорядочены по неключевому полю. Процесс созда ния инвертированного файла состоит в переупорядочении исходного (основного) файла по значениям неключевого поля, т. е. в получении копии основного файла с иным порядком следования записей. Инвертирование основного файла будет полным, если созданы инвертированные файлы для каждого из его неключевых полей, и частичным, если они созданы только для части неключевых полей.
Пример БД в составе основного файла, записи которого упорядочены по ключевому полю ФАМИЛИЯ, и инвертиро ванного файла ИФ_ГОД, записи которого упорядочены по неключевому полю ГОД основного файла:
Основной файл
|
Фамилия |
Год |
…… |
|
Борисов А. А. |
1970 |
|
|
Иванов И. Р. |
1969 |
|
|
Сейфуллин Р. С. |
1969 |
Инвертированный файл
|
Фамилия |
Год |
…… |
|
Иванов И. Р. |
1969 |
|
|
Сейфуллин Р. С. |
1969 |
|
|
Борисов А. А. |
1970 |
При вводе, например, запроса «найти сотрудников с годом рождения, меньшим 1970», поиск данных необходимо вести не в основном файле, где потребуется полный перебор запи сей, а в инвертированном файле, в котором для нашего приме ра достаточно прочитать две первые записи.
Инвертированный файл обеспечивает самый быстрый по иск данных по неключевому полю. По отношению к основно му файлу БД он является поисковой структурой. Однако при менение инвертированного файла приводит к чрезмерному дублированию информации, т. е. перерасходу памяти.
В связи с этим целесообразно создавать не инвертирован ные файлы, а инвертированные файлы адресов записей основ ного файла, т. е. файлы, содержащие вместо записей БД адреса этих записей. Такие файлы называются индексными файлами (индексами), они занимают малый объем памяти. Каждая за пись индекса содержит значение одного неключевого поля и список адресов записей основного файла, в которых встреча ется указанное значение неключевого поля. Файл БД, для об работки которого используется хотя бы один индекс, называ ется индексированным файлом. Построение индекса выполня ется автоматически самой СУБД.
Поиск записей в БД с помощью индексов заключается в выборе индекса, соответствующего признаку поиска, поиске в индексе строки с заданным значением признака, выборке из этой строки списка адресов исходных записей и чтении этих записей в основном файле по указанным адресам методом прямого доступа.
Пример физической организации базы данных в составе файла БД и индексного файла И1:
Основной файл
|
№ |
Фамилия |
Год |
|
001 |
Борисов А. А. |
1970 |
|
002 |
Иванов И. Р. |
1969 |
|
003 |
Сейфуллин Р. С. |
1969 |
|
004 |
Яшин Л. З. |
1959 |
Индексный файл
|
Год |
Адреса |
|
1959 |
004 |
|
1969 |
002 003 |
|
1970 |
001 |
Таким образом, БД может включать один основной и не сколько вспомогательных файлов. Состав БД в случае исполь зования индексных файлов в качестве поисковой структуры можно представить выражением:
БД={ФБД, [ИФ1, ИФ2, ….ИФn]},
где ФБД — основной файл БД;
ИФj — индексный файл; j = 1,2, …n;
n — количество индексных файлов, равное количеству ат рибутов в ФБД или меньшее его.
Язык SQL является основой многих СУБД, т.к. отвечает за физическое структурирование и запись данных на диск, а также за чтение данных с диска, позволяет принимать SQL-запросы от других компонентов СУБД и пользовательских приложений. Таким образом, SQL – мощный инструмент, который обеспечивает пользователям, программам и вычислительным системам доступ к информации, содержащейся в реляционных базах данных.
Основные достоинства языка SQL заключаются в следующем:
Любой язык работы с базами данных должен предоставлять пользователю следующие возможности:
Кроме того, язык работы с базами данных должен решать все указанные выше задачи при минимальных усилиях со стороны пользователя, а структура и синтаксис его команд – достаточно просты и доступны для изучения. И наконец, он должен быть универсальным, т.е. отвечать некоторому признанному стандарту, что позволит использовать один и тот же синтаксис и структуру команд при переходе от одной СУБД к другой. Язык SQL удовлетворяет практически всем этим требованиям.
Язык SQL является примером языка с трансформирующейся ориентацией, или же языка, предназначенного для работы с таблицами с целью преобразования входных данных к требуемому выходному виду. Он включает только команды определения и манипулирования данными и не содержит каких-либо команд управления ходом вычислений. Подобные задачи должны решаться либо с помощью языков программирования или управления заданиями, либо интерактивно, в результате действий, выполняемых самим пользователем. По причине подобной незавершенности в плане организации вычислительного процесса язык SQL может использоваться двумя способами. Первый предусматривает интерактивную работу, заключающуюся во вводе пользователем с терминала отдельных SQL-операторов. Второй состоит во внедрении SQL-операторов в программы на процедурных языках. Язык SQL относительно прост в изучении. Поскольку это не процедурный язык, в нем необходимо указывать, какая информация должна быть получена, а не как ее можно получить. Иначе говоря, SQL не требует указания методов доступа к данным. Как и большинство современных языков, он поддерживает свободный формат записи операторов. Это означает, что при вводе отдельные элементы операторов не связаны с фиксированными позициями экрана. Язык SQL может использоваться широким кругом специалистов, включая администраторов баз данных, прикладных программистов и множество других конечных пользователей.
Язык SQL – первый и пока единственный стандартный язык для работы с базами данных, который получил достаточно широкое распространение. Практически все крупнейшие разработчики СУБД в настоящее время создают свои продукты с использованием языка SQL либо с SQL-интерфейсом. В него сделаны огромные инвестиции как со стороны разработчиков, так и со стороны пользователей. Он стал частью архитектуры приложений, является стратегическим выбором многих крупных и влиятельных организаций.
Язык SQL используется в других стандартах и даже оказывает влияние на разработку иных стандартов как инструмент определения (например, стандарт Remote Data Access, RDA). Создание языка способствовало не только выработке необходимых теоретических основ, но и подготовке успешно реализованных технических решений. Это особенно справедливо в отношении оптимизации запросов, методов распределения данных и реализации средств защиты. Начали появляться специализированные реализации языка, предназначенные для новых рынков: системы управления обработкой транзакций (OnLine Transaction Processing, OLTP) и системы оперативной аналитической обработки или системы поддержки принятия решений (OnLine Analytical Processing, OLAP). Уже известны планы дальнейших расширений стандарта, включающих поддержку распределенной обработки, объектно-ориентированного программирования, расширений пользователей и мультимедиа.
Все запросы на получение практически любого количества данных из одной или нескольких таблиц выполняются в языке SQL с помощью единственного предложения SELECT. В общем случае результатом реализации предложения SELECT является другая (рабочая) таблица. К этой новой (рабочей) таблице может быть снова применена операция SELECT и т.д., т.е. такие операции могут быть вложены друг в друга. Представляет исторический интерес тот факт, что именно возможность включения одного предложения SELECT внутрь другого послужила мотивировкой использования прилагательного "структуризированный" в названии языка SQL.
Предложение SELECT может использоваться как:
Ведем следующие обозначения:
Предложение SELECT (выбрать) имеет следующий формат:
SELECT [[ALL] | DISTINCT]{ * | элемент_SELECT
[,элемент_SELECT] ...}
FROM {базовая_таблица | представление} [псевдоним]
[,{базовая_таблица | представление} [псевдоним]] ...
[WHERE фраза]
[GROUP BY фраза [HAVING фраза]];
где:
Фраза WHERE включает набор условий для отбора строк:
WHERE [NOT] WHERE_условие
[[AND|OR][NOT] WHERE_условие]...
Где: WHERE_условие – одна из следующих конструкций:
значение { = | <> | < | <= | > | >= }
{ значение | ( подзапрос ) }
значение_1 [NOT] BETWEEN значение_2 AND значение_3
значение [NOT] IN { ( константа [,константа]... )
| ( подзапрос ) }
значение IS [NOT] NULL
[таблица.]столбец [NOT] LIKE 'строка_символов'
Кроме традиционных операторов сравнения (= | <> | < | <= | > | >=) в WHERE фразе используются условия BETWEEN (между), LIKE (похоже на), IN (принадлежит), IS NULL (не определено) и EXISTS (существует), которые могут предваряться оператором NOT (не). Критерий отбора строк формируется из одного или нескольких условий, соединенных логическими операторами:
-причем существует приоритет AND над OR (сначала выполняются все операции AND и только после этого операции OR). Для получения желаемого результата WHERE условия должны быть введены в правильном порядке, который можно организовать введением скобок.
При обработке условия строки символов сравниваются в соответствии с их представлением в коде, используемом в конкретной СУБД, например, в коде ASCII. Если сравниваются две строки символов, имеющих разные длины, более короткая строка дополняется справа пробелами для того, чтобы они имели одинаковую длину перед осуществлением сравнения.
Синтаксис фразы GROUP BY имеет вид
GROUP BY [таблица.]столбец [,[таблица.]столбец] ...
[HAVING фраза]
GROUP BY инициирует перекомпоновку формируемой таблицы по группам, каждая из которых имеет одинаковое значение в столбцах, включенных в перечень GROUP BY. Далее к этим группам применяются агрегирующие функции, указанные во фразе SELECT, что приводит к замене всех значений группы на единственное значение (сумма, количество и т.п.).
С помощью фразы HAVING (синтаксис которой почти не отличается от синтаксиса фразы WHERE)
HAVING [NOT] HAVING_условие
[[AND|OR][NOT] HAVING_условие]...
можно исключить из результата группы, не удовлетворяющие заданным условиям.
В соответствии с технологической схема обработки информации (см. рис.8), на основании логической схемы базы данных (см. табл. 4, 5), следующие запросы позволяют:
1. Сформировать перечень коммунальных услуг по адресу ул. Центральная 2, кв. 1,
SELECT Адрес, Вид услуги, Тариф FROM Таблица 4 WHERE Адрес= «Ул. Центральная 2 Кв.1»;
-в результате имеем результат представленный в табл. 7.
Таблица 7. Результат выполнения запроса о перечне коммунальных услуг.
|
Адрес |
Вид услуги |
Тариф |
|
Ул. Центральная 2 Кв.1 |
Отопление |
1,54 |
|
Ул. Центральная 2 Кв.1 |
Водоотведение |
1,03 |
2. Определить квартиросъемщика и наличие льготы по адресу ул.Центральная 2, кв. 1,
SELECT Адрес, Ф.И.О., Категория льготы FROM Таблица 5 WHERE Адрес= «Ул. Центральная 2 Кв.1»;
в результате имеем результат представленный в табл. 8.
Таблица 8. Результат выполнения запроса об определении квартиросъемщика и наличии льготы
|
Адрес |
Ф.И.О. |
Категория Льготы |
|
Ул. Центральная 2 Кв.1 |
Попов В. Е. |
Нет |
3. Определить дополнительные данные для расчета коммунальных услуг по адресу ул. Центральная 2, кв. 1,
SELECT Адрес, Площадь, Кол-во человек FROM Таблица 5 WHERE Адрес= «Ул. Центральная 2 Кв.1»;
в результате имеем результат представленный в табл. 9.
Таблица 9. Результат выполнения запроса об определении дополнительных данных для расчета коммунальных услуг
|
Адрес |
Площадь |
Кол-во человек |
|
Ул. Центральная 2 Кв.1 |
30 |
2 |
«Клиент-сервер» — это модель взаимодействия компьюте ров в сети. Как правило, компьютеры не являются равноправ ными. Каждый из них имеет свое, отличное от других назна чение, играет свою роль. Некоторые компьютеры в сети вла деют и распоряжаются информационно-вычислительными ресурсами, такими как процессоры, файловая система, почто вая служба, служба печати, база данных. Другие же имеют возможность обращаться к этим службам, пользуясь услугами первых. Компьютер, управляющий тем или иным ресурсом, принято называть сервером этого ресурса, а компьютер, кото рый может им воспользоваться, — клиентом. Конкретный сервер определяется видом ресурса, которым он владеет. Так, если ресурсом являются базы данных, то речь идет о сервере баз данных, назначение которого — обслуживать запросы клиентов, связанные с обработкой данных; если ресурс — это файловая система, то говорят о файловом сервере, или файл-сервере. В сети один и тот же компьютер может выполнять роль как клиента, так и сервера.
Этот же принцип распространяется и на взаимодействие программ. Если одна из них выполняет некоторые функции, предоставляя другим соответствующий набор услуг, то такая программа выступает в качестве сервера. Программы, которые пользуются этими услугами, принято называть клиентами. Так, ядро реляционной SQL-ориентированной СУБД часто называют сервером базы данных, или SQL-сервером, а про грамму, обращающуюся к нему за услугами по обработке дан ных, — SQL-клиентом.
Первоначально СУБД имели централизованную архитек туру. В ней сама СУБД и прикладные программы, которые работали с базами данных, функционировали на центральном компьютере (большая ЭВМ или мини-компьютер). Там же располагались базы данных. К центральному компьютеру были подключены терминалы, выступавшие в качестве рабочих мест пользователей. Все процессы, связанные с обработкой данных: поддержка ввода, осуществляемого пользователем, формирование, оптимизация и выполнение запросов, обмен с устройствами внешней памяти и т. д., — выполнялись на центральном компьютере, что предъявляло жесткие требования к его производительности. Особенности СУБД первого поколения напрямую связаны с архитектурой систем больших ЭВМ и мини-компьютеров и адекватно отражают все их пре имущества и недостатки. Однако нас больше интересует со временное состояние многопользовательских СУБД, для кото рых архитектура «клиент-сервер» стала фактическим стандар том. Сравним технологию «клиент-сервер» с технологией «файл-сервер» (рис. 25).
В файл-серверной системе данные хранятся на файловом сервере (например, Novell NetWare или Windows NT Server), а их обработка осуществляется на рабочих станциях, на кото рых, как правило, функционирует одна из так называемых «настольных СУБД» — Access, FoxPro, Paradox и т. п.
Приложение на рабочей станции отвечает за формирова ние пользовательского интерфейса, логическую обработку данных и за непосредственное манипулирование данными. Файловый сервер предоставляет услуги только самого низкого уровня — открытие, закрытие и модификацию файлов, а не базы данных. База данных существует только в «мозгу» рабо чей станции.
Таким образом, непосредственным манипулированием данными занимается несколько независимых и не согласован ных между собой процессоров. Кроме того, для осуществле ния любой обработки (поиск, модификация, суммирование и т. п.) все данные необходимо передать по сети с сервера на рабочую станцию.
В клиент-серверной системе функционируют (как мини мум) два приложения — клиент и сервер, делящие между со бой те функции, которые в файл-серверной архитектуре цели ком выполняет приложение на рабочей станции. Хранением и непосредственным манипулированием данными занимается сервер баз данных, в качестве которого может выступать Microsoft SQL Server, Oracle, Sybase и т. п.
Рис. 25. Технологии «файл-сервер» (слева)
и «клиент-сервер» (справа)
Формированием пользовательского интерфейса занима ется клиент; для построения интерфейса можно использо вать це лый ряд специальных инструментов, а также боль шинство настольных СУБД. Логика обработки данных мо жет выпол няться как на клиенте, так и на сервере. Клиент посылает на сервер запросы, сформулированные, как прави ло, на языке SQL. Сервер обрабатывает эти запросы и пере дает клиенту результат (разумеется, клиентов может быть много).
Таким образом, непосредственным манипулированием дан ными занимается один процессор. При этом обработка данных происходит там же, где данные хранятся — на серве ре, что исключает необходимость передачи больших объемов данных по сети.
ДОМЕНЫ
ОТНОШЕНИЕ СОТРУДНИКИ
Целые числа
Деньги
Строки символов
Номера пропусков
Размеры выплат
Имена
Сотр_номер
2934
2935
2936
2937
2938
Сотр_имя
Иванов
Петров
Сидоров
Федоров
Иванова
Сотр_зарп
112,000
144,500
92,000
110,000
112,000
ПЕРВИЧНЫЙ КЛЮЧ
КОРТЕЖИ
ТИПЫ ДАННЫХ
4
Иванов
Петров
Сидоров
Краснов
ФАЙЛ-СЕРВЕР
КЛИЕНТ-СЕРВЕР
Файл-сервер
Функции:
физическое
хранение данных
Высокая нагрузка на сеть: передаются большие
объемы данных
КЛИЕНТЫ
КЛИЕНТЫ
Функции: интерфейс
пользователя, логика обработки
Низкая нагрузка на сеть: передаются запросы
и результаты
Сервер базы данных
Функции: физическое хранение данных,
логика
обработки, управление данными
Функции: интерфейс
пользователя, логика обработки