Основы теории баз данных

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

Основы теории баз данных

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Реляционной база данных (РМД) реализует табличный способ. В РМД таблица называется отношением, строка -- кортежем, а столбцы -- атрибутами. Область, в которой находится подмножество возможных значений атрибута, является областью определения атрибута -- доменом. Характер таблицы (отношения) определяется не только количеством кортежей m, но и числом атрибутов n, которое определяет арность отношения. При наличии одного атрибута (n=1) отношение называется унарным, двух атрибутов (n=2) -- бинарным, трех атрибутов (n=3) -- тернарным и т.д. Основное требование к отношению РМД состоит в том, что значения атрибутов должны быть элементарной, неделимой информационной единицей, что создает возможность применения в целях обработки математического аппарата реляционной алгебры.

Следует также учитывать:

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

во-вторых, порядок следования картежей безразличен

в-третьих, отношение не может иметь двух одинаковых кортежей.

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

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

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

- сохранению смыслового содержания логической модели;

- максимальной экономии внешней памяти;

- минимизации затрат по управлению данными;

- максимальному быстродействию при поиске и при обработке запросов.

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

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

Тип данных

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

Домен

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

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

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

Кортеж, отношение

Кортеж, соответствующий данной схеме отношения, - это множество пар {имя атрибута, значение}, которое содержит одно вхождение каждого имени атрибута, принадлежащего схеме отношения. "Значение" является допустимым значением домена данного атрибута (или типа данных, если понятие домена не поддерживается). Тем самым, степень или "арность" кортежа, т.е. число элементов в нем, совпадает с "арностью" соответствующей схемы отношения. Попросту говоря, кортеж - это набор именованных значений заданного типа.

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

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

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

Реляционная база данных - это набор отношений, имена которых совпадают с именами схем отношений в схеме БД.

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

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

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

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

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

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

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

Архитектурные решения баз данных

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

- физическом размещении в памяти данных и их описаний;

- механизмах поиска запрашиваемых данных;

- проблемах, возникающих при одновременном запросе одних и тех же данных многими пользователями (прикладными программами);

- способах обеспечения защиты данных от некорректных обновлений и (или) несанкционированного доступа;

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

Существует несколько архитектурных решений баз данных

1. системы на основе архитектуры файл-сервер;

2. системы на основе архитектуры клиент-сервер;

3. системы на основе многоуровневой архитектуры;

4. системы на основе Интернет/интранет-технологий.

Архитектура файл-сервер

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

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

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

Архитектура клиент-сервер

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

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

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

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

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

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

Многоуровневая архитектура

Многоуровневая архитектура стала развитием архитектуры клиент-сервер классической форме состоит из трех уровней:

- нижний уровень представляет собой приложения клиентов и имеющие программный интерфейс для вызова приложения на среднем уровне;

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

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

Подобную концепцию обработки данных пропагандируют, в частное Oracle, Sun, Borland и др.

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

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

Интернет/интранет-технологии

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

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

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

Критерии выбора СУБД при создании информационных систем

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

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

Выделение СУБД - претендентов, подходящих по внешним ограничениям.

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

Сравнительный анализ полученных вариантов.

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

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

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

средства поддержки целостности БД,

языковые средства и их поддержка,

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

стоимость эксплуатации системы.

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

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

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

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

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

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

Для расширения информационной системы могут потребоваться новые компьютеры и новые программные системы. Поэтому СУБД должна поддерживать как общепринятые стандарты сетевого обмена (TCP/IP, DECnet, IPX/SPX, NetBIOS, SNA и т.д.), так и стандарты межпрограммных интерфейсов (ATMI, XA, ODBC).

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

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

Моделирование данных. Существует множество моделей данных [7], поэтому вопрос о применении той или иной модели должен решаться на начальном этапе проектирования АИС. К наиболее распространенным среди используемых моделей данных относятся иерархическая, сетевая, реляционная, объектно-реляционная и объектно-ориентированная.

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

Средства поиска. Ряд современных систем имеет встроенные дополнительные средства контекстного поиска.

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

Реализация языка запросов. Все современные системы совместимы со стандартным языком доступа к данным SQL-92, однако реализуют различные расширения данного стандарта.

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

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

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

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

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

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

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

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

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

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

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

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

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

Особенности архитектуры и функциональные возможности

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

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

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

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

Модели данных: иерархическая, сетевая, реляционная

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

- иерархическая;

- сетевая;

- реляционная.

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

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



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

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

Узел - информационная модель элемента, находящегося на данном уровне иерархии.

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

1. Несколько узлов низшего уровня связано только с одним узлом высшего уровня.

2. Иерархическое дерево имеет только одну вершину (корень), не подчиненную никакой другой вершине.

3. Каждый узел имеет свое имя (идентификатор).

4. Существует только один путь от корневой записи к более частной записи данных.

Достоинством модели является:

простота ее построения;

легкость понимания сути принципа иерархии;

наличие промышленных СУБД, поддерживающих данную модель.

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

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

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

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

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

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

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



Реляционная модель данных имеет следующие свойства:

- Каждый элемент таблицы - один элемент данных.

- Все поля в таблице являются однородными, т.е. имеют один тип.

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

- Одинаковые записи в таблице отсутствуют.

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

В зависимости от содержания отношения реляционные базы данных бывают:

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

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

Достоинства реляционной модели:

- простота построения;

- доступность понимания;

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

- независимость данных;

- гибкость структуры и др.

Недостатки реляционной модели:

- низкая производительность по сравнению с иерархической и сетевой моделями;

- сложность программного обеспечения;

- избыточность элементов.

Типология моделей баз данных

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

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

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

Модели данных: инфологическая, даталогическая, физическая

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

Различают внешнюю, инфологическую, логическую(даталогическую) и физическую (внутреннюю) модели данных.

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

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

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

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

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

· Логическая модель отражает логические связи между элементами данных вне зависимости от их содержания и среды хранения.

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

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

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

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

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

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

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

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

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

Существуют следующие шесть форм нормализации:

- первая нормальная форма (INF);

- вторая нормальная форма (2NF);

- третья нормальная форма (3NF);

- нормальная форма Бойса - Кодда (BCNF);

- четвертая нормальная форма (4NF);

- пятая нормальная форма, или нормальная форма проекции-соединения (5NF).

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

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

3. Транзитивная функциональная зависимость между полями А и С наблюдается в том случае, если поле В функционально зависит от поля А и поле С функционально зависит от поля В. В то же время не существует функциональной зависимости поля А от поля В.

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

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

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

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

Основы теории баз данных

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

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

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

- таблица должна содержать данные об одном типе объектов;

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

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

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

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

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

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

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

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

- языковые средства (трансляторы с языков описания данных, языков манипулирования данными, языков программирования, редакторов и отладчиков);

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

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

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

- язык определения (описания) данных БД - ЯОД - (DLL - Data Definition Language)

- язык манипулирования данными - ЯМД - (DML - Data Manipulation Language)

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

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

По степени открытости различают:

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

- замкнутые (автономные) языки (dBase, Clipper, SQL, QBE и др.), которые являются специализированными средствами работы с базами данных; по сравнению с открытыми, замкнутые языки обладают более широкими возможностями манипулирования данными, но уступают по вычислительным параметрам.

По степени алгоритмизации:

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

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

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

Современное состояние технологий баз данных

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

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