Основные положения реляционной модели БД. Реляционная субд

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

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

Замечание. О выборе СУБД. Выбор СУБД относится к многокритериальной задаче выбора и в настоящем курсе не рассматривается. Следует помнить о том, что СУБД обычно поддерживает только одну модель данных: реляционную, иерархическую, сетевую, многомерную, объектно-ориентированную, объектно-реляционную. Исключение составляют небольшое число СУБД. Например, ADABAS, Software AG (сетевая и реляционная модели), или Oracle 9i, Oracle Inc. (реляционная и объектно-реляционная модели). Обычно при выборе СУБД при всех прочих равных возможностях стараются создать базу данных на СУБД, претендующей на промышленный стандарт.

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

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

Замечание. В контексте лекции атрибуты, колонки, столбцы и поля считаются синонимами. То же относится и к терминам "строка", "запись" и "кортеж".

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

Рис. 8.1.

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

Основные объекты реляционной базы данных

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

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

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

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

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

Далее объекты реляционной базы данных будут вводиться в контексте реляционной СУБД Oracle 9i. Такой подход принят потому, что проектирование физической модели реляционной базы данных выполняется для конкретной среды ее реализации.

В Oracle 9i термин схема (Schema) используется для описания всех объектов базы данных, которые созданы некоторым пользователем. Для каждого нового пользователя автоматически создается новая схема.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Хранимая процедура ( Stored procedure ) - это объект базы данных, представляющий поименованный набор команд SQL и/или операторов специализированных языков обработки программирования базы данных (например, SQLWindows или PL/SQL).

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

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

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

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

Пакет (Package) - это объект базы данных, который состоит из поименованного структурированного набора переменных, процедур и функций.

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

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

Связь базы данных (Database Link) или связь с удаленной базой данных - это объект базы данных, который позволяет обратиться к объектам удаленной базы данных. Имя связи базы данных, грубо говоря, можно представить как ссылку на параметры доступа к удаленной базы данных.

Для эффективного управления разграничением доступа к данным в Oracle поддерживает объект роль.

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

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

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

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

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

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

Централизованное управление данными имеет преимущества по сравнению с обычной файловой системой:

— сокращение избыточности хранения данных;

— сокращение трудоемкости разработки, эксплуатации и модернизации ИС;

Обеспечение удобного доступа к данным как пользователям

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

Основные требования, предъявляемые к БнД:

— адекватность отображения предметной области (полнота, целостность и — непротиворечивость данных, актуальность информации;

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

— дружелюбность интерфейсов, малое время на обучение;

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

— надежность хранения и защита данных.

Определение термина Банк данных дано во Временном положении о государственном учете и регистрации баз и банков данных, утвержденное постановлением Правительства Российской Федерации от 28.02.96 № 226, п.2 (СЗ РФ, 1996, № 12, ст. 1114)

Первоначально (начало 60-х годов) использовалась файловая система хранения. Для решения преимущественно инженерных задач, характеризующихся небольшим количеством данных и значительным объемом вычислений, данные хранились непосредственно в программе. Применялся последовательный способ организации данных, имелась их высокая избыточность, идентичность логической и физической структур и полная зависимость данных. С появлением экономико-управленческих задач (информационная система руководства — MIS), отличающихся большими объемами данных и малой долей вычислений, указанная организация данных оказалась неэффективной. Требовалось упорядочение данных, которое, как выяснилось, возможно было проводить по двум критериям: использование (информационные массивы); хранение (базы данных). Первоначально применяли информационные массивы, но вскоре стало ясно превосходство баз данных. Использование файлов для хранения только данных было предложено Мак Гри в 1959 году. Были разработаны методы доступа (в том числе произвольного) к таким файлам, при этом физическая и логическая структуры уже различались, а физическое расположение данных можно было менять без изменения логического представления.

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

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

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

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

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

СУБД организует хранение информации таким образом, чтобы ее было удобно:

просматривать,

пополнять,

изменять,

искать нужные сведения,

делать любые выборки,

осуществлять сортировку в любом порядке.

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

а) по характеру хранимой информации:

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

Документальные (архивы)

б) по способу хранения данных:

Централизованные (хранятся на одном компьютере),

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

в) по структуре организации данных:

Табличные (реляционные),

Иерархические,

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

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

Популярные СУБД — FoxPro, Access for Windows, Paradox. Для менее сложных применений вместо СУБД используются информационно-поисковые системы (ИПС), которые выполняют следующие функции:

хранение большого объема информации;

быстрый поиск требуемой информации;

добавление, удаление и изменение хранимой информации;

вывод ее в удобном для человека виде.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Понятие реляционный (англ. relation - отношение) связано с разработками известного английского специалиста в области систем баз данных Эдгара Кодда (Edgar Codd).

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

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

– каждый элемент таблицы - один элемент данных;

– все столбцы в таблице однородные, то есть все элементы в столбце имеют одинаковый тип (числовой, символьный и т. д.);

– каждый столбец имеет уникальное имя;

– одинаковые строки в таблице отсутствуют;

– порядок следования строк и столбцов может быть произвольным.

Базовыми понятиями реляционных СУБД являются: 1) атрибут; 2) отношения; 3) кортеж.

