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

ЛИЧНЫЙ КАБИНЕТ 

 

Здравствуйте гость!

 

Логин:

Пароль:

 

Запомнить

 

 

Забыли пароль? Регистрация

Повышение оригинальности

Предлагаем нашим посетителям воспользоваться бесплатным программным обеспечением «StudentHelp», которое позволит вам всего за несколько минут, выполнить повышение оригинальности любого файла в формате MS Word. После такого повышения оригинальности, ваша работа легко пройдете проверку в системах антиплагиат вуз, antiplagiat.ru, РУКОНТЕКСТ, etxt.ru. Программа «StudentHelp» работает по уникальной технологии так, что на внешний вид, файл с повышенной оригинальностью не отличается от исходного.

Результат поиска


Наименование:


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

Информация:

Тип работы: контрольная работа. Добавлен: 03.05.2013. Год: 2013. Страниц: 20. Уникальность по antiplagiat.ru: < 30%

Описание (план):


ВВЕДЕНИЕ
 
Для оперативного, гибкого и эффективного управления предприятиями, фирмами  и организациями различных форм собственности, телекоммуникационными  средствами гражданского и военного назначения, информационно-вычислительными, экологическими, радиолокационными и радионавигационными системами широко внедряются системы автоматизированного управления, ядром которых являются базы данных (БД). При большом объеме информации и сложности производимых с ней операций проблема эффективности средств организации хранения, доступа и обработки данных приобретает особое значение.
Конец XX — начало XXI в. характеризуются  активным внедрением в деятельность человечества компьютерных информационных технологий, особенно систем управления базами данных (СУБД). СУБД — это  программные системы управления структурированными файлами данных, обеспечивающих пользователю оперативное получение необходимой информации.
В соответствии с основными этапами  проектирования базы данных после построения концептуальной модели выбирается система  управления базой данных, с помощью которой будет организована база данных и работа с ней. Каждая СУБД поддерживает определенные виды и типы данных, а также средства представления связей между данными, составляющими модель данных СУБД. Именно это обуславливает актуальность исследования моделей представления данных.
Важность и значимость баз данных в современной жизни определяют серьезные требования, предъявляемые  к квалификации специалистов, создающих  приложения на их основе.
 
 
 
1. БАЗЫ ДАННЫХ
 
1.1. Понятие базы данных (БД)
 
Основы современной информационной технологии составляют базы данных (БД) и системы управления базами данных (СУБД), роль которых как единого  средства хранения, обработки и доступа  к большим объемам информации постоянно возрастает. При этом существенным является постоянное повышение объемов информации, хранимой в БД, что влечет за собой требование увеличения производительности таких систем. Резко возрастает также в разнообразных применениях спрос на интеллектуальный доступ к информации. Это особенно проявляется при организации логической обработки информации в системах баз знаний, на основе которых создаются современные экспертные системы.
База данных – средство организации  хранения и управления большим количеством  упорядоченной разнородной информации. Обычно её характеризует жёсткая внутренняя структура и взаимосвязь между отдельными элементами хранящихся данных. Работая с базой данных, пользователь абстрагируется от конкретного способа их физического хранения на компьютере.
И вместо того, чтобы иметь дело с большим количеством отдельных файлов, например, текстовых, табличных и графических, мы оперируем единым интерфейсом, посредством которого добавляем новые записи, редактируем или удаляем уже имеющиеся. Кроме того, база данных подразумевает наличие механизма генерации аналитических отчётов, который избавляет пользователя от расчёта каких-либо сложных показателей вручную и поиска необходимых фрагментов в различных файлах.
В базе данных предприятия, например, может храниться: вся информация о штатном расписании, о рабочих и служащих предприятия; сведения о материальных ценностях; данные о поступлении сырья и комплектующих; сведения о запасах на складах; данные о выпуске готовой продукции; приказы и распоряжения дирекции и т.п.
Даже небольшие изменения какой-либо информации могут приводить к значительным изменениям в разных других местах.
Пример. Издание приказа о повышении  в должности одного работника  приводит к изменениям не только в  личном деле работника, но и к изменениям в списках подразделения, в котором он работает, в ведомостях на зарплату, в графике отпусков и т.п.
Организация структуры БД формируется  исходя из следующих соображений:
1. Адекватность описываемому объекту/системе  — на уровне концептуальной  и логической модели.
2. Удобство использования для ведения учёта и анализа данных — на уровне так называемой физической модели.
На уровне физической модели электронная  БД представляет собой файл или их набор в формате TXT, CSV, Excel, DBF, XML либо в специализированном формате конкретной СУБД. Также в СУБД в понятие физической модели включают специализированные виртуальные понятия, существующие в её рамках — таблица, табличное пространство, сегмент, куб, кластер и т. д.
Хорошая модель и правильный проект базы данных формируют основу информационной системы. Построение слоя данных - часто первый критичный шаг в направлении создания новой системы, который правомерно требует внимания к деталям и тщательного планирования. База данных, как и любая компьютерная система, является моделью небольшой части реального мира. И, как любая модель, это - узкое представление, которое значительно упрощает сложность реальной вещи. Современные системы баз данных основываются на реляционной модели хранения и извлечения данных.
 
 
1.2. Понятие системы управления базами данных (СУБД)
 
