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

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ

Федеральное государственное бюджетное образовательное учреждение

высшего профессионального образования

«Тихоокеанский государственный университет»

 

 

Кафедра Экономической кибернетики

 

 

 

Контрольная работа

по Базам данных

вариант №1

на тему «История развития баз данных: файлы и файловые системы, базы данных»

 

 

 

                                                          Выполнил студент заочного обучения

                                                     Специальность «Региональная Экономика»

                                                          Группа РЭ(б)3-22

                                                          Номер зачетной книжки 120430160

                                                          Ф.И.О. Данилов Е.С.

                                                                                                                                                                                                                

 

 

 

 

 

Хабаровск 2013 г.

СОДЕРЖАНИЕ

 

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

2 Расчет повременной оплаты                                                                              16

Список использованных источников 45

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

1 ИСТОРИЯ РАЗВИТИЯ БАЗ  ДАННЫХ: ФАЙЛЫ И ФАЙЛОВЫЕ

              СИСТЕМЫ, БАЗЫ ДАННЫХ

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1.  сетевая модель данных (network data model).

     Сетевая модель данных – модель, состоящая из записей, элементов данных и связей типа «один ко многим» (1:М), установленных между записями.

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

Рисунок 1 - Представление связей в сетевой модели

 

     Для описания схемы сетевой БД используется две группы типов: «запись» и «связь». Тип «связь» определяется для двух типов «запись»: предка и потомка. Переменные типа «связь» являются экземплярами связей.

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

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

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

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

2) иерархическая модель данных (hierarchical data model).

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

Рисунок 2 - Представление связей в иерархической модели.

 

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

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

    Также можно встретить следующее описание типов иерархической модели.

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

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

3) реляционная модель данных (relational data model)

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

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

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

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

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

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

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

•  определение данных;

•  определение представлений;

•  обработку данных (интерактивную и программную);

•  условия целостности;

•  идентификация прав доступа;

•  границы транзакций (начало, завершение и отмена).

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

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

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

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

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

11. Правило независимости  распространения. Реляционная СУБД  не должна зависеть от потребностей  конкретного пользователя.

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

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

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

Таблица 1 Сравнительная характеристика способов обращения к данным

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

 

 

Преимущества и недостатки СУБД представлены в таблице 2.

Таблица 2 - Преимущества и недостатки СУБД

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

 

 

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

- каждый узел — это полноценная СУБД сама по себе;

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

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

     Фундаментальный принцип создания распределённых баз данных («правило 0»): Для пользователя распределённая система должна выглядеть так же, как нераспределённая система. Фундаментальный принцип имеет следствием определённые дополнительные правила или цели. Таких целей всего двенадцать:

1. Локальная независимость. Узлы в распределённой системе должны быть независимы, или автономны. Локальная независимость означает, что все операции на узле контролируются этим узлом.
2. Отсутствие опоры на центральный узел. Локальная независимость предполагает, что все узлы в распределённой системе должны рассматриваться как равные. Поэтому не должно быть никаких обращений к «центральному» или «главному» узлу с целью получения некоторого централизованного сервиса.
3. Непрерывное функционирование. Распределённые системы должны предоставлять более высокую степень надёжности и доступности.
4. Независимость от расположения. Пользователи не должны знать, где именно данные хранятся физически и должны поступать так, как если бы все данные хранились на их собственном локальном узле.
5. Независимость от фрагментации. Система поддерживает независимость от фрагментации, если данная переменная-отношение может быть разделена на части или фрагменты при организации её физического хранения. В этом случае данные могут храниться в том месте, где они чаще всего используются, что позволяет достичь локализации большинства операций и уменьшения сетевого трафика.
6. Независимость от репликации. Система поддерживает репликацию данных, если данная хранимая переменная-отношение — или в общем случае данный фрагмент данной хранимой переменной-отношения — может быть представлена несколькими отдельными копиями или репликами, которые хранятся на нескольких отдельных узлах.
7. Обработка распределённых запросов. Суть в том, что для запроса может потребоваться обращение к нескольким узлам. В такой системе может быть много возможных способов пересылки данных, позволяющих выполнить рассматриваемый запрос.
8. Управление распределёнными транзакциями. Существует 2 главных аспекта управления транзакциями: управление восстановлением и управление параллельностью обработки. Что касается управления восстановлением, то чтобы обеспечить атомарность транзакции в распределённой среде, система должна гарантировать, что все множество относящихся к данной транзакции агентов (агент — процесс, который выполняется для данной транзакции на отдельном узле) или зафиксировало свои результаты, или выполнило откат. Что касается управления параллельностью, то оно в большинстве распределённых систем базируется на механизме блокирования, точно так, как и в нераспределённых системах.
9. Аппаратная независимость. Желательно иметь возможность запускать одну и ту же СУБД на различных аппаратных платформах и, более того, добиться, чтобы различные машины участвовали в работе распределённой системы как равноправные партнёры.
10. Независимость от операционной системы. Возможность функционирования СУБД под различными операционными системами.
11. Независимость от сети. Возможность поддерживать много принципиально различных узлов, отличающихся оборудованием и операционными системами, а также ряд типов различных коммуникационных сетей.
12. Независимость от типа СУБД. Необходимо, чтобы экземпляры СУБД на различных узлах все вместе поддерживали один и тот же интерфейс, и совсем необязательно, чтобы это были копии одной и той же версии СУБД.

 

 

 

 

 

 

 

 

 

 

 

 

 

2 РАСЧЕТ ПОВРЕМЕННОЙ ОПЛАТЫ

 

Задание.

1. Создать таблицы:

Таблица 1. Справочник работников

Структура таблицы: Табельный номер, Фамилия И. О., Разряд, Цех

Таблица 2. Справочник тарифов

Структура таблицы: Разряд, Тариф (руб./час.)

Таблица 3. Табель учета отработанного времени

Структура таблицы: Табельный номер, Отработанное время в часах, Номер месяца

Таблица 4. Ведомость начисления зарплаты

Структура таблицы: Месяц, Цех, Табельный номер. Фамилия И. О., Отработанное время, Тариф, Начислено (руб.)

2. Ввести в таблицу 1 сведения о 15-ти работниках из трех цехов, в таблицу 2 данные по пяти разрядам.
3. Создать форму «Табель» для ввода данных в таблицу 3, предусмотрев контроль вводимых данных (отработанное время) и выдачу сообщений при возникновении ошибок ввода. Для ввода табельного номера использовать поле со списком, содержащим табельные номера и фамилии, соответствующие таблице 1. Ввести данные о 15 рабочих за один месяц.
4. Создать запрос на добавление расчетных данных в четвертую таблицу за один месяц, номер которого должен вводится по запросу.
5. Создать форму (типа главная/подчиненная) только для просмотра сведений об одном работнике. Главная форма должна содержать: Табельный номер, Фамилия И. О., Разряд, Цех, Тариф. Подчиненная форма должна иметь  три графы  (номер месяца, отработанное время, начисленную сумму) и количество строк, соответствующее отработанным месяцам.
6. Создать отчет "Платежная ведомость по цеху  N … за месяц ..." с итогом по полю начислено. Цех и номер месяца должны вводиться по запросу. Платежная ведомость должна содержать графы: Номер по порядку, Табельный номер, Фамилия И.О., Сумма к выдаче, Подпись.
7. Создать отчет с итоговыми данными за два месяца, показывающий распределение сумм зарплаты в разрезе цехов по разрядам.

 

Решение.

1. Создание таблиц.

Создадим таблицы, исходя их условий задачи.

    В режиме «Конструктор» таблица «Справочник данных» имеет вид:

Рисунок 1 – Справочник данных

 

     В режиме  «Конструктор» таблица «Справочник  тарифов» имеет вид: