Я сейчас довольно активно работаю с базами данных и с СУБД Oracle в частности. Но, чтобы качественно работать с различными СУБД – необходимо очень хорошо знать основы реляционных баз данных, и теорию всех баз данных.

Поэтому начнем с истории возникновения баз данных:

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

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

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

3.0. 1970 год – британский ученый Эдгар Кодд выпустил работу «A Relational Model of Data for Large Shared Data Banks». Данная работа считается первым трудом по реляционному хранению данных. После ее выпуска начинаются активные работы по разработке данной системы хранения информации.

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

Основы реляционных баз данных включают в себя три аспекта:

Структурный – данные представляют из себя наборы отношений;

Целостности – наборы отношений отвечают требованиям целостности;

Обработки – поддерживаются операторы манипулирования отношениями.

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

Достоинствами реляционного подхода являются:

Данный подход основан на небольшом числе законов (правил);

Эти правила точно определены;

В основе лежит мат.логика и теория множеств;

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

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

Данное описание истории баз данных – это мой взгляд на нее, так что ругаться не надо. Реляционные СУБД сейчас используются повсеместно – это MSSQL Server от компании Microsoft , ORACEL от одноименной компании, DB /2 от IBM – это примеры коммерческих РСУБД. Всем веб-разработчикам, которые не используют таких РСУБД, известна MySQL – бесплатная РСУБД, которая разрабатывалась компанией Sun Microsystem . Различных реляционных СУБД много, но меня будет интересовать (пока) только продукция компании Oracle .

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

Важным этапом развития ИС явился переход к использованию централизованных систем управления файлами. Широкое распространение получили индексированные файлы . Файл является простым набором записей (record), которые содержат логически связанные данные. Каждая запись содержит логически связанный набор из одного или нескольких полей (field), каждое из которых представляет некоторую характеристику моделируемого объекта. С точки зрения прикладной программы файл – именованная область внешней памяти, в которую можно записывать и из которой можно считывать данные.

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

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

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

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

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

5. Невозможность многопользовательского режима работы.

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

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

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

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

В 1968 году появилась первая версия базы данных Information Management System (IMS) фирмы IBM. Применяемая структура, напоминала перевернутое дерево и была названа иерархической структурой.

Другим заметным достижением середины 1960-х годов было появление системы IDS (Integrated Data Store) фирмы General Electric. Развитие этой системы привело к созданию нового типа систем управления базами данных - сетевых СУБД . Сетевая СУБД создавалась для представления более сложных взаимосвязей между данными, чем те, которые можно было моделировать с помощью иерархических структур, а также для формирования стандарта баз данных. В 1971 году для утверждения Национальным институтом стандартизации США (American National Standards Institute - ANSI), группой DBTG был представлен стандарт баз данных, содержаий три компонента:

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

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

· Язык управления данными - инструмент для определения характеристики структуры данных, а также для управления ими.

Той же группой DBTG было предложено стандартизировать три языка:

· Язык определения данных для схемы (Data Definition Language - DDL), который позволяет администраторам баз данных ее описать.

· Язык определения данных для подсхемы (также DDL), который позволяет определять в приложениях те части базы данных, доступ к которым будет необходим.

· Язык манипулирования данными (Data Manipulation Language - DML), предназначенный для управления данными.

Несмотря на то что этот отчет официально не был утвержден Национальным институтом стандартизации США (American National Standards Institute - ANSI), большое количество систем было разработано в полном соответствии с этими предложениями группы DBTG.

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

· Развитые средства управления данными во внешней памяти на низком уровне.

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

· Возможность экономии памяти за счет разделения подобъектов (в сетевых системах).

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

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

· Независимость от данных существует лишь в минимальной степени.

· Отсутствие общепризнанных теоретических основ.

В 1970 году Э. Ф. Кодд (Е. F. Codd), работавший в исследовательской лаборатории корпорации IBM, опубликовал статью о реляционной модели данных , позволявшей устранить недостатки прежних моделей. Вслед за этим появилось множество экспериментальных реляционных СУБД, а первые коммерческие продукты появились в 1970-1980-х годах. Корпорацией IBM, расположенной в городе Сан-Хосе, штат Калифорния, созданной в конце 1970-х годов, был задуман проект с целью доказать практичность реляционной модели, что достигалось посредством реализации предусмотренных ею структур данных и требуемых функциональных возможностей. На основе этого проекта были получены важнейшие результаты.

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

· В 1980-х годах были созданы различные коммерческие реляционные СУБД - например DB2 или SQL/DS корпорации IBM или Oracle корпорации Oracle Corporation.

В настоящее время существует несколько сотен различных реляционных СУБД. В качестве примеров многопользовательских СУБД могут служить система INGRES II фирмы Computer Associates и система Informix фирмы Informix Software, Inc. Примерами реляционных СУБД для персональных компьютеров являются Access и FoxPro фирмы Microsoft, Paradox фирмы Corel Corporation, InterBase и BDE iupMbi Borland, а также R:Base фирмы R:Base Technologies. Реляционные СУБД относятся к СУБД второго поколения.

Однако реляционная модель обладает также некоторыми недостатками, в частности ограниченными возможностями моделирования. Для решения этой проблемы был выполнен большой объем исследовательской работы. В 1976 году Питер Чен) предложил модель "сущность-связь" (Entity-Relationship model - ER-модель), которая в настоящее время стала самой распространенной технологией проектирования баз данных и является основой методологии. В 1979 году Кодд сделал попытку устранить недостатки собственной основополагающей работы и опубликовал расширенную версию реляционной модели - RM/T (1979), затем еще одну версию - RM/V2 (1990). Попытки создания модели данных, позволяющей более точно описывать реальный мир, неформально называют семантическим моделированием данных (semantic data modeling).

В ответ на все возрастающую сложность приложений баз данных появились две новые системы: объектно-ориентированные СУБД, или ООСУБД (Object-Driented DBMS - OODBMS), и объектно-реляционные СУБД, или ОРСУБД Object-Relational DBMS - ORDBMS). Однако в отличие от предыдущих моделей действительная структура этих моделей не совсем ясна. Попытки реализации подобных моделей представляют собой СУБД третьего поколения.

История развития баз данных

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

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

· надежное хранение информации в памяти компьютера;

· выполнение специфических для данного приложения преобразований информации и вычислений;

· Предоставление пользователям удобного и легко осваиваемого"интерфейса.

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

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

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

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

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

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

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

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

· создать файл (требуемого типа и размера); а открыть ранее созданный файл;

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

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

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

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

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

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

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

Первый этап - базы данных на больших ЭВМ

История развития СУБД насчитывает более 30 лет. В 1968 году была введена в эксплуатацию первая промышленная1 СУБД система IMS фирмы IBM. В 1975 году появился первый стандарт ассоциации по языкам систем обработки дан­ных - Conference of Data System Languages (CODASYL), который определил ряд фундаментальных понятий в теории систем баз данных, которые и до сих пор являются основополагающими для сетевой модели данных.

В дальнейшее развитие теории баз данных большой вклад был сделан амери­канским математиком Э. Ф, Коддом, который является создателем реляционной модели данных. В 1981 году получил за создание реляционной моде­ли и реляционной алгебры престижную премию Тьюринга Американской ассо­циации по вычислительной технике.

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

Первый этап развития СУБД связан с организацией баз данных на больших ма­шинах типа IBM 360/370, ЕС-ЭВМ и мини-ЭВМ типа PDP11 (фирмы Digital Equipment Corporation - DEC), разных моделях HP (фирмы Hewlett Packard),

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

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

· Все СУБД базируются на мощных мультипрограммных операционных сис­темах (MVS SVM, RTE, OSRV, RSX, UNIX), поэтому в основном поддер­живается работа с централизованной базой данных в режиме распределенно­го доступа.

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

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

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

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

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

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

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

Эпоха персональных компьютеров

