Вконтакте Facebook Twitter Лента RSS

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

Дисциплина: Информационные технологии в управлении

Тема: Классификация баз данных

Москва 2004 г.

ПЛАН


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

2. Функциональные возможности СУБД.

3. Модели описания баз данных.

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

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

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

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

По выполняемым функциям СУБД подразделяются на операционные и информационные;

По сфере применения СУБД подразделяются на универсальные и проблемно-ориентированные;

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

По числу поддерживаемых уровней моделей данных СУБД подразделяются на одно-, двух-, трехуровневые системы;

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

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

Системы централизованных баз данных с сетевым доступом предполагают две основные архитектуры – файл-сервер или клиент-сервер.

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

Архитектура клиент-сервер. Эта модель взаимодействия компьютеров в сети для современных СУБД фактически стала стандартом. Каждый из подключенных к сети и составляющих эту архитектуру компьютеров играет свою роль: сервер владеет и распоряжается информационными ресурсами системы, клиент имеет возможность пользоваться ими. Помимо хранения централизованной базы данных сервер базы данных обеспечивает выполнение основного объема обработки данных. Запрос на данные, выдаваемый клиентом (рабочей станцией), порождает поиск и извлечение данных на сервере. Извлеченные данные транспортируются по сети от сервера к клиенту. Спецификой архитектуры клиент-сервер является использование языка запроса SQL.

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

Характеристиками СУБД являются:

Производительность;

Обеспечение целостности данных на уровне баз данных;

Обеспечение безопасности данных;

Возможность работы в многопользовательских средах;

Возможность импорта и экспорта данных;

Обеспечение доступа к данным с помощью языка SQL;

Возможность составления запросов;

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

Производительность СУБД оценивается:

Временем выполнения запросов;

Скоростью поиска информации;

Временем импортирования баз данных из других форматов;

Скоростью выполнения операций (таких как обновление, вставка, удаление);

Временем генерации отчета и другими показателями.

Безопасность данных достигается:

Шифрованием прикладных программ;

Шифрованием данных;

Защитой данных паролем;

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

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

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

Наибольшее распространение в настоящее время получили системы управления базами данных Microsoft Access и Oracle.


Этапами работы в СУБД являются:

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

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

Обработка данных, содержащихся в таблицах, на основе запросов и на основе программы;

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

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

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

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


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

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

В качестве примера простой иерархической структуры можно привести административную структуру высшего учебного заведения, элементами которой являются: «Университет – Факультет – Группа». На каждом уровне иерархии данной структуры могут быть использованы различные атрибуты. Например, атрибутами третьего уровня могут быть: специализация группы, численный состав, фамилия старосты группы и другие.

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

Принципы иерархии:

Иерархия всегда начинается с корневой вершины (или главного узла);

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

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

Порожденные узлы могут встраиваться в «дерево» как в горизонтальном направлении, так и в вертикальном;

Доступ к порожденным узлам возможен только через исходный узел, поэтому существует только один путь доступа к каждому узлу.

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

Сетевая модель описывает элементарные данные и отношения между ними в виде ориентированной сети. Это такие отношения между объектами, когда каждый порожденный элемент имеет более одного исходного и может быть связан с любым другим элементом структуры. Например, в структуре управления учебным заведением порожденный элемент «Студент» может иметь не один, а два исходных элемента: «Студент – Учебная группа», и «Студент – Комната в общежитии».

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

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

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

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

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

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

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

ЛИТЕРАТУРА

1. Веретенникова Е.И., Патрушина С.М., Савельева Н.Г. Информатика: Учебное пособие. Серия «Учебный курс». – Ростов н/Д: Издательский центр «МарТ», 2002.

2. Могилев А.В. Информатика: Учеб. пособие для студ. пед. вузов / А.В. Моглиев, Н.И. Пак, Е.К. Хеннер; Под ред. Е.К. Хеннера.- 2-е изд., стер. – М.: Издательский центр «Академия», 2003.


Репетиторство

Нужна помощь по изучению какой-либы темы?

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

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

Классификация баз данных пи типу хранимых данных

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

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

Фактографические БД объединяют данные по факту совершения события (дата выпуска товара, год рождения сотрудника).

Лексикографические БД объединяют словари, классификаторы, и т.л. документы.

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

Классификация баз данных по обращению к ним

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

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

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

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

Классификация БД по способу организации данных

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

Модели БД

Моделями структурированной БД могут быть:

  • БД иерархической модели;
  • Сетевой модели;
  • И самой используемой моделью БД – реляционной базой данных.

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

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

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