Система управления базами данных (СУБД) — это система программного обеспечения, позволяющая обрабатывать обращения  к базе данных, поступающие от прикладных программ конечных пользователей. Системы  управления базами данных позволяют  объединять большие объемы информации и обрабатывать их, сортировать, делать выборки по определённым критериям и т.п.
Современные СУБД – это многопользовательские  системы управления базой данных, которые специализируется на управлении массивом информации одним или множеством одновременно работающих пользователей. Они имеют развитый пользовательский интерфейс, который позволяет вводить и модифицировать информацию, выполнять поиск и представлять информацию в графическом или текстовом режиме, дают возможность включать звуковые фрагменты и даже видеоклипы.
СУБД обеспечивают правильность, полноту  и непротиворечивость данных, а также  удобный доступ к ним. Простота использования  СУБД позволяет создавать новые  базы данных, не прибегая к программированию, а пользуясь только встроенными функциями.
К числу функций СУБД принято  относить следующие:
1. Непосредственное управление  данными во внешней памяти.
Эта функция включает обеспечение  необходимых структур внешней памяти как для хранения данных, непосредственно  входящих в БД, так и для служебных целей, например, для убыстрения доступа к данным в некоторых случаях (обычно для этого используются индексы). В некоторых реализациях СУБД активно используются возможности существующих файловых систем, в других работа производится вплоть до уровня устройств внешней памяти. СУБД поддерживает собственную систему именования объектов БД.
2. Управление буферами оперативной  памяти.
СУБД обычно работают с БД значительного  размера; по крайней мере, этот размер обычно существенно больше доступного объема оперативной памяти. Понятно, что если при обращении к любому элементу данных будет производиться обмен с внешней памятью, то вся система будет работать со скоростью устройства внешней памяти. Практически единственным способом реального увеличения этой скорости является буферизация данных в оперативной памяти. В развитых СУБД поддерживается собственный набор буферов оперативной памяти с собственной дисциплиной замены буферов.
3. Управление транзакциями.
Транзакция - это последовательность операций над БД, рассматриваемых СУБД как единое целое. Либо транзакция успешно выполняется, и СУБД фиксирует (COMMIT) изменения БД, произведенные этой транзакцией, во внешней памяти, либо ни одно из этих изменений никак не отражается на состоянии БД. Понятие транзакции необходимо для поддержания логической целостности БД.
4. Журнализация.
Одним из основных требований к СУБД является надежность хранения данных во внешней памяти. Под надежностью  хранения понимается то, что СУБД должна быть в состоянии восстановить последнее согласованное состояние БД после любого аппаратного или программного сбоя.
Поддержание надежности хранения данных в БД требует избыточности хранения данных, причем та часть данных, которая  используется для восстановления, должна храниться особо надежно. Наиболее распространенным методом поддержания такой избыточной информации является ведение журнала изменений БД.
5. Поддержка языков БД.
Для работы с базами данных используются специальные языки, в целом называемые языками баз данных. В современных  СУБД обычно поддерживается единый интегрированный язык, содержащий все необходимые средства для работы с БД, начиная от ее создания, и обеспечивающий базовый пользовательский интерфейс с базами данных. Стандартным языком наиболее распространенных в настоящее время реляционных СУБД является язык SQL (Structured Query Language).
Обычно современная СУБД содержит следующие компоненты:
    ядро, которое отвечает за управление данными во внешней и оперативной памяти и журнализацию,
    процессор языка базы данных, обеспечивающий оптимизацию запросов на извлечение и изменение данных и создание, как правило, машинно-независимого исполняемого внутреннего кода,
    подсистему поддержки времени исполнения, которая интерпретирует программы манипуляции данными, создающие пользовательский интерфейс с СУБД
    а также сервисные программы (внешние утилиты), обеспечивающие ряд дополнительных возможностей по обслуживанию информационной системы.
Быстрое развитие потребностей применений БД выдвигает новые требования к  СУБД:
    поддержка широкого спектра типов представляемых данных и операций над ними (включая фактографические, документальные, картинно-графические данные);
    естественные и эффективные представления в БД разнообразных отношений между объектами предметных областей (например, пространственно-временных с обеспечением визуализации данных);
    поддержка непротиворечивости данных и реализация дедуктивных БД;
    обеспечение целостности БД в широком диапазоне разнообразных предметных областей и операционных обстановок;
    управление распределенными БД, интеграция неоднородных баз данных;
    существенное повышение надежности функционирования БД.
1.3. Классификация баз данных
 
Многообразие характеристик и  видов баз данных порождает многообразие классификации. Рассмотрим основные виды классификации.
По технологии обработки данных базы данных подразделяются на централизованные и распределенные.
Централизованная база данных хранится в памяти одной вычислительной системы, к которой подключены несколько  других компьютеров.
Распределенная база данных состоит  из нескольких, возможно пересекающихся или даже дублирующих друг друга частей, хранимых в различных ПК компьютерной сети. Работа с такой базой осуществляется с помощью системы управления распределенной базой данных (СУРБД).
По способу доступа к данным базы данных подразделяются на базы данных с локальным доступом и базы данных с удаленным (сетевым) доступом.
Системы централизованных баз данных с сетевым доступом предполагают различные архитектуры подобных систем:
Файл – сервер. Согласно этой архитектуре в компьютерной сети выделяется машина – сервер для хранения файлов централизованной базы данных. Файлы базы данных могут быть переданы на рабочие станции для обработки: ввода, корректировки, поиска записей. При большой интенсивности доступа к одним и тем же файлам производительность системы падает. В этой системе сервер и рабочие станции должны быть реализованы на достаточно мощных компьютерах.
На данный момент файл – серверные  СУБД считаются устаревшими.
Примеры: Microsoft Access, Borland Paradox.
Клиент – сервер – архитектура, используемая не только для хранения файлов централизованной базы данных на сервере, но и выполняющая на том же сервере основной объем работы по обработке данных. Таким образом, при необходимости поиска информации в базе данных рабочим станциям – клиентам передаются не файлы данных, а уже записи, отобранные в результате обработки файлов данных. Такая архитектура позволяет использовать маломощные компьютеры в качестве рабочих станций, но обязательно в качестве сервера используется очень мощный компьютер.
Примеры: Firebird, Interbase, MS SQL Server, Sybase, Oracle, MySQL,
PostgreSQL.
Прежде чем создавать базу данных, с которой вам придется работать, необходимо выбрать модель данных, наиболее удобную для решения  поставленной задачи.
Модель данных – совокупность структур данных и операций их обработки.
С помощью модели данных могут быть представлены объекты предметной области  и взаимосвязи между ними. Модели данных, которые поддерживают СУБД, а, следовательно, и сами СУБД делят  на:
      иерархические;
      сетевые;
      реляционные;
      файловые.
 
 
 
 
 
 
 
 
 
 
 
2. МОДЕЛИ ПРЕДСТАВЛЕНИЯ  ДАННЫХ В СУБД
 
2.1. Файловая модель представления данных
 
Исторически первыми системами  хранения и обработки данных на ЭВМ  была файловая организация данных. При такой модели внутримашинная система размещения данных представляет собой совокупность не связанных между собой обычных компьютерных файлов из однотипных записей с линейной (одноуровневой) структурой.
Основные компоненты структуры  данных файловой модели - поле, запись, файл (рис. 2.1).

Рис. 2.1. Логическая структура данных в файловых БД.
Поле - элементарная единица логической организации данных, которая соответствует  отдельной, неделимой единице информации - реквизиту.
Запись - совокупность полей, соответствующих логически связанным реквизитам. Структура записи определяется составом и последовательностью входящих в нее полей, каждое из которых содержит элементарные данные.
Файл - множество одинаковых по структуре  экземпляров записей.
Агрегат - несколько функционально  связанных нолей данных.
Так, поли со значениями года, месяца и дня можно рассматривать  как некоторый агрегат.
Экземпляр записи представляет собой  описание некоторого конкретного объекта  типовой структуры.
Допустим, надо создать БД файлового  типа, содержащую сведения о сотрудниках некоторой организации (табл. 2.1). Тогда в качестве отдельной записи будет рассматриваться информация каждой из строк табл. 2.1, в качестве k-го поля - данные k-го столбца в соответствующей строке (т.е. первое поле каждой записи будет содержать номер отдела, второе - фамилию, третье - год рождения и  т.д.). Таким образом, БД будет содержать 7 записей одного типа, каждая из 6 полей.
Табл. 2.1. База данных файлового типа, содержащую сведения о сотрудниках
Отдел
Должность
10
Иванов
1949
Нач. отдела
05 03 072072
1
10
Поддубный
1971
Ст. инспектор
05 03 072081
2
20
Петров
1972
Вед. инспектор
02 78 123123
3
20
Кац
1953
Нач. отдела
12 34 034123
4
20
Могильный
1961
Инспектор
03 06 035321
5
30
Иванов
1971
Инспектор
02 35 088456
6
30
Ковтун
1953
Нач. отдела
05 03 178098
7

 
В принципе в файловой БД могут  быть записи нескольких типов, различающихся  числом и составом полей. Тогда каждый тип записей организуется в свой файл.
Ключи для выбора записей.
Выбор из БД записей, необходимых пользователю, требует формирования соответствующего запроса. Этот запрос выполняется с помощью ключа. Поэтому для выбора нужной информации необходимо задать значение ключа, т.е. указать значение ноля (палей) ключа. После этого СУБД ищет записи, в которых поле ключа имеет заданное значение.
В общем случае ключи записи бывают двух видов: первичный и вторичный.
Первичный ключ - это одно или несколько  полей, однозначно идентифицирующих запись.
Первичный ключ позволяет для его  любого значения всегда находить в БД не более одной записи. Например, для данных, представленных в табл. 2.1, первичным ключом будет поле <Паспорт>. Если задать любое допустимое значение этого поля, то всегда будет выбрана только одна запись. Так, при задании значения <12 34 034123> будет выбрана запись № 4.
Вторичный ключ - это одно или несколько  полей, значение которых может повторяться  в нескольких записях файла.
Такой ключ используется, когда указанному в запросе требованию в БД могут  соответствовать несколько записей. Допустим, нам надо выбрать сотрудников, родившихся в некотором году. Для рассматриваемого выше примера поле <Год рождения> будет вторичным ключом, так как для значения ключа «1953» в БД будет найдено две записи: № 4 и № 7.
Если ключ состоит из одного поля, то называется простым, если из нескольких полей - составным.
Базы данных, в основе которых  лежит файловая организация данных, до сих пор довольно широко используются. Однако оказалось, что они обладают серьезными недостатками. Основная проблема состоит в том, что файлы независимы и могут иметь повторяющиеся данные. Повторение данных в разных файлах приводит, во-первых, к избыточному объему, во вторых, усложняется процесс редактирования, так как одинаковые поля надо изменять в нескольких файлах, а при этом можно ошибиться. Кроме того, одни и те же данные могут размещаться в полях с разными именами, что приводит к проблемам выбора логически связанных записей из нескольких файлов.
Следует отметить, что файловые модели не предполагают установления связей между файлами, что и явилось одной из причин появления специальных прикладных программ, получивших название СУБД.
 
 
 
2.2. Иерархическая и сетевая модели представления данных
 
