1)Первый этап — базы данных на больших эвм

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

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

• Функции управления распределением ресурсов в основном осуществляются операционной системой (ОС).

• Поддерживаются языки низкого уровня манипулирования данными, ориентированные на навигационные методы доступа к данным.

• Значительная роль отводится администрированию данных.

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

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

• Результаты теоретических исследований активно внедряются в коммерческие СУБД.

Второй этап ­– эпоха персональных компьютеров

Особенности этого этапа следующие:

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

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

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

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

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

• Сравнительно скромные требования к аппаратному обеспечению со стороны настольных СУБД. Вполне работоспособные приложения, разработанные, например, на Clipper, работали на PC286.

• В принципе, их даже трудно назвать полноценными СУБД. Яркие представители этого семейства — очень широко использовавшиеся до недавнего времени СУБД Dbase, FoxPro, Clipper, Paradox.

Третий этап ­– распределенные базы данных

Особенности данного этапа:

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

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

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

• Разработка стандартов в рамках языков описания и манипулирования данными, начиная с языка SQL и технологий по обмену данными между различными СУБД, к которым можно отнести и протокол ODBC (Open DataBase Connectivity), предложенный фирмой Microsoft.

• Исследование концепций объектно-ориентированных БД — ООБД.

• Представителями СУБД, относящимся ко второму этапу, можно считать MS Access и все современные серверы баз данных Оrасlе, MS SQL Server, Sybase, Informix, DB2, SQL Base и другие.

1.1 ЭВОЛЮЦИЯ КОНЦЕПЦИЙ ОБРАБОТКИ ДАННЫХ

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

· обработка БД на мэйнфреймах с помощью СУБД;

· обработка БД с помощью систем удаленной обработки данных;

· обработка локальных БД на ПК с помощью настольных СУБД;

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

· использование клиент/серверных систем;

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

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

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

3)

4)

5)

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

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

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

«опытные пользователи» - знакомы со структурой БД, могут применять языки, создавать собственные приложения;

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

7) Непосредственное управление данными во внешней памяти

Управление буферами оперативной памяти

Управление транзакциями

Журнализация

Поддержка языков БД

8) Проектирует базы данных.

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

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

Обеспечение безопасности в базе данных.

Резервирование и восстановление базы данных.

Обеспечение целостности баз данных.

Обеспечение перехода на новую версию СУБД.

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

10) Транзакция - это последовательность операций над БД, рассматриваемых СУБД как единое целое. Либо транзакция успешно выполняется, и СУБД фиксирует (COMMIT) изменения БД, произведенные этой транзакцией, во внешней памяти , либо ни одно из этих изменений никак не отражается на состоянии БД. Понятие транзакции необходимо для поддержания логической целостности БД. Если вспомнить наш пример информационной системы с файлами СОТРУДНИКИ и ОТДЕЛЫ, то единственным способом не нарушить целостность БД при выполнении операции приема на работу нового сотрудника является объединение элементарных операций над файлами СОТРУДНИКИ и ОТДЕЛЫ в одну транзакцию. Таким образом, поддержание механизма транзакций является обязательным условием даже однопользовательских СУБД (если, конечно, такая система заслуживает названия СУБД ). Но понятие транзакции гораздо более важно в многопользовательских СУБД .

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

12) Процесс проектирования базы данных состоит из трех основных этапов: концептуальное, логическое и физическое проектирование.

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

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

Логическое проектирование базы данных

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

Физическое проектирование базы данных

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

13)

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

1)) аспект структуры: методы описания типов и логических структур данных в базе данных;

2)) аспект манипуляции: методы манипулирования данными;

3)) аспект целостности: методы описания и поддержки целостности базы данных.

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

15)

16) I этап. Постановка задачи.

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

II этап. Анализ объекта.

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

III этап. Синтез модели.

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

IV этап. Выбор способов представления информации и программного инструментария.

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

В большинстве СУБД данные можно хранить в двух видах:

с использованием форм;

без использования форм.

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

V этап. Синтез компьютерной модели объекта.

VI этап. Работа с созданной базой данных.

Работа с БД включает в себя следующие действия:

поиск необходимых сведений;

сортировка данных;

отбор данных;

вывод на печать;

изменение и дополнение данных.

17) одель сущность-связь (ER-модель) (англ. entity-relationship model, ERM) — модель данных, позволяющая описывать концептуальные схемы предметной области.

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

Во время проектирования баз данных происходит преобразование ER-модели в конкретную схему базы данных на основе выбранной модели данных (реляционной, объектной, сетевой или др.).

ER-модель представляет собой формальную конструкцию, которая сама по себе не предписывает никаких графических средств её визуализации. В качестве стандартной графической нотации, с помощью которой можно визуализировать ER-модель, была предложена диаграмма сущность-связь (ER-диаграмма) (англ. entity-relationship diagram, ERD).

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

Концептуальное (инфологическое) проектирование

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

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

Чаще всего концептуальная модель базы данных включает в себя:

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

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