Система управления базами данных

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Содержание

1. Понятие о базе данных и системе управления СУБД

1.1 Причины возникновения систем баз данных

1.2 Базы данных

1.3 Система управления БД

1.4 Структурированный язык запросов SQL

2. Информационно-логические модели данных

2.1 Иерархическая модель

2.2 Сетевая модель данных

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

2.4 Постреляционная модель

2.5 Многомерная модель

2.6 Объектно-ориентированная модель

3. Информационные объекты и их связи

4. Этапы проектирования и создания БД

Список использованной литературы

1. Понятие о базе данных и системе управления СУБД

1.1 Причины возникновения систем баз данных

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

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

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

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

4. Отсутствие описаний данных. В файлах операционной системы данные, обрабатываемые прикладными программами, хранятся без описания. Это создает сложности при документировании системы, затрудняет поиск нужных данных и приводит к появлению ошибок.

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

1.2 Базы данных

Предметная область АИС «материализуется» в форме, хранимой в памяти ЭВМ структурированной совокупности данных, которые характеризуют состав объектов предметной области, их свойства и взаимосвязи. Такое отражение предметной области принято называть базой данных (БД). Более строгое определение звучит следующим образом.

База данных - это совокупность определенным образом взаимосвязанных данных, хранящихся в памяти ЭВМ или системы, которая отображает структуру объектов и их связей.

Классификация баз данных



Рис. 1. Классификация БД

По типу хранимой информации БД делятся на:

документальные,

фактографические и

лексикографические.

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

К лексикографическим базам данных относятся различные словари (классификаторы, многоязычные словари, словари основ слов и т. п.).

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

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

Централизованная БД хранится в памяти одной вычислительной системы (применяется в локальных сетях ПК).

Централизованные БД могут быть с сетевым доступом.

Архитектуры систем централизованных БД с сетевым доступом подразделяются на файл-сервер и клиент-сервер.

Распределённая БД состоит из нескольких частей, хранимых в различных ЭВМ вычислительной сети (работа с такой БД происходит с помощью СУБД).

По способу доступа к данным БД разделяются на БД с локальным и удаленным доступом.

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

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

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

1.3 Система управления БД

Система управления базами данных - комплекс символьных и программных средств, предназначенных для создания, ведения и совместного доступа к БД.

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

Рис. 2. Классификация СУБД

Основные функции СУБД:

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

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

3. Управление данными -- можно указать, кому разрешено знакомиться с данными, корректировать их или добавлять новую информацию. Можно определить правило коллективного доступа.

Основными средствами СУБД являются:

* средства задания структуры данных;

* средства конструирования экранных форм, предназначенных для ввода данных, просмотра и обработки в диалоговом режиме;

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

* средства создания отчетов из базы данных для вывода на печать результатов обработки в удобном для пользователя виде;

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

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

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

Соответственно СУБД имеет два режима работы: проектировочный и пользовательский. Первый режим предназначен для создания или изменения структуры базы и ее объектов. Во втором режиме происходит использование ранее подготовленных объектов для наполнения базы или получения данных из нее.

Классификация СУБД

По способу доступа к БД разделяют:

1) Файл-серверные СУБД

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

Преимуществом этой архитектуры является низкая нагрузка на процессор файлового сервера.

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

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

Примеры: Microsoft Access, Paradox, dBase, FoxPro, Visual FoxPro.

Рис. 3. СУБД с сетевым доступом (Файл-сервер)

2) Клиент-серверные СУБД

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

Недостаток клиент-серверных СУБД состоит в повышенных требованиях к серверу.

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

Примеры: Oracle, Firebird, Interbase, IBM DB2, Informix, MS SQL Server, Sybase Adaptive Server Enterprise, PostgreSQL, MySQL, Cachй, ЛИНТЕР.

Рис. 4. СУБД с сетевым доступом Клиент-сервер

3) Встраиваемые СУБД

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

Примеры: OpenEdge, SQLite, BerkeleyDB, Firebird Embedded, Microsoft SQL Server Compact, ЛИНТЕР.

Состав СУБД

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

Рис. 5. Состав СУБД

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

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

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

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

В настоящее время функции всех трех языков выполняет язык SQL, относящийся к классу языков, базирующихся на исчислении кортежей (кортеж чаще всего является единицей информации), языки СУБД FoxPro, Visual Basic for Application (СУБД Access) и т.д.