Более сложными моделями по сравнению  с файловыми являются иерархические  и сетевые модели, которые предполагают, что БД содержит описания совокупности взаимосвязанных объектов. Связь двух объектов отражает их подчиненность.
Иерархическая БД представляет собой древовидную структуру и состоит из упорядоченного набора деревьев (ориентированных графов) или, точнее, упорядоченного набора нескольких деревьев (графов) одного и того же типа. Напомним, что граф 1 совокупность точек, изображенных на плоскости (вершины графа) и связей между ними в виде линий, соединяющих их (ребра или дуги графа). Вершина, с которой начинается дерево (см. рис. 2.1), называется корневой. Каждая вершина (родительская) может порождать ряд других вершин (потомков), которые располагаются ниже. Графом, например, удобно описывать структуру управления организацией, начиная от ее руководителя и заканчивая конкретным исполнителем.
Тип дерева представляет собой иерархически организованную совокупность, содержащую один корневой тип записи и упорядоченный  набор, который может содержать  или не содержать множество типов  поддеревьев, каждое из которых относится к определенному типу дерева.
Между записями в иерархии могут  быть определены связи: один ко многим или один к одному, где запись, соответствующая элементу один, определяется как исходная, а соответствующая  элементу иного — как порожденная. Для иерархической структуры характерно, что запись-потомок имеет только одного предка, у которого может быть множество потомков. В общем случае данные в иерархической БД могут представляться несколькими деревьями.
В иерархических БД автоматически  поддерживается целостность ссылок между предыдущим (родителями) и последующим (потомками). Основное правило — последующее не может существовать без своего предыдущего. Аналогичное поддержание целостности по ссылкам между записями, не входящими в одну иерархию, не поддерживается.
В различных СУБД описание объекта  для БД иерархического типа может  называться по-разному: тип записи, файл, сегмент (далее используем термин «запись»). В свою очередь, запись состоит  из одного или нескольких элементов  данных (это аналог поля в файловой модели). Элементы упорядочиваются в некотором порядке.
Записи одной структуры образуют тип записи. Отдельные записи некоторого типа называют экземплярами записи. Модель данных может включать несколько  типов записей. При этом запись конкретного типа называют объектом модели.
Между объектами модели данных устанавливаются  связи. Они также характеризуются  типом. Связи между разными объектами (между парой экземпляров записей  разного типа) могут иметь разный тип.
В качестве пояснения ниже приводится концептуальная и логическая модели иерархической БД для «Классификатора таможенных органов и их структурных подразделений». Этот классификатор применяется при подготовке и контроле таможенных документов.
Известно, что в структуре ФТС  России выделяют три типа объектных множеств: региональные таможенные управления (РТУ), таможни (Т) и таможенные посты (ТП). Они находятся в линейной подчиненности РТУ-Т-ТП. Описание каждого типа объектов состоит из двух элементов: имя и код, однако они имеют разный смысл. Для объектов типа РТУ - это наименования и коды региональных таможенных управлений, для Т - наименования и коды таможен, для ТП - наименования и коды таможенных постов. Таким образом, концептуальная модель создаваемой базы предполагает задание и сохранение в БД описан ИИ объектов трех типов, находящихся в линейной подчиненности.
Конкретная таможня подчиняется только одному РТУ, а ТП - только одной таможне, поэтому для каждого РТУ можно построить дерево  подчиненности, в котором у каждого потомка будет только один предок, а корнем дерева будет объект типа РТУ. Следовательно, взаимосвязь данных в создаваемой БД описывается иерархическим деревом, что является особенностью БД иерархического типа.
Поскольку в состав каждого РТУ  входят несколько таможен, а в  таможню - несколько ТП, можно выделить два типа связей: первый - [РТУ-» Т] и второй - [Т -> ТП] . Поскольку в ФТС России семь РТУ, логическая модель создаваемой БД будет иметь семь однотипных деревьев (рис. 2.2). Количество потомков записей РТУ или Т будет зависеть от структуры соответствующих РТУ. Для описания элементов объектов в логической модели будет три типа записей по числу типов объектов: РТУ, Т и ТП.
 
