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

23.08.2019

Реляционная СУБД – СУБД, управляющая реляционными базами данных.

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

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

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

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

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

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

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

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

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

Пусть имеются таблицы A и B. Таблица A содержит поля a, b, c, d, из которых поле a – первичный ключ. Таблица B содержит поля x, y, z. В поле y содержится значение поля a одной из записей таблицы A. В таком случае поле y и называется внешним ключом таблицы A в таблице B.

Вот такой SQL-запрос вернёт все связанные пары записей из таблиц A и B:

select * from A, B where A.a = B.y;

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

СУБД поддерживают автоматический контроль ссылочной целостности на внешних ключах.

Виды связей таблиц

Существует три виды связей таблиц.

Связь с отношением «один-ко-многим». Является наиболее часто используемым типом связи между таблицами. В такой связи каждой записи в таблице A могут соответствовать несколько записей в таблице B, а запись в таблице B не может иметь более одной соответствующей ей записи в таблице A. Например, в одном подразделение может работать несколько сотрудников, но ни один сотрудник не может работать сразу в нескольких подразделениях. Принятое обозначение (1 – ∞).

Отношение «многие-ко-многим». При этом отношении одной записи в таблице A могут соответствовать несколько записей в таблице B, а одной записи в таблице B несколько записей в таблице A. Такая схема реализуется только с помощью третьей (связующей) таблицы, ключ которой состоит по крайней мере из двух полей, которые являются полями внешнего ключа в таблицах A и B. Например, между таблицами инспекторов и лиц, пересекающих границу, связь определяется отношением «многие-ко-многим». Один декларант может обсуживаться у нескольких инспекторов, в то же время инспектор может обслуживать несколько лиц. Такая связь определяется путем создания двух связей с отношением «один-ко-многим» для таблицы Инспектор_Декларант, в которой обязательно должны быть поля КлючИнспектора и КлючДекларанта.

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

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

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

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

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

· негибкость структуры для развивающихся БД,

· затруднения в построении концептуальной модели для объектов с многочисленными связями “многие – ко – многим”,

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

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

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

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

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

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

5. Сообщения : Взаимодействие с объектами осуществляется путем посылки сообщений с возможностью получения ответов.

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

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

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

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

Объектно-реляционными СУБД являются, к примеру, Oracle Database и PostgreSQL; разница между объектно-реляционными и объектными СУБД: первые являют собой надстройку над реляционной схемой, вторые же изначально объектно-ориентированы.

Доступ к объекту в реляционных СУБД.1) СУБД определяет страницу во внешнем устройстве хранения, содержащую требуемую запись. Используя механизмы индекса или выполняя полный просмотр таблиц. Затем СУБД считывает эту страницу из внешнего устройства хранения и копирует ее в КЕШ 2.СУБД последовательно переносит данные из КЕШа в пространство памяти приложения. При этом может понадобится выполнить преобразования типов данных SQL в типы данных приложения. Приложение может обновлять значения полей в своем пространстве памяти. 3. модифицированные приложением поля данных средствами языка SQL переносится назад в КЕШ СУБД, в процессе чего может опять потребоваться выполнить преобразование типов данных. 4. СУБД сохраняет обновленную страницу на внешнем устройстве хранения переписывая ее из КЕШа.

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

Билет №27

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

Деловая активность предприятия обычно характеризуется интенсивностью использования инвестированного (внутреннего) капитала. В производстве капитал находится в постоянном движении, переходя из одной стадии кругооборота в другую: т. е. реализуется технология Д®Т®…®П®…Т®Д". Деньги, товар

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

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

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

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

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

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

Термин «реляционный» означает, что теория основана на математическом понятии отношение (relation). В качестве неформального синонима термину «отношение» часто встречается слово таблица. Необходимо помнить, что «таблица» есть понятие нестрогое и неформальное и часто означает не «отношение» как абстрактное понятие, а визуальное представление отношения на бумаге или экране.

Для лучшего понимания РМД следует отметить три важных обстоятельства:

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

Принципы реляционной модели были сформулированы в 1969-1970 годах Э. Ф. Коддом (E. F. Codd). Идеи Кодда были впервые подробно изложены в статье «A Relational Model of Data for Large Shared Data Banks», ставшей классической.

Строгое изложение теории реляционных баз данных (реляционной модели данных) в современном понимании можно найти в книге К. Дж. Дейта. «C. J. Date. An Introduction to Database Systems» («Дейт, К. Дж. Введение в системы баз данных»).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Определение термина Банк данных дано во Временном положении о государственном учете и регистрации баз и банков данных, утвержденное постановлением Правительства Российской Федерации от 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: . Доступ по логину и паролю.

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

Структура реляционной БД.

Типы БД.

Основные возможности СУБД.

Понятие базы данных, СУБД.

План

ТЕРМИНЫ : база данных, система управления базами данных (СУБД),

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

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

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

Далее на примере одной из самых распространенных систем управления базами данных - Microsoft Access входит в состав популярного пакета Microsoft Office - мы познакомимся с основными типами данных, способами создания баз данных и с приемами работы с базами данных.

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

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

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

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

Основные возможности СУБД:

ü Обновление, пополнение и расширение БД.

ü Высокая надёжность хранения информации.

ü Вывод полной и достоверной информации на запросы.

ü Средства защиты информации в БД.

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

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

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

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

Известны три основных типа организации данных в БД и связей между ними:

· иерархический (в виде дерева),

· сетевой,

· реляционной .

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

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

Такой же БД является родовое генеалогическое древо.

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

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

· Числовой,

· Символьный (слова, тексты, коды и т.д.),

· Дата (календарные даты в форме «день/месяц/год»),

· Логический (принимает два значения: «да» - «нет» или «истина» - «ложь»).

Окно базы данных содержит следующие элементы:

ü Кнопки : «СОЗДАТЬ» , «ОТКРЫТЬ» , «КОНСТРУКТОР» и т. д. Кнопки открывают объект в определенном окне или режиме.

ü Кнопки объектов . (Корешки выбора объектов, ярлычки.) «Таблица» , «Форма» и т. д. Кнопки объектов выводят список объектов, которые могут быть открыты или закрыты.

ü Список объектов. Выводит список объектов, выбираемых пользователем. В нашем варианте список пока пуст.

Основные объекты баз данных:

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

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

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

· Отчет – объект базы данных Microsoft Access, предназначенный для печати данных.

· Макросы – автоматизируют стандартные действия.

· Модули – автоматизируют сложные операции, которые нельзя описать макросами.