Другие статьи раздела: База данных

Информация основа современного общества. Объем ее огромен и растет с каждым годом. Огромный объем информации уже давно поставил задачу ее хранения и обработки. Решает эту задачу понятие база данных. Похожие статьи:Беспроводная связь на больших расстоянияхПонятие и назначение SQL запросаМаршрутизация в компьютерных сетяхPhpMyAdmin на локальном сервереФункции СУБД обеспечивающие управление базой данныхSQL запрос INSERT INTO - наполнить […]

ЛЕКЦИЯ

Классификация БД. Фактографические и документальные БД.

БД оперативной и ретроспективной информации.

Хранилища данных. Локальные и распределенные БД. Соотношение основных требований и свойств СУБД: система компромиссов

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

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

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

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

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

По топологии хранения данных различают локальные и распределенные БД.

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

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

По сфере возможного применения можно различать универсальные и специализированные (или проблемно-ориентированные) системы.

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

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

Типология баз данных с точки зрения информационных процессов

БД могут соотноситься с различными уровнями информационных процессов: уровень информационных технологий (ИТ), уровень системы (ИС), уровень информационных ресурсов (ИР).(слайд 3)

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

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

При рассмотрении БД на уровне информационных ресурсов БД трактуется как элемент мировых ИР. Основной характеристикой здесь является содержание БД , хотя и структуры данных также немаловажны.

2.2. Фактографические и документальные БД

Главное отличие фактографических и документальных БД состоит в структуре единицы хранения информации.

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

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

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

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

Фактографические БД – БД, ориентированные на хранение хорошо структурированных данных. Единицей хранения в таких БД служит описание «факта» конечным четко определенным множеством характеристических свойств.

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

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

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

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

Отличия этих двух видов поиска представлены на слайде (слайд 5) .

При поиске данных обычно ищут полное совпадение запроса с элементом данных. При поиске данных результаты выводятся простой индукцией, например, если A и B , то C . Поиск информации намного ближе к методам дедукции: отношения описываются только степенью уверенности или неуверенности. В информационном поиске, как правило, стратегия поиска построена по принципу усечения первоначальных результатов поиска, что и приводит к логике «от общего к частному». Из этого следует детерминистское описание модели поиска данных и вероятностная модель информационного поиска.

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

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

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

2.3. БД оперативной и ретроспективной информации. Хранилища данных

С точки зрения основных особенностей ПрО и решаемых задач можно выделить два основных класса БД – оперативной и ретроспективной информации.

БД оперативной информации являются основой так называемых OLTP -приложений (Оп- Line Transactions Processing ) . Типичными примерами OLTP -приложений являются системы складского учета, системы заказов билетов, банковские системы, выполняющие операции по переводу денег, и т. п. Основная функция подобных систем заключается в одновременном выполнении большого количеств коротких транзакций – завершенных блоков операций манипулирования данными, например: "снять некоторую сумму де нег со счета А и добавить эту сумму на счет В", "продать пассажиру билет на заданный поезд на заданное место на определенную дату". Завершенность транзакции означает, что при возникновении ошибки транзакция должна целиком откатиться и вернуть БД к состоянию, которое было до начала транзакции (не должно быть ситуации, когда деньги сняты со счета А , но не поступили на счет В ).

Основные особенности OLTP -приложений:

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

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

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

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

БД ретроспективной информации входят в состав документальных ИС, ориентированных на задачи информационного поиска, а также в OLAP -приложения (Оп- Line Analitical Processing , оперативная аналитическая обработка данных). Это обобщенный термин, характеризующий принципы построения систем поддержки принятия решений (DSS , Decision Support System ), а также хранилищ данных (data warehouse ) и систем интеллектуального анализа данных (data mining ). Такие системы предназначены для установления зависимостей меж ду данными (например, можно попытаться определить, как связан объем продаж товаров с характеристиками потенциальных покупателей) или для проведения анализа, отвечающего на вопросы "что если...".

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

1. Добавление в БД новых данных происходит относительно редко крупными блоками.

2. Данные из БД обычно никогда не удаляются.

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

4. Скорость выполнения запросов важна, но не критична.

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

Хранилища данных

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

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

Хранилище данных - предметно-ориентированный, интегрированный, привязанный ко времени и неизменяемый набор данных, предназначенный для под­ держки принятия решений.

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

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

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

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

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

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

Сравнение систем OLTP и хранилищ данных

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

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

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