Рис.2.2. Логическая модель БД классификатора
Например, запись типа РТУ, описывающая  Центральное таможенное управление (ЦТУ), будет иметь вид:
Имя
Код
ЦТУ
10100000

 
В Подольской таможне несколько  ТП. Поэтому запись типа Т с именем - <Подольская> будет иметь соответствующее  число потомков типа ТП.
Имя
Код
Подольская
10127070

 
Дальневосточное таможенное управление состоит из 18 таможен, соответственно в дереве, описывающем это управление, у записи типа РТУ будет 18 записей-потомков. Конкретная таможня, например Владивостокская, будет представлена записью:
Имя
Код
ДВТУ
10702000

 
В СУБД на основе иерархической модели типичными являются операции типа:
- найти  указанное дерево БД;
- найти  указанный экземпляр записи в  ранее выбранном дереве;
- просмотреть  записи некоторого типа в заданном  порядке;
- добавить  запись в заданную позицию  иерархии и др.
Для хранения в памяти ЭВМ иерархической структуры данных используется система указателей. Поэтому, например, при размещении в память ЭВМ записи типа РТУ после нее будет к ячеек-указателей с адресами расположения записей типа Т (к - число таможен, подчиненных определенному РТУ). В конце каждой записи типа Т будет столько указателей, сколько таможенных постов у соответствующей таможни.
Если  некоторые связи не укладываются в иерархическое дерево, то структуру  данных можно представить в виде нескольких иерархических деревьев, но тогда некоторые данные будут дублироваться.
Для выбора информации из иерархической  БД надо последовательно задать несколько  ключей. Так, для выбора информации о некоторой таможне в рассмотренной  выше БД надо сначала задать ключ выбора таможенного управления, а затем - ключ выбора таможни.
В технической литературе в качестве примеров иерархических БД часто  называют системы IMS (Information Management System), TDMS (Time-Shared Data Management System), Mark IV (Multi-Access Retrieval System), System-2000 и др.
Иерархическая модель является частным  случаем сетевой. В строго иерархических  моделях любой объект может подчиняться  только одному объекту вышестоящего уровня. В иерархических моделях  первоначальный доступ возможен по ключу, как правило, только к объекту самого высокого уровня (сопоставленного корню дерева), который не подчинен другим объектам. Доступ к другим объектам осуществляется по связям от корня дерева с использованием соответствующих дополнительных ключей.
Сетевая организация БД является дальнейшим развитием иерархической. В иерархических структурах запись-потомок должна иметь только одного предка, тогда как в сетевой структуре данных потомок может иметь любое число предков. Основными компонентами структуры сетевой БД, как и в иерархической, являются записи и связи, которые характеризуются типом. Конкретная запись или связь называется экземпляром связи или записи.
На рис. 2.3. представлена концептуальная модель сетевой БД, содержащая информацию о предпринимателях, брокерах, оформляющих грузовые таможенные декларации (с номерами 1,2….,5) на некоторые товары (сахар, окорочка, телевизоры).

Рис.2.3. Пример структуры данных сетевой БД
Достаточно очевидно, что в этой БД будет четыре типа записей: <Владелец товара>, <Брокер>, <Грузовая таможенная декларация><Вид товара>.
Логическую структуру сетевой  БД можно представить в виде графа (рис. 2.5). Нетрудно заметить, что в  нем несколько корневых вершин, причем некоторые из них имеют нескольких предков, что является характерным свойством сетевой модели.
В сетевых моделях доступ по ключу  может обеспечиваться к любому экземпляру записи независимо от уровня, на котором  она находится в модели. Возможен также доступ по нескольким путям.
Таким образом, при использовании сетевой модели пользователю достаточно (в общем случае) задать один ключ, чтобы получить искомую запись. Например, декларацию 2 можно найти в БД через владельцев товара либо брокеров. При иерархической модели может потребоваться последовательное задание нескольких ключей, чтобы получить требуемую запись.