База данных, таким образом, это ни что иное, как набор таблиц. RDBS и ориентированные на записи системы организованы на основе стандарта B-Tree или методе доступа, основанном на индексации – Indexed Sequential Access Method (ISAM) и являются стандартными системами, использующимися в большинстве современных программных продуктов. Для обеспечения комбинирования таблиц для определения связей между данными, которые практически полностью отсутствуют в большинстве программных реализаций B-Tree и ISAM, используется языки, подобные SQL (IBM), Quel (Ingres) и RDO (Digital Equipment), причем стандартом отрасли в настоящее время стал язык SQL, поддерживаемый всеми производителями реляционных СУБД.

Оригинальная версия SQL – это интерпретируемый язык, предназначенный для выполнения операций над базами данных. Язык SQL был создан в начале 70х как интерфейс для взаимодействия с базами данных, основанными на новой для того времени реляционной теории. Реальные приложения обычно написаны на других языках, генерирующих код на языке SQL и передающих их в СУБД в виде текста в формате ASCII. Нужно отметить также, что практически все реальные реляционные (и не только реляционные) системы помимо реализации стандарта ANSI SQL, известного сейчас в последней редакции под именем SQL2 (или SQL-92), включают в себя дополнительные расширения, например, поддержка архитектуры клиент-сервер или средства разработки приложений.

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

Чтобы однозначно определить элемент, ему должны быть сопоставлены поле или набор полей, гарантирующих уникальность элемента внутри таблицы. Такое поле или поля называются первичным ключом (primary key) таблицы и часто являются числами. Если одна таблица содержит первичным ключ другой, это позволяет организовать связь между элементами разных таблиц. Это поле называется внешним ключом (foreign key).

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

Несмотря на рассмотренные недостатки реляционных баз данных, они обладают рядом достоинств:

разделение таблиц разными программами;

развернутый «код возврата» при ошибках;

высокая скорость обработки запросов (команда SELECT языка SQL; результатом выборки является таблица, которая содержит поля, удовлетворяющие заданному критерию);

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

относительно высокая скорость при работе с большими объемами данных.

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

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

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

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

Объектно-реляционные адаптеры, такие как Odapter компании Hewlett-Packard для СУБД Oracle, можно с успехом использовать во многих областях, например в качестве связующего ПО, объединяющего объектно-ориентированные приложения с реляционными СУБД.

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

Производительность в рассмотренных двух подходах зависит от способа доступа к реляционной базе данных. Каждая РСУБД состоит из двух уровней: уровня управления данными (data manager layer) и уровня управления носителем (storage manager layer). Первый из них обрабатывает операторы на языке SQL, а второй отображает данные в базу. Шлюз или адаптер могут взаимодействовать как с уровнем данных (то есть обращаться к РСУБД при помощи SQL), так и с уровнем носителя (вызовами процедур низкого уровня). Производительность в первом случае намного ниже (например, система OpenODB фирмы Hewlett-Packard, которая может выполнять роль шлюза, поддерживает только на высоком уровне).

Гибридные СУБД – е ще одним решением может стать создание гибридных объектно-реляционных СУБД, которые могут хранить и традиционные табличные данные, и объекты. Многие аналитики считают, что будущее за такими гибридными БД. Ведущие поставщики реляционных СУБД начинают (или планируют) добавлять к своим продуктам объектно-ориентированные средства. В частности, Sybase и Informix собираются в следующих версиях СУБД ввести поддержку объектов. Подобные разработки намерены вести и независимые фирмы. Например, компания Shores готовится оснастить объектно-ориентированными средствами СУБД Oracle8, выпуск которой намечен на конец 1996 г.

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

1.3 Многомерные базы данных

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

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

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

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

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

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

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

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

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

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

Еще к недостаткам MOLAP-моделей можно отнести:

не позволяют работать с большими БД. На сегодняшний день их реальный предел – 10-20 гигабайт. К тому же за счет денормализации и предварительно выполненной агрегации 20 гигабайт в многомерной базе, как правило, соответствуют (по оценке Кодда) в 2.5-100 раз меньшему объему исходных детализированных данных, то есть в лучшем случае нескольким гигабайтам.

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

отсутствуют единые стандарты на интерфейс, языки описания и манипулирования данными

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

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

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

время ответа системы на нерегламентированные запросы является наиболее критичным параметром.

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

2. Практическая часть

2.1 Постановка задачи

2.1.1 Цель решения задачи

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

Цель решения данной задачи состоит в своевременности расчетов стоимости работ для оперативного предоставления подробно составленного счета клиентам.

2.1.2 Условие задачи

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

Наименование работы	Единицы измерения	Объем выполняемых работ		Стоимость работ, руб.
		Q i	C і	S i

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

Прайс-лист

Наименование работы	Цена за единицу продукции, руб.

Латинские буквы в таблице указывают на элементы соответствующих расчетных формул.

В результате следует получить счет со следующими реквизитами: наименование работы, цена за единицу продукции (руб.), объем выполняемых работ, стоимость работы (руб.), № счета (заполняется автоматически). ФИО клиента и дата вписываются вручную. Информация выдается в следующих документах:

Структура результирующего документа «Счет»

	ООО «Стройсервис»
	СЧЕТ №
				Дата		20__
			ФИО клиента
	№ п/п		Наименование работы		Единицы измерения	Объем выполняемых работ		Цена за единицу продукции, руб.	Стоимость работ, руб.
			Замена батарей		шт.
			Наклейка обоев		м 2
			Замена труб
			Настилка паркета		м 2
	ИТОГО:								ΣS i
	НДС:								N
	СУММА С НДС:								SN
		Гл. бухгалтер

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

В технологии организовать межтабличные связи для автоматического формирования документа «Счет» при помощи функций ВПР или ПРОСМОТР.

2.2. Компьютерная модель решения задачи

2.2.1. Информационная модель решения задачи

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

2.2.2. Аналитическая модель решения задачи

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

стоимость работ, руб.;


НДС, руб.;


сумма с НДС, руб..


Расчеты выполняются по следующим формулам:


S i = C i ∙Q i ,


N = ΣS i ∙ 0,18,


SN = ΣS i + N,


где S i
- стоимость i -й работы; C i
- цена за i -ю единицу продукции; Q i - обїем выполняемой i -й работы; N - НДС; SN - сумма с НДС.


2.2.3. Технология решения задачи MS Excel


Решение задачи средствами MS Excel


Вызовите Excel:


нажмите кнопку «Пуск»;


выберите в главном меню команду «Программы»;


в меню Microsoft Office выберите MS Excel.

Переименуйте «Лист 1» в «Прайс-лист»:

выберите в контекстном меню команду «Переименовать» и нажмите левую кнопку мыши;


нажмите клавишу «Enter».

Введите заголовок таблицы «Прайс-лист»:

наберите на клавиатуре «Прайс-лист»;


4. Отформатируйте заголовок:





Рис. 2. Пример выделения группы ячеек


на панели инструментов в закладке «Главная» выберите раздел «Выравнивание» и нажмите кнопку .


5. Отформатируйте ячейки А2:B2 под ввод длинных заголовков:


выделите ячейки А2:B2;


выполните команду «Выравнивание» в разделе «Формат ячеек» меню «Главная» на панели инструментов;


выберите закладку «Выравнивание»;


в группе опций «Отображение» установите флажок опции «переносить по словам» (рис. 3);





Рис. 3. Задание переноса слов при вводе в ячейку длинных


заголовков


нажмите кнопку «ОК».


6. Введите в ячейки А2:B2 информацию, представленную на рис. 4.





Рис. 4. Имена полей таблицы «Прайс-лист»


7. Отформатируйте ячейки А3:A8 для ввода текстовых символов:


выделите ячейки А3:A8;


на панели инструментов в меню «Главная» выберите «Ячейки», где в пункте «Формат» выполните команду «Формат ячеек»;


выберите закладку «Число»;


выберите формат «Текстовый» (рис. 5);


нажмите кнопку «ОК».





Рис. 5. Выбор формата ячеек


8. Повторите п. 9 для диапазона ячеек B3:B8, выбрав формат «Числовой».


9. Введите исходные данные (рис. 6).





Рис. 6. Вид таблицы «Прайс-лист»


10. Присвойте имя группе ячеек:


выделите ячейки А3:В8;


выберите команду «Присвоить имя» в разделе «Определенные имена» меню «Формулы» (рис. 7);





Рис. 7. Вид окна «Создание имени»


нажмите кнопку «ОК.».


11. Переименуйте «Лист 2» в «Расчет стоимости работ» (аналогично действиям п. 2).


12. Создайте таблицу «Расчет стоимости выполняемых работ» (аналогично действиям пунктов 3 — 7, 8) (рис. 8).





Рис. 8. Вид таблицы «Расчет стоимости работ»


13. Заполните графы «Наименование работы» и «Цена за единицу продукции, руб.»:


сделайте ячейку А3 активной;


в меню «Данные» выберите команду «Проверка данных», в поле «Тип данных» которой выберите «Список»;


введите значение в поле «Источник», выделив диапазон A3:A8 в «Прайс-лист» (рис. 9);





Рис. 9. Настройка списка плательщиков


нажмите кнопку «ОК»;


для того чтобы ввод наименования работы из списка осуществлялся в каждой ячейке столбца А («Наименование работы»), сделайте ячейку А3 активной и, установив курсор на маркер в правом нижнем углу, щелкните левой клавишей мыши и протяните его до ячейки А6 (рис. 10);





Рис. 10. Вид листа «Расчет стоимости работ» при настройке списка


в поле «Выберите функцию» нажмите «ВПР» (рис. 11);





Рис. 11. Вид первого окна мастера функций


нажмите кнопку «OK»;


введите наименование работы в поле «Искомое_значение», щелкнув по ячейке А3;


нажмите «Enter»;


введите информацию в поле «Таблица»;


воспользуйтесь командой «Использовать в формуле» меню «Формулы», выбрав «Вставить имена»;


выделите «Имя:» «Прайс_лист» (рис. 12);





Рис. 12. Ввод имени массива в качестве аргумента формулы


нажмите кнопку «OK»;


нажмите «Enter»;


введите информацию — цифру 2 в поле «Номер_столбца»;


введите информацию — цифру 0 в поле «Интервальный_просмотр» (рис. 13);





Рис. 13. Вид второго окна мастера функций


Нажмите кнопку «ОК»;


14. Заполните графу «Объем выполняемых работ».


15. Введите наименования работ в ячейки А4:А6:


Сделайте ячейку А4 активной;


Щелкните на кнопку рядом с ячейкой А4 и из предложенного списка выберите наименование работ — Замена батарей, шт. Ячейка С4 — «Цена за единицу продукции, руб.» будет заполнена автоматически (рис. 14);





Рис. 14. Автоматическое заполнение Цены за единицу продукции по ее наименованию


аналогично заполните ячейки А5:А6, ячейки С5:С6 будут также заполнены автоматически.


16. Заполнить графу «Стоимость работы, руб»
таблицы «Расчёт стоимости выполняемых работ».
Для этого:


занести в ячейку D3 формулу =B3*C3;


размножить введённую в ячейку D3 формулу для остальных ячеек D4:D6 данной графы (с помощью функции автозаполнения).


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


17. Заполненная таблица выглядит следующим образом (рис. 15).





Рис. 15. Результат заполнения таблицы «Расчеты стоимости работ»


18. Переименуйте «Лист 3» в « Счет» (аналогично действиям п. 2).


19. На рабочем листе «Счет» создайте необходимую таблицу, рукодствуясь предшествующими пунктами.


20. С помощью функции ПРОСМОТР() создайте межтабличные связи. Однако перед этим отсортируйте значения таблицы «Расчеты стоимости выполняемых работ» в порядке возрастания по столбцу «Наименование работ». Для этого:


выделите диапазон ячеек А2:D6;


выберите пункт «Сортировка и фильтр» на Главной, а там «Настраиваемая сортировка»;


в выпавшем окне выберите «Сортировать по» «Наименованию работ»;


нажмите кнопку «ОК».


воспользуйтесь командой «Вставить функцию» меню «Формулы»;


в поле «Выберите функцию» нажмите «ПРОСМОТР»;


нажмите кнопку «OK»;


введите наименование работы в поле «Искомое_значение», щелкнув по ячейке С9;


нажмите «Enter»;


введите информацию в поле «Просматриваемый вектор», а именно ‘Расчет стоимости работ’!$A$3:$A$6;


нажмите «Enter»;


введите информацию в поле «Искомый вектор», а именно ‘Расчет стоимости работ’!$С$3:$С$6;


нажмите «Enter» (рис. 16);





Рис. 16. Вид второго окна мастера функции ПРОСМОТР


нажмите кнопку «ОК»;


22. Повторите действия, аналогичные п. 22 для ячеек D9:D12, E9:E12.


23. Заполнить графу «ИТОГО» таблицы следующим образом:


занести в ячейку F13 формулу =СУММ(F9:F12) .


24. Заполните графу «НДС». Для этого занести в ячейку F14 формулу =F13*0,18.


25. Заполните графу «СУММА С НДС». Для этого занести в ячейку F15 формулу =F13+F14 .


26. В результате у Вас должна получиться таблица, пркдставленная на рис. 17.





Рис. 17. Форма счета на оплату выполненных работ


27. Для анализа информации о стоимости каждого вида работ по полученному заказу:


сделайте активным лист «Счет»;


выделите диапазон C9:F12;


выберите команду «Гистограмма» в разделе «Диаграммы» меню «Вставка»;


выберите необходимый тип гистограммы;


переименуйте гистограмму в «Cтоимость каждого вида работ» (рис. 18).





Рис. 18. Гистограмма «Стоимость каждого вида работ»


2.3. Результаты компьютерного эксперимента и их анализа


2.3.1. Результаты компьютерного эксперимента


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


Прайс-лист
Наименование работы	Цена за единицу продукции, руб.
Замена ванны, шт.
Замена труб, м
Наклейка обоев, м2
Настилка паркета, м2
Побелка потолка, м2

Расчет стоимости выполняемых работ
Наименование работы	Объем выполняемых работ	Цена за единицу продукции, руб.	Стоимость работы, руб.
Замена батарей, шт.			1000
Замена труб, м
Наклейка обоев, м2			1400
Настилка паркета, м2			1200

	ООО «Строй-дизайн»
	СЧЕТ №
		Дата		. .20
		ФИО клиента
	№ п/п	Наименование работы	Объем выполняемых работ	Цена за единицу продукции, руб.		Стоимость работ, руб.
		Замена батарей, шт.				1000
		Наклейка обоев, м2				1400
		Замена труб, м
		Настилка паркета, м2				1200
	ИТОГО:					4560
	НДС:					820,8
	СУММА С НДС:					5380,8

В результате решения задачи полученные с помощью компьютера ведомости совпадают с тестовыми.


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


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


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


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


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


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


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


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


В практической части была решена средства MS Excel 2010 поставленная задача в отношении условного предприятия – фирмы ООО «Строй-дизайн», которая осуществляет деятельность, связанную с выполнением работ по ремонту помещений. Были построены таблицы по приведенным данным в задании. Выполнен расчет стоимости работ по полученному заказу, данные расчета занести в таблицу. Организованы межтабличные связи с использованием функций ВПР или ПРОСМОТР для автоматического формирования счета, выставляемого клиенту для оплаты выполняемых работ. Сформирован и заполнен документ «Cчет на оплату выполненных работ». Приведены результаты расчета стоимости каждого вида работ по полученному заказу представить в графическом виде.


Компьютерная обучающая программа по дисциплине Информатика» / А.Н. Романов, В.С. Торопцов, Д.Б. Григорович, Л.А. Галкина, А.Ю. Артемьев, Н.И. Лобова, К.Е. Михайлов, Г.А. Жуков, О.Е. Кричевская, С.В. Ясеновский, Л.А. Вдовенко, Б.Е. Одинцов, Г.А. Титоренко, Г.Д. Савичев, В.И. Гусев, С.Е. Смирнов, В.И. Суворова, Г.В. Федорова, Г.Б. Коняшина. – М.: ВЗФЭИ, 2000. Дата обновления 24.11.2010. – Доступ по логину и паролю.