· Недооценка ресурсов, необходимых для загрузки данных : многие разработчики склонны недооценивать время, необходимое для извле чения, очистки и загрузки данных в хранилище.

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

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

· Повышение требований конечных пользователей

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

· Высокие требования к ресурсам : может потребоваться огромный объем дискового про­странства.

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

· Сложное сопровождение : любая реорганизация деловых процессов или источников данных может отразиться на работе хранилища данных

· Долговременный характер проектов

· Сложности интеграции

Локальные и распределенные БД

В общем случае режимы работы с БД можно классифицировать по следующим признакам:

- многозадачность- однопользовательский или многопользовательский;

- правило обслуживания запросов – последовательное или параллельное;

- схема размещение данных – централизованная или распределенная БД.

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

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

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

Соотношение основных требований и свойств СУБД: система компромиссов(слайд 10)

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

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

2). Каким образом организовать данные, чтобы была возможность эффективного внесения, удаления и редактирования данных.

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

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

Создание базы данных - это по существу попытка найти компромисс сразу по нескольким направлениям и сочетаниям нескольких взаимообратных факторов (с точки зрения их влияния на показатель общей эффективности системы), в том числе, следующих(слайд 11) :

1) Эффективность – простота;

2) Скорость выборки – стоимость (сложность) аппаратных средств;

3) Скорость выборки – сложность процедур доступа;

4) Плотность данных – время доступа и сложность процедур;

5) Независимость данных – производительность;

6) Гибкость средств поиска – избыточность данных или

7) Гибкость поиска – скорость поиска;

8) Сложность процедур доступа – простота обслуживания.

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

Терминология

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

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

Виды БД

В теории различают несколько их видов. Бывают:

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

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

БД - это табличка?

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

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

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

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

Связи между таблицами

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

  • "Один-к-одному" - каждой записи таблицы соответствует только одна запись из другой таблички.
  • "Один-ко-многим" и "многие-ко-многим". Одной записи может соответствовать сразу несколько из связанной таблицы. И наоборот (для второго варианта).
  • "Многие-ко-многим". Уже нетрудно догадаться, что в этом случае для нескольких строк может быть подобрано для связи несколько строк другой таблицы (такая связь организовывается при помощи промежуточной таблицы и двух связей вышеуказанного вида).

Движение вверх и вниз

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

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

Расширяем связи

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

Табличный способ отображения

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

Объектно-ориентированный тип

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

База данных

Например:

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

тах, представленные в строго определенном формате.

Документальные

)

Хранилище информации процедура ввода

поиск – процесс обработки запроса;

обработка

выдача информации

Централизованная БД –

По структуре организации базы данных делятся на

Реляционными базами данных называются базы данных с табличной формой организации.

В реляционных БД строка таблицы называется записью, а столбец - полем. В общем виде это выглядит так:

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

ОСНОВНЫЕ ТИПЫ ДАННЫХ

текстовый одна строка текста (до 255 символов)
поле MEMO текст, состоящий из нескольких строк, который можно
посмотреть при помощи полос прокрутки (до 65535 символов)
числовой число любого типа (можно использовать в вычислениях)
денежный поле, выраженное в денежных единицах (рубли, доллары и т.д.)
дата/время поле, содержащее дату или время
счётчик поле, которое вводится автоматически с вводом каждой записи
логический содержит одно из значений True (истина) или False (ложно) и применяется в логических операциях
поле объекта OLE содержит рисунки, звуковые файлы, таблицы Excel, документ Word и т. д.

Банк данных

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

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

2.Понятие БД, СУБД, ИС. Примеры использования и сферы применения баз данных

База данных (БД ) - это структурированные знания об объектах.

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

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

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

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

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

основное назначение БД - “постоянное применение”. Говоря о применении БД, необходимо упомянуть о понятии информационная система (ИС).

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

Ядром, “сердцем” ИС как раз и является БД. Разумеется, ИС бывают достаточно сложными, в том числе и построенными на нескольких базах данных, но сути это не меняет - БД в принципе можно представить себе как нечто автономное, но невозможно представить ИС, не основанную на БД.

Структура базы данных

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

принято выделять базы данных следующих видов:иерархические , сетевые , реляционные и объектно-ориентрованные .

Ключи

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

7. Виды связей между таблицами в Реляционной модели БД

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

Существует 4 типа связей:

1. «Один-к-одному» - любому экземпляру сущности А соответствует только один экземпляр сущности В, и наоборот.

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