Рис. 2.4. Граф, соответствующий примеру на рис. 2.2.
Таким образом, при использовании  сетевой модели пользователю проще  получить искомую запись.
В принципе сетевую структуру (см. рис 2.4) можно представить в виде нескольких отдельных деревьев (в виде иерархической модели), но тогда возникнет дублирование части информации, что приведет к росту объема БД.
В СУБД на основе сетевой модели типичными  являются операции:
- поиск указанной записи;
- переход от предка к потомку;
- переход от потомка к предку;
- просмотр предков ИЛИ потомков  в заданном порядке;
- добавление записи в заданную  позицию иерархии и др.
Сетевые модели данных по сравнению  с иерархическими являются более  универсальным средством отображения структуры информации для разных предметных областей. Кроме того, технология работы с сетевыми моделями является более удобной для пользователя, так как доступ к данным практически не имеет ограничений и возможен по одному ключу непосредственно к объекту любого уровня.
Взаимосвязи данных во многих предметных областях имеют сетевой характер. В то же время они позволяют  отображать и иерархические взаимосвязи  данных. Достоинством сетевых моделей  является также отсутствие дублирования данных.
Внутри машинное представление данных в сетевой БД, как и в иерархической, предполагает снабжение записей указателями.
В технической литературе в качестве примеров сетевых БД часто называют системы IDS (Integrated Data Store), IDMS (Integrated Database Management System), db. VISTA и др.
 
2.3. Реляционная модель данных
 
Длительное время до появления  реляционных БД на практике преобладали  иерархические и сетевые модели.
Считается, что впервые наиболее полное изложение реляционной модели сформулировал Е.Ф. Кодд в начале 70-х гг. К этому времени стало ясно, что при сложных структурах данных реализация новых запросов или введение новых логических связей в сетевых или иерархических БД требует довольно существенных доработок программного обеспечения. Указанный недостаток обусловлен тем, что в этих БД выбор необходимых записей производится е использованием указателей, через которые связаны записи. Предположим, что исходная иерархическая или сетевая БД содержит сведения о товарах, их ценах в разных поставках и информацию о производителях товаров, причем в графе исходной структуры данных нет пути между вершинами, сопоставленными производителям и их ценам товаров. Тогда при необходимости выбора из БД сведений о ценах товаров указанного производителя придется выполнить несколько запросов и провести специальную обработку выбранных данных (скорей всего для этого потребуется разработать дополнительный программный модуль). Если же было несколько производителей одного товара, то задача может оказаться невыполнимой.
Е.Ф. Кодд предложил представлять логическую модель данных в виде набора таблиц, которые получили название реляций, а сама модель -  реляционной. При использовании этой модели по запросу пользователя из таблиц должна выбираться одна или несколько строк (столбцов), удовлетворяющих заданным требованиям. Кроме того он предложил для обработки таблиц (в целях реализации запросов) применять механизм реляционной алгебры или реляционного исчисления.
В реляционной модели по запросу  пользователя из таблиц должна выбираться одна или несколько строк (столбцов), удовлетворяющих заданным требованиям. Реляционная алгебра позволяет описывать процессы реализации запросов, манипулируя таблицами, а не отдельными данными. С некоторым допущением можно говорить, что пользователь реляционной БД, применяя реляционную алгебру, может при разработке процедур обработки запроса одной командой описать обработку целой таблицы или нескольких таблиц, в то время как в других БД для выполнения этого же запроса ему пришлось бы манипулировать множеством записей и, соответственно, использовать множество команд. Не менее важным свойством реляционных БД является возможность создания достаточно простых стандартных языковых средств формулирования и реализации любых запросов.
Базы данных, объектами которых  являются связанные определенным образом таблицы, называют реляционными (от relation - связь, отношение). В реляционной БД таблицы (реляции) должны удовлетворять определенным требованиям.
1. Данные в ячейках таблицы  должны быть структурно неделимыми. Каждая ячейка может содержать только один набор данных. Это свойство часто определяется как принцип информационной неделимости. Недопустимо, чтобы в ячейке таблицы реляционной модели содержалось более одного набора (порции) данных, что иногда называют информационным кодированием.
2. Столбцы должны размешаться  в произвольном порядке, а данные  каждого столбца должны быть  однотипными.
3. Каждый столбец должен быть  уникальным (недопустимо дублирование  столбцов) и иметь уникальное  наименование.
4. Строки размешаются в таблице в произвольном порядке.
Связанные отношениями таблицы  взаимодействуют по принципу главная (master) - подчиненная (detail). Например, если име
и т.д.................


Перейти к полному тексту работы


Скачать работу с онлайн повышением оригинальности до 90% по antiplagiat.ru, etxt.ru


Смотреть полный текст работы бесплатно


Смотреть похожие работы


* Примечание. Уникальность работы указана на дату публикации, текущее значение может отличаться от указанного.