Компьютерная обучающая программа по дисциплине «Информационные системы в экономике» / А.Н. Романов, В.С. Торопцов, Д.Б. Григорович, Л.А. Галкина, А.В. Мортвичев, Б.Е. Одинцов, Г.А. Титоренко, Л.А. Вдовенко, В.В. Брага, Г.Д. Савичев, В.И. Суворова. – М.: ВЗФЭИ, 2005. Дата обновления 15.10.2010. – URL: . Доступ по логину и паролю.


СУБД ПОНЯТИЕ И ВИДЫ МОДЕЛЕЙ БАЗ ДАННЫХ СБОР ДАННЫХ СОЦИОЛОГИЧЕСКОГО ХАРАКТЕРА С ИСПОЛЬЗОВАНИЕМ ТЕХНОЛОГИЙ БАЗ ДАННЫХ. СОЗДАНИЕ ТАБЛИЦ И ФОРМ БД 2013-11-05

Основные сведения о БД. Понятия: БД, Предметная область, Структурирование данных, Системы управления БД.

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

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

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

Структурирование данных – соглашение о способе представления данных.

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

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

· управление данными во внешней памяти (на дисках);

· управление данными в оперативной памяти с использованием дискового кэша;

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

· поддержка языков БД (язык определения данных, язык манипулирования данными).

Обычно современная СУБД содержит следующие компоненты:

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

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

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

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

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

По модели данных

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

· Сетевые

· Иерархические

· Реляционные

· Объектно-реляционные

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

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

· локальные СУБД (все части локальной СУБД размещаются на одном компьютере)

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

2. Классификация БД по способу доступа к данным .

По способу доступа к БД

Файл-серверные

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

На данный момент файл-серверные СУБД считаются устаревшими.

Примеры: Microsoft Access, Borland Paradox.

Клиент-серверные

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

Примеры: Firebird, Interbase, MS SQL Server, Sybase, Oracle, PostgreSQL, MySQL.

Встраиваемые

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

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

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

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

Правила для атрибутов сущности:

· Каждый атрибут должен иметь уникальное имя.

· Сущность может обладать любым количеством атрибутов.

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

· Для каждого экземпляра сущности должно существовать значение каждого его атрибута (правило необращения в нуль - Not Null).

· Ни один из экземпляров сущности не может обладать более чем одним значением для ее атрибута.

При построении БД:

1. определяем ЦЕЛЬ

2. определяем функции

Внешний уровень – то, что надо представить в структурированном виде;

Концептуальное проектирование – информационные объекты выстраиваются и связываются друг с другом + внешний уровень

3. преобразовываем концептуальную модель в модель БД.

Связи между объектами:

1:1, 1:ко многим, многие ко многим.

Модели данных

· Сетевые

· Иерархические

· Реляционные

· Объектно-реляционные

· Объектно-ориентированные \

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

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

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

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

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

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

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

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

Реляционная: Понятие реляционный (англ. relation - отношение) связано с разработками известного английского специалиста в области систем баз данных Эдгара Кодда (Edgar Codd).

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

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

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

· все столбцы в таблице однородные, то есть все элементы в столбце имеют одинаковый тип (числовой, символьный и т. д.)

· каждый столбец имеет уникальное имя

· одинаковые строки в таблице отсутствуют

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

Базовыми понятиями реляционных СУБД являются: 1) атрибут 2) отношения 3) кортеж

Реляционная модель БД

Реляционная модель данных - это множество взаимосвязанных двумерных таблиц. Каждая таблица содержит сведения об однородных объектах базы данных и обладает следующими свойствами:

Каждый элемент таблицы представляет собой один элемент данных;

Элементы одного столбца однородны;

Каждый столбец имеет уникальное имя;

Таблица не содержит двух и более одинаковых строк;

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

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

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

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

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

Объединение таблиц с одинаковой структурой. Результат – общая таблица: сначала первая, затем вторая (конкатенация).

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

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

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

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

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

Таблицы реляционной БД должны отвечать требованиям нормализации отношений.

Логические функции

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

Запросы QBE на выборку.

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

Простой запрос на выборку;

Запрос с параметром;

Запрос с итогами;

Запрос перекрестный;

Запрос с вычисляемым полем.

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

Бланк простого запроса содержит шесть строк:

Имя поля;

Имя таблицы;

Сортировка;

Вывод на экран (указывает, будет ли поле присутствовать в динамическом наборе данных);

Условие отбора (содержит первое условие, ограничивающее набор данных);

Или (содержит другие условия ограничения данных).

Разработка простого запроса выполняется в несколько этапов:

Выбор таблицы;

Выбор полей (добавление полей в запрос);

Установление критериев отбора;

Задание порядка расположения записей (сортировка).

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

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

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

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

Выполнить команду ЗАПРОС/Перекрестный;

В строке Перекрестная таблица указать, какое поле используется в качестве заголовков строк, какое – в качестве заголовков столбцов и какое - для выполнения вычислений в соответствии с выбранной групповой операцией;

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

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

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

Чтобы создать запрос с параметром, необходимо в строку Условия отбора для заданного поля ввести текст приглашения для ввода данного, заключив его в прямоугольные скобки. Можно задать параметры для нескольких полей или для одного поля определить несколько параметров для отбора, используя запись условия в несколько строк совместно с логической операцией «ИЛИ».

Запросы QBE - действия.

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

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

Существует 4 типа запросов на изменение:

- запрос на добавление;

- запрос на обновление;

- запрос на удаление;

- запрос на создание таблицы.

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

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

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

Отменить свойство Вывод на экран для полей запроса;