Персональные компьютеры стремительно ворвались в нашу жизнь и буквально перевернули наше представление о месте и роли вычислительной техники в жизни общества. Теперь компьютеры стали ближе и"доступнее каждому пользо­вателю. Исчез благоговейный страх рядовых пользователей перед непонятны­ми и сложными языками программирования. Появилось множество программ, предназначенных для работы неподготовленных пользователей. Эти программы были просты в использовании и интуитивно понятны: это прежде всего различ­ные редакторы текстов, электронные таблицы и другие. Простыми и понятны­ми стали операции копирования файлов и перенос информации с одного ком­пьютера на другой, распечатка текстов, таблиц и других документов. Системные программисты были отодвинуты на второй план. Каждый пользователь мог себя почувствовать полным хозяином этого мощного и удобного устройства, по­зволяющего автоматизировать многие аспекты деятельности. И, конечно, это сказалось и на работе с базами данных. Появились программы, которые называ­лись системами управления базами данных и позволяли хранить значительные объемы информации, они имели удобный интерфейс для заполнения данных, встроенные средства для генерации различных отчетов. Эти программы позво­ляли автоматизировать многие учетные функции, которые раньше велись вруч­ную. Постоянное снижение цен на персональные компьютеры сделало их до­ступными не только для организаций и фирм, но и для отдельных пользователей. Компьютеры стали инструментом для ведения документации и собственных учетных функций. Это все сыграло как положительную, так и отрицательную роль в области развития баз данных. Кажущаяся простота и доступность персо­нальных компьютеров п их программного обеспечения породила множество ди­летантов. Эти разработчики, считая себя знатоками, стали проектировать недол­говечные базы данных, которые не учитывали многих особенностей объектов реального мира. Много было создано систем-однодневок, которые не отвечали законам развития п взаимосвязи реальных объектов. Однако доступность пер­сональных компьютеров заставила пользователей из многих областей знаний, которые ранее не применяли вычислительную технику в своей деятельности, обратиться к ним. И спрос па развитые удобные программы обработки данных заставлял поставщиков программного обеспечения поставлять все новые системы, которые принято называть настольными (desktop) СУБД. Значительная конку­ренция среди поставщиков заставляла совершенствовать эти системы, предла­гая новые возможности, улучшая интерфейс п быстродействие систем, снижая их стоимость. Наличие на рынке большого числа СУБД, выполняющих сход­ные функции, потребовало разработки методов экспорта-импорта данных для этих систем и открытия форматов храпения данных. Но и в этот период появлялись любители, которые вопреки здравому смыслу разрабатывали собственные СУБД, используя стандартные языки программи­рования. Это был тупиковый вариант, потому что дальнейшее развитие показа­ло, что перенести данные из нестандартных форматов в новые СУБД было го­раздо труднее, а в некоторых случаях требовало таких трудозатрат, что легче было бы все разработать заново, по данные все равно надо было переносить на новую более перспективную СУБД. И это тоже было результатом недооценки тех функций, которые должна была выполнять СУБД,

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

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

· Большинство СУБД имели развитый и удобный пользовательский интерфейс. В большинстве существовал-интерактивный режим работы с БД как в рам­ках описания БД, так и в рамках проектирования запросов. Кроме того, боль­шинство СУБД предлагали развитый и удобный инструментарий для разра­ботки готовых приложений без программирования. Инструментальная среда состояла из готовых элементов приложения в виде шаблонов экранных форм, "отчетов, (этикеток"(Labels), графических конструкторов запросов, которые достаточно просто могли быть собраны в единый комплекс.

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

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

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

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

· И, наконец, последняя и в настоящий момент весьма положительная особен­ность - это сравнительно скромные требования к аппаратному обеспечению со стороны настольных СУБД.

Вполне работоспособные приложения, разра­ботанные, например, на Clipper, работали на PC 286,

В принципе, их даже трудно назвать полноценными СУБД, Яркие предста­вители этого семейства - очень широко использовавшиеся до недавнего вре­мени СУБД Dbasc (DbaseIII+, DbaselV), FoxPro, Clipper, Paradox.

Распределенные базы данных

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

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

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

· структурной целостности - допустимыми являются только данные, пред­ставленные в виде отношений реляционной модели;

· языковой целостности, то есть языков манипулирования данными высо­кого уровня (в основном SQL);

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

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

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

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

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

· Именно к этому этапу можно отнести разработку ряда стандартов в рамках языков описания и манипулирования данными начиная с SQL89, SQL92, SQL99 и технологий по обмену данными между различными СУБД, к кото­рым можно отнести и протокол ODBC (Open DataBase Connectivity), пред­ложенный фирмой Microsoft .

· Именно к этому этапу можно отнести начало работ, связанных с концепцией объектно-ориентированных БД - СЮБД. Представителями СУБД, относя­щимся ко второму этапу, можно считать MS Access 97 и все современные серверы баз данных Огас1е7ДОгас1е 8.4 MS SQL6.5, MS SQL7.0, System 10, System 11, Informix, DB2, SQL Base и другие современные серверы баз дан­ных, которых в настоящий момент насчитывается несколько десятков.

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

Этот этап характеризуется появлением новой технологии доступа к данным - интернет, Основное отличие этого подхода от технологии клиент-сервер состо­ит в том, что отпадает необходимость использования специализированного кли­ентского программного обеспечения. Для работы с удаленной базой данных используется стандартный броузер Интернета, например Microsoft Internet Explorer или Netscape Navigator, и для конечного пользователя процесс обра­щения к данным происходит аналогично скольжению по Всемирной Паутине (см. рис. 1.1). При этом встроенный в загружаемые пользователем HTML-стра­ницы код, написанный обычно на языке Java, Java-script, Perl и других, отсле­живает все действия пользователя и транслирует их. в низкоуровневые SQL-за­просы к базе данных, выполняя, таким образом, ту работу, которой в технологии клиент-сервер занимается клиентская программа. Удобство данного подхода привело к тому, что он стал использоваться не только для удаленного доступа к базам данных, но и для пользователей локальной сети предприятия, Простые задачи обработки данных, не связанные со сложными алгоритмами, требующими согласованного изменения данных во многих взаимосвязанных объектах, достаточно просто и эффективно могут быть построены по данной ар­хитектуре. В этом случае для подключения нового пользователя к возможности использовать данную задачу не требуется установка дополнительного клиент­ского программного обеспечения. Однако алгоритмически сложные задачи ре­комендуется реализовывать в архитектуре «клиент-сервер» с разработкой спе­циального клиентского программного обеспечения.

время все подходы широко используются.

Рис. 1.1. Взаимодействие с базой данных в технологии интранет

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

1. Введение. История развития баз данных

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

3. Первый этап -- базы данных на больших ЭВМ

4. Второй этап - эпоха персональных компьютеров

5. Третий этап - распределенные базы данных

6. Четвертый этап - перспективы развития систем

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

7. Типы данных СУБД MySQL

a. Числовые типы

b. Текстовые типы данных

c. Типы даты и времени

8. Перспективы развития сетевых баз данных

Список литературы

1. Введен ие. История развития баз данных

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

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

надежное хранение информации в памяти компьютера;

выполнение специфических для данного приложения преобразований информации и вычислений;

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

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

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

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

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

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

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

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

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

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

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

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

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

создать файл (требуемого типа и размера);

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

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

Для иллюстрации обратимся к примеру, приведенному в книге: У. Девис, Операционные системы, М., Мир, 1980:

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

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

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

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

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

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

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

3. Первый этап -- базы данных на больших ЭВМ

История развития СУБД насчитывает более 30 лет. В 1968 году была введена в эксплуатацию первая промышленная СУБД система IMS фирмы IBM. В 1975 году появился первый стандарт ассоциации по языкам систем обработки данных -- Conference of Data System Languages (CODASYL), который определил ряд фундаментальных понятий в теории систем баз данных, которые и до сих пор являются основополагающими для сетевой модели данных.

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

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

Первый этап развития СУБД связан с организацией баз данных на больших машинах типа IBM 360/370, ЕС-ЭВМ и мини-ЭВМ типа PDP11 (фирмы Digital Equipment Corporation -- DEC), разных моделях HP (фирмы Hewlett Packard).

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

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

Все СУБД базируются на мощных мультипрограммных операционных системах (MVS, SVM, RTE, OSRV, RSX, UNIX), поэтому в основном поддерживается работа с централизованной базой данных в режиме распределенного доступа.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

структурной целостности -- допустимыми являются только данные, представленные в виде отношений реляционной модели;

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

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

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

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

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

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

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

Именно к этому этапу можно отнести начало работ, связанных с концепцией объектно-ориентированных БД -- ООБД. Представителями СУБД, относящимся ко второму этапу, можно считать MS Access 97 и все современные серверы баз данных Огас1е7.3, 0гас1е 8.4, MS SQL 6.5, MS SQL 7.0, System 10, System 11, Informix, DB2, SQL Base и другие современные серверы баз данных, которых в настоящий момент насчитывается несколько десятков.

Четвертый этап - перспективы развития систем управления базами данных

Этот этап характеризуется появлением новой технологии доступа к данным -- интранет. Основное отличие этого подхода от технологии клиент-сервер состоит в том, что отпадает необходимость использования специализированного клиентского программного обеспечения. Для работы с удаленной базой данных используется стандартный броузер Internet, например Microsoft Internet Explorer или Netscape Navigator, и для конечного пользователя процесс обращения к данным происходит аналогично скольжению по Всемирной Паутине. При этом встроенный в загружаемые пользователем HTML-страницы код, написанный обычно на языках Java, Java-script, Perl и других, отслеживает все действия пользователя и транслирует их в низкоуровневые SQL-запросы к базе данных, выполняя, таким образом, ту работу, которой в технологии клиент-сервер занимается клиентская программа. Удобство данного подхода привело к тому, что он стал использоваться не только для удаленного доступа к базам данных, но и для пользователей локальной сети предприятия. Простые задачи обработки данных, не связанные со сложными алгоритмами, требующими согласованного изменения данных во многих взаимосвязанных объектах, достаточно просто и эффективно могут быть построены по данной архитектуре. В этом случае для подключения нового пользователя к возможности использовать данную задачу не требуется установка дополнительного клиентского программного обеспечения. Однако алгоритмически сложные задачи рекомендуется реализовывать в архитектуре «клиент-сервер» с разработкой специального клиентского программного обеспечения.

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

Типы данных СУБД MySQL.

Все типы данных, с которыми работает СУБД MySQL можно разбить на три большие группы: числовые, текстовые и даты-времени. Рассмотрим эти типы данных по порядку.

a. Числовые типы

Числовые типы столбцов используются для хранения чисел, все числовые типы можно разбить на два подтипа для хранения точных чисел и чисел с плавающей точкой. Все числовые типы характеризуются длинной хранимых чисел, а типы с плавающей точкой еще и числом десятичных разрядов. Эти значения указываются после объявления типа столбца, например, FLOAT(10, 2). В примере указана длинна числа в 10 символов и два знака после десятичного разделителя. Также объявление числовых типов можно заканчивать ключевыми словами ZEROFILL и (или) USIGNED. Ключевое слово USIGNED означает, что столбец содержит только положительные числа или нули.

ZEROFILL - означает, что число будет отображено с ведущими нулями.

NUMERIC или DECIMAL

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

Тип данных INTEGER можно сократить до INT. Это просто целое число в заданном диапазоне. Для хранения этого типа данных отводится 4 байта и оно может хранить числа до двух в тридцать второй степени. Также существует несколько вариантов типа INTEGER.

TINYINT - Размер хранения в один байт и соответственно хранит числа от 1 до 127 (один бит знак отрицательности)

SMALLINT - Диапазон значений в два байта

MEDIUMINT - Три байта

BIGINT - Самый большой тип целых чисел диапазон восемь байтов.

Это числа с плавающей точкой с обычной точностью (4 байта). Они могут представлять числа в диапазоне от 1.18 на 10 в минус 38 степени до 3.4на 10 в тридцать восьмой степени.

Числа с плавающей точкой двойной точности(8 байтов) диапазон значений плюс минус десять в триста восьмой степени (ну, очень много).

b. Текстовые типы данных

Тип CHAR используется для хранения строк фиксированной длинны. После ключевого слова CHAR обычно указывается длинна строки, например, CHAR(50) если длинна строки не указана то считается, что длинна равна одному символу. Максимальная длинна поля данного типа равняется 255 символам. Если число переданных в строку символов меньше указанной длинны, то строка будет дополнена пробелами, если больше, то обрезана. При возврате значения пробелы будут удалены из строки.

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

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

Типы полей TEXT используются для хранения более длинных фрагментов текста, чем допускается предыдущими типами. Сокращение BLOB означает большой двоичный объект. Эти два типа одинаковы за исключением того, что в типе BLOB сравнение строк идет с учетом регистра символов, а в типе TEXT без учета регистра. Оба типа имеют переменную длину и оба имеют некоторые вариации:

TINYTEXT и TINYBLOB - Могут хранить до 255 символов

TEXT и BLOB могут хранить до 64 килобайт информации

MEDIUMTEXT и MEDIUMBLOB - до 16 мегабайт

LONGTEXT и LONGBLOB до 4 гигабайт

Этот тип позволяет перечислить набор возможных значений для ввода в поле и хранит только одно значение из представленного списка. Например, ENUM(`m`,`a`,`z`) если не указать какое значение используется в поле по умолчанию, то будет использовано первое значение списка.

Этот тип похож на тип ENUM, но позволяет хранить несколько значений из списка значений в поле.

c. Типы даты и времени.

Тип применяется для хранения дат в формате(гггг-мм-дд)

Хранит время в виде (чч:мм:сс)

Комбинация предыдущих двух типов. формат следующий ГГГГ-ММ-ДД ЧЧ:ММ:СС.

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

Тип поля содержит значение года. Возможны две длинны: YEAR(2) и YEAR(4) для двух, и четырех цифр года соответственно. Нужно отметить, что при YEAR(2) диапазон дат принимается с 1970 по 2069 годы.

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

Перспективы развития сетевых баз данных

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

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

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

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

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

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

2. Направление Exodus/Genesis. Основная характеристика: создание собственно не системы, а генератора систем, наиболее полно соответствующих потребностям приложений. Решение достигается путем создания наборов модулей со стандартизованными интерфейсами, причем идея распространяется вплоть до самых базисных слоев системы.

3. Направление Starburst. Основная характеристика: достижение расширяемости системы и ее приспосабливаемости к нуждам конкретных приложений путем использования стандартного механизма управления правилами. По сути дела, система представляет собой некоторый интерпретатор системы правил и набор модулей-действий, вызываемых в соответствии с этими правилами. Можно изменять наборы правил (существует специальный язык задания правил) или изменять действия, подставляя другие модули с тем же интерфейсом.

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

Список литературы

1. Браун М., Ханикатт Д. “HTML 3.2”, К., 2006

2. Вьюкова Н.И., Галатенко В.А., “Информационная безопасность систем управления базами данных”, СУБД № 1 2001

3. Грабер М., “Справочное руководство по SQL”, М., 2002

4. Дейта К. “Введение в системные баз данных”, М., 1999

5. Дунаев С.Б. “Intranet-технологии.”, М., 1997

6. Кириллов В.В. “Структуризованный язык запросов (SQL)”, М.,1997

7. Кузнецов С.Д. “Основы современных баз данных”, К., 1999

8. Кузнецов С.Д. “Безопасность и целостность или, Худший враг себе - это ты сам”, СПб., 1998

9. Мейер М. “Теория реляционных баз данных”, М.,2006

10. ЦНИТ НГУ. “Использование технологий WWW для доступа к базам данных”, Н., 1997

11. Шпеник М., Следж О. и др. “Руководство администратора баз данных Microsoft SQL Server 7.0”, М., 1999

12. "SQL Полное руководство" К., 2008

Подобные документы

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

презентация , добавлен 01.12.2015


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

реферат , добавлен 29.11.2010


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

лекция , добавлен 19.08.2013


Основные понятия базы данных и систем управления базами данных. Типы данных, с которыми работают базы Microsoft Access. Классификация СУБД и их основные характеристики. Постреляционные базы данных. Тенденции в мире современных информационных систем.

курсовая работа , добавлен 28.01.2014


Общее понятие и признаки классификации информационных систем. Типы архитектур построения информационных систем. Основные компоненты и свойства базы данных. Основные отличия файловых систем и систем баз данных. Архитектура клиент-сервер и ее пользователи.

презентация , добавлен 22.01.2016


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

дипломная работа , добавлен 26.07.2009


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

реферат , добавлен 01.11.2009


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

курсовая работа , добавлен 02.03.2014


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

реферат , добавлен 20.12.2010


Классификации баз данных по характеру сберегаемой информации, способу хранения данных и структуре их организации. Современные системы управления базами данных и программы для их создания: Microsoft Office Access, Cronos Plus, Base Editor, My SQL.

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

В середине 60-х годов корпорация IBM совместно с фирмой NAA (North American Aviation, в настоящее время - Rockwell International) разработали первую СУБД - иерархическую систему IMS (Information Management System). Несмотря на то, что IMS является самой первой из всех коммерческих СУБД, она до сих пор остается основной иерархической СУБД, используемой на большинстве крупных мейнфреймов.

Другим заметным достижением середины 60-х годов было появление системы IDS (Integrated Data Store) фирмы General Electric. Развитие этой системы привело к созданию нового типа систем управления базами данных - сетевых СУБД, что оказало существенное влияние на информационные системы того поколения. Сетевая СУБД создавалась для представления более сложных взаимосвязей между данными, чем те, которые можно было моделировать с помощью иерархических структур, и послужили основой для разработки первых стандартов БД.

Для создания стандартов структур хранения данных в 1965 году на конференции CODASYL (Conference on Data Systems Languages) была сформирована рабочая группа List Processing Task Force, переименованная в 1967 году в группу Data Base Task Group (DBTG). В компетенцию группы DBTG входило определение спецификаций среды, которая допускала бы разработку баз данных и управление данными.

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

Группа DBTG также предложила стандартизировать три различных языка: o язык определения данных DDL для схемы, который позволит администратору базы данных (АБД) описать ее o язык определения данных (также DDL) для подсхемы, который позволит определять в прикладных программах те части базы данных, доступ к которым будет необходим o язык манипулирования данными DML, предназначенный для управления данными

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

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

В 1970 году Э. Ф. Кодд, работавший в корпорации IBM, опубликовал статью о реляционной модели данных, позволявшей устранить недостатки прежних моделей. Появилось множество экспериментальных реляционных СУБД, а первые коммерческие продукты появились в конце 70-х - начале 80-х годов. Известен проект System R, разработанный в корпорации IBM в конце 70-х годов (Astrahan et al., 1976), задуман с целью доказать практичность реляционной модели, что достигалось посредством реализации предусмотренных ею структур данных и требуемых функциональных возможностей.

На основе этого проекта были получены важнейшие результаты: o был разработан структурированный язык запросов SQL, который с тех пор стал стандартным языком любых реляционных СУБД o в 80-х годах были созданы различные коммерческие реляционные СУБД - например, DB2 или SQL/DS корпорации IBM, Oracle корпорации Oracle, др.

Реляционные СУБД относятся к СУБД второго поколения, существует несколько сотен различных реляционных СУБД для мейнфреймов и персональных ЭВМ. Примеры многопользовательских реляционных СУБД: CA-OpenIngres фирмы Computer Associates, Informix фирмы Informix Software, Inc. Примеры реляционных СУБД для персональных компьютеров: Access фирмы Microsoft, FoxPro, R-Base фирмы Microrim и т.д. Реляционная модель обладает некоторыми недостатками: ограниченными возможностями моделирования. Для решения этой проблемы в 1976 году Чен предложил модель "сущность-связь" (Entity-relationship model - ER-модель), которая в настоящее время стала самой распространенной технологией и основой методологии проектирования баз данных.

В 1979 году Кодд сделал попытку устранить недостатки собственной основополагающей работы и опубликовал расширенную версию реляционной модели - RM/T (1979), затем еще одну версию - RM/V2 (1990). Попытки создания модели данных, позволяющей более точно описывать реальный мир, нестрого называют семантическим моделированием данных (semantic data modeling).

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

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

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

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

База данных хранит не только рабочие данные, но и их описания. По этой причине базу данных еще называют набором интегрированных записей с самоописанием. В совокупности, описание данных называется системным каталогом (system catalog), или словарем данных (data dictionary), а сами элементы описания – метаданными (meta-data), т.е. данными о данных.

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

В базах данных используется термин "логически связанные данные", когда при анализе информационных потребностей организации следует выделить: o сущность (entity)- отдельный тип объекта, который нужно представить в базе данных o атрибут (attribute)- свойство, которое описывает некоторую характеристику рассматриваемого объекта o связь (relationship) это то, что объединяет несколько сущностей

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

Возможности СУБД: o позволяет определять базу данных с помощью языка определения данных (DDL – Data Definition Language). o позволяет вставлять, обновлять, удалять и извлекать информацию из базы данных с помощью языка управления данными (DML – Data Manipulation Language).

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

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

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

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

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

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

Администратор базы данных (Database Administrator) отвечает за: o физическую реализацию базы данных, включая физическое o проектирование и воплощение проекта o обеспечение безопасности и целостности данных o сопровождение операционной системы o обеспечение максимальной производительности приложений пользователей

Разработчик логической базы данных Занимается идентификацией данных, связей между данными и устанавливает ограничения, накладываемые на хранимые данные. Должен быть всесторонним и в полном объеме понимать структуры данных организации и ее бизнес-правил. Работа разработчика делится на два этапа: o концептуальное проектирование базы данных o логическое проектирование базы данных

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

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

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

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

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