2. «Один-ко-многим» - любому экземпляру сущности А соответствует 0, 1 или несколько экземпляров сущности В, но любому экземпляру сущности В соответствует только один экземпляр сущности А.

Ученику ставят много оценок; поставленная оценка принадлежит только одному ученику.

3. «Многие-к-одному» - любому экземпляру сущности А соответствует только один экземпляр сущности В, но любому экземпляру сущности В соответствует 0, 1 или несколько экземпляров сущности А.

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

Какая же разница между связями «один-ко-многим» и «многие-к-одному»? Такая же, как между фразами «портфель ученика» и «ученик портфеля». То есть важно, кто во взаимоотношении двух объектов главный - ученик или портфель. Суть отношений двух объектов отражается в имени связи.

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

4. «Многие-ко-многим» - любому экземпляру сущности А соответствует 0, 1 или несколько экземпляров сущности В, и любому экземпляру сущности В соответствует 0, 1 или несколько экземпляров сущности А.

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

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

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

Первая нормальная форма

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

Первая нормальная форма предписывает, что все данные, содержащиеся в таблице, должны быть атомарными (неделимыми ).

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

Так как значение поля Оценки не является атомарным, таблица не соответствует требованиям 1НФ.

Вторая нормальная форма

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

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

Приведем пример таблицы, которая не находится во 2НФ.

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

Здесь уместно задаться вопросом: а в чем практический смысл 2НФ? Какая польза от этих ограничений? Оказывается - большая. Допустим, что в приведенном выше примере разработчик проигнорирует требования 2НФ. Во-первых, скорее всего возникнет так называемая избыточность - хранение лишних данных. Ведь если для одной записи с данной датой уже хранится время восхода, то для всех других записей с данной датой оно должно быть таким же и хранить его, вообще говоря, незачем.

Третья нормальная форма

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

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

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

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

Четвертая нормальная форма

Отношение находится в четвертой нормальной форме , если оно находится в третьей нормальной форме и если в нем не содержатся независимые группы атрибутов, между которыми существует отношение «многие-ко-многим».

В теории реляционных баз данных рассматриваются и формы высших порядков - нормальная форма Бойса - Кодда, 4НФ, 5НФ и даже выше. Большого практического значения эти формы не имеют, и разработчики, как правило, всегда останавливаются на 3НФ.

Индексация

Индексация - крайне важная с точки зрения практического применения.

Основное назначение индексации - оптимизация (убыстрение) поиска (и, соответственно, некоторых других операций с базой данных).

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

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

Типы данных

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

Все реляционные СУБД поддерживают данные следующих основных типов:

· числовые;

· строковые;

· логические;

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

Отметим также, что, как правило, типы могут снабжаться модификаторами, уточняющими соответствующее множество данных (диапазон значений). Например, в Microsoft Access данные числового типа могут быть просто “целыми”, “длинными целыми”, “вещественными” и т.д. - см. рисунок.

11.Правила Кодда (требования к реляционным БД)

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

Перечислим эти правила:

1) Явное представление данных.

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

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

2) Гарантированный доступ к данным.

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

а) имени отношения;

б) указателя на кортеж (например, значение первичного ключа кортежа);

в) имени атрибута;

(имя_отношения, первичный ключ, атрибут)

3) Полная обработка неопределенных значений.

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

4) Доступ к базе данных в терминах реляционной модели.

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

5) Полнота подмножества реляционного языка.

Реляционная схема может поддерживать несколько языков, по крайней мере, язык DDL и DML. Однако хотя бы один из языков должен иметь синтаксис предложений, поддерживающий следующие понятия:

Определение данных (отношения, атрибуты, домены, ключи, ограничения целостности);

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

Манипулирование данными (интерактивное или программное);

Ограничение целостности;

Санкционированный доступ;

Управление транзакциями (начало транзакции, фиксация выполнения, отказ от выполнения).

6) Обновляемость представлений.

Все представления (виртуальные отношения) должны автоматически обновляться при модификации данных в базовых отношениях. Если, например, A= R È S, и А – это представление, то А должно обновляться как только меняется R или S.

7) Наличие высокоуровнего языка манипулирования данными.

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

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

8) Физическая независимость данных.

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

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

9) Логическая независимость данных.

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

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

10) Независимость контроля целостности.

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

11) Дистрибутивная независимость.

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

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

12) Согласования языковых уровней.