1.4 Структурированный язык запросов SQL

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

Для подготовки запросов с помощью различных СУБД чаще всего используются два основных языка описания запросов:

QBE (Query By Example) - язык запросов по образцу;

SQL (Structured Query Language) - структурированный язык запросов.

По возможностям манипулирования данными при описании запросов указанные языки практически эквивалентны. Отличаются языки способом формирования запросов: язык QBE предполагает ручное или визуальное формирование запроса, в то время как использование SQL означает программирование запроса.

Язык SQL имеет несколько стандартов, наиболее распространенными из которых являются SQL-89 и SQL-92. Язык предназначен для выполнения операций над таблицами (создание, удаление, изменение структуры) и над данными таблиц (выборка, изменение, добавление и удаление), а также некоторых сопутствующих операций. SQL является непроцедурным языком и не содержит операторов управления, организации подпрограмм, ввода-вывода и т.п. В связи с этим SQL автономно не используется, обычно он погружен в среду встроенного языка программирования СУБД (например, FoxPro СУБД Visual FoxPro, ObjectPAL СУБД Paradox, Visual Basic for Applications СУБД Access).

Операторы языка SQL можно условно разделить на два подъязыка: язык определения данных (Data Definition Language - DDL) и язык манипулирования данными (Data Manipulation Language - DML).

2. Информационно-логические модели данных

2.1 Иерархическая модель

Иерархическая структура представляет совокупность элементов, связанных между собой по определенным правилам. Графическим способом представления иерархической структуры является дерево (рис. 6).

Рис. 6. Графическое изображение иерархической структуры

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

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

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Рис. 7. Пример иерархической структуры

К достоинствам иерархической модели данных относятся эффективное использование памяти ЭВМ и неплохие показатели времени выполнения операций над данными.

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

На иерархической модели данных основано сравнительно ограниченное количество СУБД, в числе которых можно назвать зарубежные системы IMS, PC/Focus, Team-Up и Data Edge, а также отечественные системы Ока, ИНЭС и МИРИС.

2.2 Сетевая модель данных

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



Рис. 8. Графическое изображение сетевой структуры

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Рис. 9. Пример взаимосвязей между элементами сетевой структуры

Достоинством сетевой модели данных является возможность эффективной реализации по показателям затрат памяти и оперативности.

Недостатком сетевой модели данных являются высокая сложность и жесткость схемы БД, построенной на ее основе.

Наиболее известными сетевыми СУБД являются IDMS, db_VistaIII, СЕТЬ, СЕТОР и КОМПАС.

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

Реляционная модель данных была предложена Е.Ф. Коддом, известным исследователем в области баз данных, в 1969 году, когда он был сотрудником фирмы IBM. Впервые основные концепции этой модели были опубликованы в 1970.

Реляционная база данных представляет собой хранилище данных, организованных в виде двумерных таблиц (рис. 10). Любая таблица реляционной базы данных состоит из строк (называемых также записями) и столбцов (называемых также полями).

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

Данные в таблицах удовлетворяют следующим принципам:

1) Каждое значение, содержащееся на пересечении строки и столбца, должно быть атомарным, т.е. неделимым.

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

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

4) Каждое поле имеет уникальное имя.

5) Последовательность полей в таблице несущественна.

6) Последовательность записей в таблице несущественна.

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

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

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

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

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

Примерами зарубежных реляционных СУБД для ПЭВМ являются: DB2, Paradox, FoxPro, Access, Clarion, Ingres, Oracle.

К отечественным СУБД реляционного типа относятся системы ПАЛЬМА и HyTech.

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Рис. 10. Схема реляционной модели данных

2.4 Постреляционная модель

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

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

а) Накладные Накладные-товары

N накладной	Покупатель		N накладной	Товар	Количество
0373	8723		0373	Сыр	3
8374	8232		0373	Рыба	2
7364	8723		8374	Лимонад	1
			8374	Сок	6
			8374	Печенье	2
			7364	Йогурт	1

б) Накладные

N накладной	Покупатель	Товар	Количество
0373	8723	Сыр	3
		Рыба	2
8374	8232	Лимонад	1
		Сок	6
		Печенье	2
7364	8723	Йогурт	1

Рис. 11. Структуры данных реляционной (а) и постреляционной (б) моделей

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

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

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

