СОДЕРЖАНИЕ

Стр.

1. Введение................................................................................ 4

2. История развития и классификация СУБД ...................... 16

2.1. Тенденции и перспективы развития СУБД....................... 18

2.2. Перспектива развития объектного подхода...................... 19

2.3 СУБД с параллельной обработкой данных........................ 20

2.4. Классификация современных СУБД................................. 21

3. Разработка базы данных....................................................... 22

3.1. Основные этапы разработки базы данных......................... 23

3.2. Информационно-логическая модель предметной области .25

3.3. Структурные связи.................................................................28

3.4. Каноническая форма ИЛМ ПО..............................................30

4. База данных ACCESS................................................................33

4.1. Объекты ACCESS...................................................................34

4.2. Средства создания приложений.............................................35

5. Начало работы в ACCESS.........................................................36

5.1. Открытие базы данных ACCESS......................................... .37

5.2. Создание базы данных............................................................38

5.3. Создание файла базы данных.................................................38

5.4. Создание таблицы базы данных..............................................39

6. Создание структуры базы данных.............................................44

7. Практические задания................................................................46

1. Введение

Известны два подхода к организации информационных массивов: файловая организация и организация в виде базы данных.

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

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

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

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

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

СУБД — это сложная программная система накопления и последующего манипулирования данными, представляющими интерес для пользователя.

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

Организация данных во внутримашинной сфере характеризуется на двух уровнях — логическом и физическом.

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

Логическая организация данных на машинном носителе зависит от используемых программных средств организации и ведения данных во внутримашинной сфере.

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

Модель данных — это совокупность взаимосвязанных структур данных и операций над этими структурами.

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

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

Файловая модель

В файловых системах реализуется модель типа плоский файл. При такой модели внутримашинная ИБ представляет собой сопокупность не связанных между собой файлов (независимых) из однотипных записей с линейной (одноуровневой) структурой.

Структуры данных файловой модели

Основные типы структур данных файловой модели — поле, запись, файл.

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

Поле — это элементарная единица логической организации данных, которая соответствует отдельной, неделимой единице информации — реквизиту.

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

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

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

Каждый экземпляр записи однозначно идентифицируется уникальным ключом записи.

В общем случае ключи записи бывают двух видов: первичный (уникальный) и вторичный ключ.

Первичный ключ (ПК) — это одно или несколько полей, однозначно идентифицирующих запись. Если первичный ключ состоит из одного поля, он называется простым, если из нескольких полей — составным ключом.

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

Названные структуры данных используются и в ряде СУБД, что делает эти понятия в определенном смысле универсальными.

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

Модель предметной области (МПО) .В настоящее время существует, по крайней мере, два различных подхода к созданию МПО, основанных на различных подходах к представлению данных.

Первый подход предполагает построение МПО на основе анализа и интеграции информационных потребностей пользователей будущего АБИ.

Альтернативный подход основан на анализе самой предметной области и построении МПО с учетом информационных потребностей пользователей.

В последнем случае анализ ПО проводится на основе объединения методов системного и классификационного анализов с привлечением методов экспертных оценок.

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

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

На основе анализа информационных потребностей пользователей разработчик (администратор) АБИ создает мысленную модель ПО, формализации которой приводят к двум видам моделей:

1. концептуальной или инфологической;

2. даталогической.

Инфологическая (информационно-логическая) модель ориентируется на пользователя, а даталогическая — на реализацию в вычислительной среде. В банках данных отображение инфологической МПО в среду СУБД порождает одну из возможных даталогических моделей.

Термины "инфологический" и "концептуальный" синонимичны. Так как более распространен второй из них, в дальнейшем мы будем использовать термин "концептуальная модель предметной области" (КМПО) . Заметим, что часто используемый в литературе термин "концептуальная модель данных" (или базы данных) является неверным.

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

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

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

В настоящее время различают три основные группы типов моделей данных; иерархическая, сетевая и реляционная, различия внутри каждой из которых определяются моделями данных, поддерживаемыми конкретной СУБД.

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

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

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

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

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

С точки зрения инструментального аспекта моделирования знаний, представленных в БЗ, интерес представляют языковые средства описания МБЗ, так как в качестве этих средств используются языки представления знаний (ЯПЗ).

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

Сетевые и иерархические модели данных

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

Тип модели данных, поддерживаемой СУБД на машинном носителе, является одним из важнейших признаков классификации СУБД.

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

Структуры данных в моделях

К типовым структурам данных относятся: элемент данных, агрегат данных, запись, база данных и т. д.

Элемент данных — это минимальная именованная структурная единица данных (аналог поля в файловых системах).

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

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

Таким образом, структура записи может иметь иерархический характер.

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

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

Связи объектов в моделях

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

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

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

Особенности моделей

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

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

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

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

Например, атрибут — аналог элемента данных. Объект линейной структуры состоит только из простых и ключевых атрибутов. Структура объекта (записи, сегмента) в иерархических моделях может быть иерархической или линейной.

Сравнение моделей

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

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

Реляционная модель данных

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

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

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

Структуры данных реляционной модели

Таблица является основным типом структуры данных (объектом) реляционной модели.

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

Столбец соответствует некоторому элементу данных — атрибуту, который является простейшей структурой данных.

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

Один или несколько атрибутов, значения которых однозначно идентифицируют строку таблицы, являются ключом таблицы.

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

Столбец таблицы со значениями соответствующего атрибута называется доменом, а строки со значениями разных атрибутов — кортежем

Нормализованные таблицы-отношения

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

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

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

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

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

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

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

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

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

Преимущества и недостатки реляционных моделей

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