Если реляционная система имеет низкоуровневый язык доступа (элемент доступа – запись) и высокоуровневый язык доступ (элемент доступа – отношения). То выполнение низкоуровневых команд должно производиться с контролем целостности, так же как и при высокоуровневых командах.

12.Формализация даталогической модели на языке конкретной СУБД(на примере Ассess)

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

· Определение имени таблицы. Если таблица является представлением некоторой сущности, то имя обычно соответствует названию сущности. Имена таблиц связей, как правило, образуют из названий связываемых сущностей.

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

· Определение первичного ключа. Несмотря на то, что реляционная модель требует наличия в каждой таблице первичного ключа, большинство СУБД позволяют не определять ключ в таблице. Этого, разумеется, следует избегать. К чести СУБД они практически всегда стараются “наставить разработчика на путь истинный” (см., например, рисунок).

· Определение (при необходимости) индексированных полей .

После конструирования таблиц необходимо установить связи между ними. В Microsoft Access для этого имеется специальное средство - “Схема данных”. На схеме очень удобно “рисовать” связи между таблицами, перетаскивая и накладывая друг на друга связанные поля. В большинстве случаев Access способен определить тип устанавливаемой связи. Например, если первичный ключ одной таблицы связывается с полем другой, не являющимся первичным ключом, то легко понять - и Access понимает, - что речь идет о связи “один ко многим”.

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

Какой бы визуальный интерфейс не предоставляла конкретная СУБД разработчикам, в подавляющем большинстве случаев за кадром находится общий для всех реляционных СУБД язык SQL (S tructured Q uery L anguage ).

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

13.Объекты базы данных . Таблицы, отчеты, страницы, макросы и модули . Запросы и формы .

Таблицы – основные объекты любой БД, в которых хранятся все данные, имеющиеся в базе, и хранится сама структура базы (поля, их типы и свойства).

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

Страницы или страницы доступа к данным – специальные объекты БД, выполненные в коде HTML , размещаемые на web -странице и передаваемые клиенту вместе с ней. Сам по себе объект не является БД, посетитель может с ее помощью просматривать записи базы в полях страницы доступа. Т.о., страницы – интерфейс между клиентом, сервером и базой данных, размещенным на сервере.

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

Запросы и формы .

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

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

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

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

14.Язык SQL (структурированный язык запросов ) .История возникновения. Подмножества языка.

Из истории SQL:

Все реляционные СУБД поддерживают специальный язык SQL (S tuctured Q ueryL anguage ), на котором записываются запросы. Фактически SQL состоит из двух языков - DML (D ata M anipulation L anguage ) и DDL (D ata D eclaration L anguage ).

История языка SQL началась в 1974 г. Первый прототип языка назывался SEQUEL (название образовано от S tructured E nglish Que ry L anguage ). Впоследствии переработанная версия SEQUEL получила название SQL. Первый стандарт языка был принят в 1987 г.

SQL - декларативный язык. Это означает, что клиент лишь указывает, что именно ему требуется, а как это получить, решает сама СУБД.

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

  • SQL-DDL (Data Definition Language) - язык определения структур и ограничений целостности баз данных. Сюда относятся команды создания и удаления баз данных; создания, изменения и удаления таблиц; управления пользователями и т.д.
  • SQL-DML (Data Manipulation Language) - язык манипулирования данными: добавление, изменение, удаление и извлечение данных, управления транзакциями

Базы данных. Виды БД по характеру хранимой информации, по способу хранения, по структуре организации. Основные типы данных.

База данных - организованная совокупность данных, предназначенная для длительного хранения во внешней памяти ЭВМ и постоянного применения

Например:

База данных книжного фонда библиотеки;

База данных кадрового состава учреждения;

База данных законодательных актов в области уголовного права;

База данных современной эстрадной песни.

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

В фактографических БД содержатся краткие сведения об описываемых объек-

тах, представленные в строго определенном формате.

Например, в БД библиотеки о каждой книге хранятся библиографические сведе-

Документальные

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

(например, различные справочники, словари)

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

Хранилище информации – база данных железнодорожной станции; процедура ввода – ввод паспортных данных клиента;

поиск – процесс обработки запроса;

обработка – выбор клиентом даты и времени отправления поезда;

выдача информации – ваш заказ принят, билет забронирован

Централизованная БД –

БД хранится на одном компьютере

Распределённая БД –различные части одной БД хранятся на мно-

жестве компьютеров, объединённых между собой сетью

© 2024 Про уют в доме. Счетчики газа. Система отопления. Водоснабжение. Система вентиляции