Рассмотренная постреляционная модель данных поддерживается СУБД uniVers. К числу других СУБД, основанных на постреляционной модели данных, относятся также системы Bubba и Dasdb.

2.5 Многомерная модель

Многомерный подход к представлению данных появился практически одновременно с реляционным, но интерес к многомерным СУБД стал приобретать массовый характер с середины 90-х годов. Толчком послужила в 1993 году статья Э. Кодда. В ней были сформулированы 12 основных требований к системам класса OLAP (OnLine Analytical Processing - оперативная аналитическая обработка), важнейшие из которых связаны с возможностями концептуального представления и обработки многомерных данных.

В развитии концепций информационных систем можно выделить следующие два направления:

1) системы оперативной (транзакционной) обработки;

2) системы аналитической обработки (системы поддержки принятия решений).

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

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

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

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

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

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

По сравнению с реляционной моделью многомерная организация данных обладает более высокой наглядностью и информативностью. Для иллюстрации на рис. 12 приведены реляционное (а) и многомерное (б) представления одних и тех же данных об объемах продаж автомобилей.

Если речь идет о многомерной модели с мерностью больше двух, то не обязательно визуально информация представляется в виде многомерных объектов (трех-, четырех- и более мерных гиперкубов). Пользователю и в этих случаях более удобно иметь дело с двумерными таблицами или графиками. Данные при этом представляют собой «вырезки» из многомерного хранилища данных, выполненные с разной степенью детализации.

а) б)

Модель	Месяц	Объем		Модель	Июнь	Июль	Август
Жигули	июнь	12		Жигули	12	24	5
Жигули	июль	24		Москвич	2	18	No
Жигули	август	5		Волга	No	19	No
Москвич	июнь	2
Москвич	июль	18
Волга	июль	19

Рис. 12. Реляционное (а) и многомерное (б) представление данных

Основные понятия многомерных моделей данных: измерение и ячейка.

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

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

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

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Рис. 13. Пример трехмерной модели

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

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

Примерами систем, поддерживающими многомерные модели данных, является Essbase, Media Multi-matrix, Oracle Express Server, Cache. Существуют программные продукты, например Media/MR, позволяющие одновременно работать с многомерными и с реляционными БД.

2.6 Объектно-ориентированная модель

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

Стандартизированная объектно-ориентированная модель описана в рекомендациях стандарта ODMG-93 (Object Database Management Group - группа управления объектно-ориентированными базами данных).

Рассмотрим упрощенную модель объектно-ориентированной БД. Структура объектно-ориентированной БД графически представима в виде дерева, узлами которого являются объекты. Свойства объектов описываются некоторым стандартным типом или типом, конструируемым пользователем (определяется как class). Значение свойства типа class есть объект, являющийся экземпляром соответствующего класса. Каждый объект-экземпляр класса считается потомком объекта, в котором он определен как свойство. Объект-экземпляр класса принадлежит своему классу и имеет одного родителя. Родовые отношения в БД образуют связную иерархию объектов. Пример логической структуры объектно-ориентированной БД библиотечного дела приведен на рис. 14. Здесь объект типа Библиотека является родительским для объектов-экземпляров классов Абонент, Каталог и Выдача. Различные объекты типа Книга могут иметь одного или разных родителей. Объекты типа Книга, имеющие одного и того же родителя, должны различаться, по крайней мере, инвентарным номером (уникален для каждого экземпляра книги), но имеют одинаковые значения свойств isbn, удк, название и автор.

Логическая структура объектно-ориентированной БД внешне похожа на структуру иерархической БД. Основное различие между ними состоит в методах манипулирования данными.

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

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

Наследование, наоборот, распространяет область видимости свойства на всех потомков объекта. Так, всем объектам типа Книга, являющимся потомками объекта типа Каталог, можно приписать свойства объекта-родителя: isbn, удк, название и автор. Если необходимо расширить действие механизма наследования на объекты, не являющиеся непосредственными родственниками (например, между двумя потомками одного родителя), то в их общем предке определяется абстрактное свойство типа abs. Так, определение абстрактных свойств билет и номер в объекте Библиотека приводит к наследованию этих свойств всеми дочерними объектами Абонент, Книга и Выдача. Не случайно поэтому значения свойства билет классов Абонент и Выдача, показанных на рис. 14, являются одинаковыми - 00015.

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