Выполнить команду ЗАПРОС/Добавление – для пре­обра­зо­вания в запрос на добавление. При этом в бланке запроса появляется строка Добавление. Далее необходимо включить в бланк запроса поля, данные которых будут добавляться в принимающую таблицу. Можно ввести также условия отбора записей для добавления.

Указать имя таблицы, куда будут добавляться записи;

Выполнить команду ЗАПРОС/Запуск.

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

Технология создания других типов запросов - действий аналогична.

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

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

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

Типы форм

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

Форма в столбец или полноэкранная форма;

Ленточная форма;

Табличная форма;

Форма главная / подчиненная;

Сводная таблица;

Форма - диаграмма.

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

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

Табличная форма отображает данные в режиме таблицы.

Форма главная/подчиненная представляет собой совокуп­ность формы в столбец и табличной. Ее имеет смысл создавать при работе со связанными таблицами, в которых установлена связь типа «один-ко-многим».

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

Форма с диаграммой. В Access в форму можно вставить диаграмму, созданную Microsoft Graph. Graph является внедряемым OLE приложением и может быть запущен из Access. С внедренной диаграммой можно работать так же, как и с любым объектом OLE.

Конструирование форм

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

Способ создания формы;

Источник данных (из списка).

Access предлагает следующие способы создания формы:

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

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

3. С помощью конструктора форм. Форма конструируется пользователем в окне конструктора форм.

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

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

Структура формы

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

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

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

3. Область данных. Область данных содержит поля, в которых отображаются данные.

4. Нижний колонтитул. Содержимое области нижнего колонтитула (дата, № страницы и т.д.) отображаются на каждой экранной странице в нижней части формы.

5. Примечание формы. Содержимое этой области выводится внизу последней экранной страницы формы.

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

Свойства формы

Как любой объект Access, форма имеет свойства. Значения этих свойств определяют внешний вид формы. Окно "Свойства" формы можно вызвать, например, щелкнув правой клавишей мыши по черному квадрату на пересечении линеек и из контекстного меню выбрать команду СВОЙСТВА.

Окно свойств выделенного объекта содержит следующие вкладки:

Макет – свойства, задающие макет формы;

Данные – свойства, определяющие источник данных, тип данных, формат и т.д.;

События – перечень событий, связанных с объектом;

Все – перечень всех свойств.

Основные свойства формы:

Подпись (это свойство расположено на вкладке МАКЕТ) – задает название формы, которое выводится в строку заголовка в окне формы.

Режим по умолчанию – определяет режим открытия формы (простая форма, ленточная, таблица).

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

все – можно;

таблица – нельзя, возможен только просмотр в режиме таблицы;

форма – нельзя, возможен только просмотр в режиме формы.

Разрешить изменение определяет, можно ли через форму изменять данные, т.е. задает статус "Только для чтения".

Разрешить удаление определяет, может ли пользователь удалять данные через форму.

Разрешить добавление определяет, может ли пользователь добавлять записи через форму.

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

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

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

Полосы прокрутки;

Кнопка оконного меню;

Кнопка размеров окна;

Кнопка закрытия окна;

Тип границы окна;

Кнопка контекстной справки.

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

Элементы управления формой

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

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

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

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

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

Основными элементами управления являются:

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

Свободная надпись используется для задания заголовков, комментариев. Создается кнопкой "Надпись" панели инструментов.

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

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

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

Добавление свободного поля в форму выполняется кнопкой "Поле" панели элементов. Добавление присоединенного поля (связанного с полем таблицы) осуществляется в режиме конструктора следующим образом:

На панели "Конструктор форм" выбирается кнопка "Список полей";

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

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

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

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

Для отображения заданного состояния можно ввести его значение по умолчанию. если это значение не задано, то элемент будет находиться в состоянии Null, что соответствует значению Ложь.

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

Управляющие элементы Флажок и Выключатель могут использоваться не только в группе, но и индивидуально.

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

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

Аналогичным образом может использоваться и элемент управления Выключатель.

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

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

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

Основные свойства списков:

1. Тип источника данных: таблица / запрос; список значений; список полей; функция VBA.

2. Источник данных – указывает фактический источник данных: для таблицы / запроса – имя таблицы / запроса; для списка значений – значения элементов списка через «;» (например, Пол – м;ж).

3. Присоединенный столбец – поле базовой таблицы, к которому присоединен список.

4. Число столбцов – количество столбцов в списке. Если источником данных является список значений, то элементы распределяются из списка по строкам и столбцам.

5. Ширина столбца – задается числовым значением через «;». Можно скрыть присоединенный столбец списка, если он содержит несколько столбцов. Для этого нужно установить ширину столбца равной 0. Значение не отображается при выводе списка, однако при выборе строки, значение из присоединенного столбца попадает в поле базовой таблицы.

6. Число строк – определяет максимальное число строк, отображаемое в поле со списком.

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

Кнопка создается мастером. Мастер позволят создать кнопки 30 разных типов и связывает их с процедурами обработки событий. Свойство Подпись определяет текст на кнопке. Свойство Рисунок определяет рисунок на кнопке.

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

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

Можно изменять размеры элемента Набор вкладок, порядок следования и названия вкладок.

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

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

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

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

Создать подчиненную форму можно:

Добавив элемент Подчиненная форма в форму;

Перетащив форму из окна базы данных в другую открытую форму;

Мастером подчиненных форм.

Структура отчета

Основные разделы отчета:

Заголовок отчета – печатается в начале отчета на титульной странице, содержит название отчета;

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

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