Поиск в объектно-ориентированной БД состоит в выяснении сходства между объектом, задаваемым пользователем, и объектами, хранящимися в БД.

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Рис. 14. Логическая структура БД библиотечного дела

Основным достоинством объектно-ориентированной модели данных в сравнении с реляционной является возможность отображения информации о сложных взаимосвязях объектов. Объектно-ориентированная модель данных позволяет идентифицировать отдельную запись базы данных и определять функции их обработки.

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

К объектно-ориентированным СУБД относятся POET, Jasmine, Versant, O2, ODB-Jupiter, Iris, Orion, Postgres.

3. Информационные объекты и их связи

Понятие информационного объекта

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

И.о. определенного реквизитного состава и структуры образует класс (тип), которому присваивается уникальное имя (или символьное обозначение). Например, Телефон, Словарь.

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

Нормализация отношений

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

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

Связи информационных объектов могут быть разного типа:

1) Одно - однозначные связи (1:1) имеют место, когда каждому экземпляру первого объекта (А) соответствует только один экземпляр второго объекта (В) и наоборот, каждому экземпляру второго объекта (В) соответствует только один экземпляр первого объекта (А).



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

2) Одно - многозначные связи (1:М) характеризуется тем, что каждому экземпляру одного объекта (А) может соответствовать несколько экземпляров другого объекта (В), а каждому экземпляру второго объекта (В) может соответствовать только 1 экземпляр первого объекта (А).

3) Много - многозначные связи (М:М)

Каждому экземпляру одного объекта (А) может соответствовать несколько экземпляров второго объекта (В) и наоборот, каждому экземпляру второго объекта (В) может соответствовать тоже несколько экземпляров первого объекта (А).

Много - многозначные связи не могут непосредственно реализовываться в реальной БД. Поэтому, если такие связи выявлены, может понадобиться их преобразование путем введения дополнительного объекта «связка». Исходные объекты будут связаны с этим объектом одно - многозначными связями. Т.о,, объект - связка является подчиненным в одно - многозначных связях по отношению к каждому из исходных объектов.

Объект - связка должен иметь идентификатор, образованный из идентификаторов исходных объектов, например, Ки К.

4. Этапы проектирования и создания БД

При разработке БД можно выделить следующие этапы работы.

I этап. Постановка задачи.

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

II этап. Анализ объекта.

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

III этап. Синтез модели.

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

IV этап. Выбор способов представления информации и программного инструментария.

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

В большинстве СУБД данные можно хранить в двух видах:

с использованием форм;

без использования форм.

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

V этап. Синтез компьютерной модели объекта.

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

Стадия 1. Запуск СУБД, создание нового файла базы данных или открытие созданной ранее базы.

Стадия 2. Создание исходной таблицы или таблиц.

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

При проектировании таблиц, рекомендуется руководствоваться следующими основными принципами:

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

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

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

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

Стадия 3. Создание экранных форм.

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

Стадия 4. Заполнение БД.

Процесс заполнения БД может проводиться в двух видах: в виде таблицы и в виде формы. Числовые и текстовые поля можно заполнять в виде таблицы, а поля типа МЕМО и OLE - в виде формы.

VI этап. Работа с созданной базой данных.

Работа с БД включает в себя следующие действия:

поиск необходимых сведений;

сортировка данных;

отбор данных;

вывод на печать;

изменение и дополнение данных.

Заключение

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

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

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

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

Список использованной литературы

файл серверный база программа

1. Левчук Т.А. Базы данных. Лекционный курс: Учебное пособие. - Комсомольск-на-Амуре: ГОУВПО «КнАГТУ», 2003. - 86 с.

2. А.Н. Исаченко, С.П. Бондаренко. Модели данных и СУБД. Учебное пособие.- Минск: БГУ, 2007.- 205 с.

3. Коваленко Т., Сирант О. Классификация БД и СУБД. НОУ ИНТУИТ [Электронный ресурс]. - Режим доступа http://www.intuit.ru/studies/courses/3439/681/info.

4. Алексеев Е.Г., Богатырев С.Д. Информатика. Мультимедийный электронный учебник. Проектирование и создание БД.[Электронный ресурс].- Режим доступа http://inf.e-alekseev.ru/text/Etapy_bd.html.

5. Понятие информационно-логической модели. [Электронный ресурс].- Режим доступа http://www.life-prog.ru/1_7147_ponyatie-informatsionno--logicheskoy-modeli.html.

Размещено на Allbest.ru