Область данных – печатается каждая запись из источника данных;

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

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

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

Конструирование отчета

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

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

1). Находясь на вкладке ОТЧЕТЫ нажать кнопку СОЗДАТЬ.

2). В окне Новый отчет:

Выбрать инструмент Автоотчет в столбец;

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

Нажать ОК.

Технология создания многоколончатого отчета:

1). Создать простой отчет в столбец.

2). Выбрать в меню ФАЙЛ команду Параметры страницы. В диалоговом окне Параметры страницы выбрать вкладку Столбцы и задать:

В группе Параметры сетки число столбцов, которые должны выводиться на каждой странице (поле Число столбцов), ширину межстрочного интервала (поле Интервал), расстояние между столбцами (поле Столбцов);

В группе Размер столбца ширину столбца (поле Ширина) и высоту строки (поле Высота);

В начало

Базы данных и СУБД

Информационные системы

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

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

Хранение данных и их защита;

Изменение (обновление, добавление и удаление) хранимых данных;

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

Обработка данных и вывод результатов.

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

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

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

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

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

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

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

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

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

Файловые системы

Развитие основных понятий представления данных

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

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

- вычислительные задачи – достаточно простое представление данных и сложный процесс вычислений;

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

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

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

Недостатки файловых систем

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

2. Проблемы с авторизацией доступа. Можно использовать средства ОС по разграничению доступа. Такое решение возможно, но неудобно. Нужны централизованные методы доступа к информации.

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

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

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

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

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

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

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

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

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

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

4. Защита логической целостности базы данных.

5. Защита физической целостности.

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

7. Синхронизация работы нескольких пользователей.

8. Управление ресурсами среды хранения.

9. Поддержка деятельности системного персонала.

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

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

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

4. Защита логической целостности базы данных.

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

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

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

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

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

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

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

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

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

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

7. Синхронизация работы нескольких пользователей .

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

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

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

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

8. Управление ресурсами среды хранения .

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

9. Поддержка деятельности системного персонала .

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

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

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

По характеру использования СУБД делят на персональные (СУБДП) и многопользовательские (СУБДМ).

К персональным СУБД относятся Visual FoxPro , Paradox , Clipper , dBase , Access и др. К многопользовательским СУБД относятся, например, СУБД Oracle и Informix . Многопользовательские СУБД включают в себя сервер БД и клиентскую часть, работают в неоднородной вычислительной среде - допускаются разные типы ЭВМ и различные операционные системы. Поэтому на базе СУБДМ можно создать информационную систему, функционирующую по технологии клиент-сервер. Универсальность многопользовательских СУБД отражается соответственно на высокой цене и компьютерных ресурсах, требуемых для их поддержки.

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

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

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

- управление данными во внешней памяти;

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

- управление транзакциями.

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

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

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

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

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

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

Поддержка функционирования в сети обеспечивается:

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

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

Поддержка взаимодействия с Windows-приложениями позволяет СУБДП внедрять в отчет сведения, хранящиеся в файлах, созданных с помощью других приложений, например, в документе Word или в рабочей книге Excel , включая графику и звук. Для этого в СУБДП поддерживаются механизмы, разработанные для среды Windows , такие как: DDE { Dynamic Data Exchange - динамический обмен данными) и OLE { Object Linking and Embedding - связывание и внедрение объектов).

Уровни представления данных

Современные подходы к созданию БД предполагают их трёхуровневую организацию. Этот способ организации БД был предложен American National Standards Institute (ANSI ) и используется повсеместно.

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

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

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

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

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

Классификация моделей данных

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

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

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

Рис.1 Модели данных

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

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

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

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

Даталогические модели

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

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

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

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

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

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

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

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

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

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

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

Основные принципы сетевой модели данных были сформулированы в середине 60-х годов. Эталонный вариант сетевой модели данных описан в отчетах рабочей группы по языкам баз данных CODASYL (COnference on DAta SYstem Languages) в середине 70-х годов.

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

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

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

Основные понятия и определения реляционной модели

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

В 1970 году Е.Ф. Кодд (E . F . Codd ) представил реляционную модель БД. Концепция этой модели основана на том, что организация данных в базе должна быть гибкой, динамичной, легко используемой. Пользователь должен работать только с логическим представлением данных, а уж система управления БД позаботится о физической структуре данных. Кодд сформулировал основные положения реляционных баз данных.

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

· база данных должна состоять из таблиц и только из таблиц. Только содержимое таблиц определяет операции БД;

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

В своём документе Кодд описал язык для оперирования с реляционными структурами. Со временем этот язык превратился в то, что сейчас называют структурированным языком запросов SQL (Structured Query Language ).

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

В правилах Кодда можно выделить 4 категории:

1) базовые возможности – описание данных и язык программирования;

2) доступ к данным – правила доступа, хранения и поиска,

3) гибкость – правила изменения (модификации) данных;

4) целостность – правила для обеспечения качества и защищённости данных.

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

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

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

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

Отношение на доменах D1, D2, ..., Dn (не обязательно, чтобы все они были различны) состоит из заголовка и тела.

Заголовок состоит из такого фиксированного множества атрибутов A1, A2, ..., An, что существует взаимно однозначное соответствие между этими атрибутами Ai и определяющими их доменами Di (i=1,2,...,n).

Тело состоит из меняющегося во времени множества кортежей , где каждый кортеж состоит в свою очередь из множества пар атрибут-значение (Ai:Vi), (i=1,2,...,n), по одной такой паре для каждого атрибута Ai в заголовке. Для любой заданной пары атрибут-значение (Ai:Vi) Vi является значением из единственного домена Di, который связан с атрибутом Ai.

Степень отношения – это число его атрибутов. Отношение степени один называют унарным, степени два – бинарным, степени три – тернарным, ..., а степени n – n-арным. Степень отношения

Кардинальное число или мощность отношения – это число его кортежей. Кардинальное число отношения изменяется во времени в отличие от его степени.

Поскольку отношение – это множество, а множества по определению не содержат совпадающих элементов, то никакие два кортежа отношения не могут быть дубликатами друг друга в любой произвольно-заданный момент времени. Пусть R – отношение с атрибутами A1, A2, ..., An. Говорят, что множество атрибутов K=(Ai, Aj, ..., Ak) отношения R является возможным ключом R тогда и только тогда, когда удовлетворяются два независимых от времени условия:

1. Уникальность: в произвольный заданный момент времени никакие два различных кортежа R не имеют одного и того же значения для Ai, Aj, ..., Ak.
2. Минимальность: ни один из атрибутов Ai, Aj, ..., Ak не может быть исключен из K без нарушения уникальности.

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

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

Отношение – Таблица (иногда Файл),
Кортеж – Строка (иногда Запись),
Атрибут – Столбец, Поле.

При этом принимается, что «запись» означает «экземпляр записи», а «поле» означает «имя и тип поля».

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

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

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

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

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

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

Ключи

Реляционная теория требует, чтобы данные унифицировались уникально по трём критериям:

· таблицей, где хранится этот элемент данных;

· названием поля в этой таблице;

· значением первичного ключа для записи.

Первичный ключ – это поле или группа полей, которые гарантируют уникальность записи.

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

Построение первичного ключа является обязательным. Данные часто имеют естественный ключ (natural key ). Например, номер социального страхования идентифицирует любого налогоплательщика США; банки выдают номера счетов своим клиентам; больницы присваивают пациентам номера в картотеке. Всё это – номер социального страхования, счёт в банке, номер в картотеке – лучшие кандидаты на роль первичного ключа, поскольку они уникально идентифицируют налогоплательщиков, клиентов и пациентов соответственно.

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

Если данные не содержат естественного первичного ключа, то он должен быть создан. Существуют две школы, которые предлагают разные способы создания искусственного ключа (artifical key ).

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

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

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

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

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

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

Индексы

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

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

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

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

Рис. 3. Пример индекса по полю «номер телефона».

Связи

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

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

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

Наиболее распространён тип связи одна-ко-многим . Например, клиент и заказы: один клиент может сделать много заказов. Поля, по которым осуществляются связи, не являются свободными, то есть не могут иметь произвольные значения. Например, в заказе должен быть упомянут клиент, который есть в таблице «Клиенты». С точки зрения таблицы «Клиенты» поле «ФИО клиента» может быть произвольным, так как не зависит от полей других таблиц.

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

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

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

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

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

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

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

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

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

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

* ограничения, для реализации которых созда1тся триггер;

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

Использование триггеров при проектировании БД даёт следующие преимущества:

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

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

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

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

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

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

Коммерческие СУБД ведут свою историю с середины 60-х годов, когда компанией IBM был выпущен первый продукт данного класса – иерархическая СУБД IMS. В начале 70-х годов Эдгаром Коддом были заложены основы реляционной модели данных, был разработан структурированный язык запросов SQL, а в 80-х годах были созданы промышленные СУБД, которые в скором времени заняли доминирующее положение. В настоящее время ведущая тройка игроков – Microsoft, Oracle и IBM – полностью контролируют рынок, а их флагманские продукты Microsoft SQL Server, Oracle Database и IBM DB2 вместе занимают долю рынка около 90%. Рынок СУБД активно растет и, по мнению аналитиков Forrester, к 2013 году его общий объем достигнет 32 млрд долл.

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

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

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

Поскольку постреляционная модель использует многомерные структуры, позволяющие хранить в полях таблицы другие таблицы, ее еще называют "не первой нормальной формой" или "многомерной базой данных". В качестве языка в данной модели запросов используется расширенный SQL, позволяющий извлекать сложные объекты из одной таблицы без операций соединения. Можно сказать, что реляционные и постреляционные СУБД различаются способами хранения и индексирования данных, во всем остальном они схожи. Первыми постреляционными СУБД, получившими достаточно большую известность, стали Universe компании Ardent (впоследствии купленной Informix, которую, в свою очередь, приобрела IBM) и ADABAS компании Software AG.

Объектно-реляционные СУБД

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

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

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

Зачастую постреляционными называют также СУБД, которые позволяют представлять данные как в виде реляционных таблиц, так и классов объектов. Типичным представителем данного вида СУБД является система Cache компании InterSystems. По словам ее разработчиков, в данной системе наиболее эффективно совмещены реляционный и объектный подходы, основанные, соответственно, на стандартах SQL-92 и ODMG 2.0. Механизмы работы с объектами и реляционными таблицами находятся на одном логическом уровне, что обеспечивает более высокую скорость доступа и работы с данными и функциональную полноту. Также Cache использует многомерную модель хранения данных и оптимизирована для обработки транзакций в системах с большими и сверхбольшими БД (сотни гигабайт, терабайты) и большим количеством (тысячи, десятки тысяч) одновременно работающих пользователей, при этом позволяя получать очень высокую производительность.

Перспективы развития

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

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

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

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

Максим Никитин