В развитии технологии баз данных выделяют 4 этапа.
Первый этап связан с развитием баз данных на больших машинах типа IBM 360/370, ЕС ЭВМ.
История развития систем управления базой данных (СУБД) насчитывает более 30 лет. В 1968 г. была введена в эксплуатацию первая промышленная СУБД фирмы IBM. В 1975 г. появился первый стандарт ассоциации по языкам систем обработки данных Conference of Data System Languages (CODASYL), определивший ряд фундаментальных понятий в теории баз систем данных. В 1981 г. Э.Ф. Кодд получил премию Тьюринга за разработку реляционной модели и реляционной алгебры.
Базы данных хранились во внешней памяти центральной ЭВМ, пользователями этих баз были задачи, запускаемые в основном в пакетном режиме. Интерактивный режим доступа обеспечивался с помощью консольных терминалов, не обладавших собственными вычислительными ресурсами. Эти системы относят к системам распределенного доступа.
Второй этап связан с появлением и развитием персональных компьютеров. На этом этапе преобладают настольные СУБД в частности: Dbase, FoxPro, Clipper, Paradox.
Третий этап. Начался процесс интеграции. Этот этап связан с развитием компьютерных сетей, поэтому остро встает задача согласованности данных хранящихся и обрабатываемых в разных местах и логически друг с другом не связанных. Успешное решение этих задач приводит к появлению распределенных баз данных.
Особенности этого этапа:
Поддержка структурной и языковой целостности;
Возможность работы на компьютерах с различной архитектурой;
Поддержка многопользовательского режима и возможность децентрализованного хранения данных.
К этому этапу относятся СУБД Access`97, Oracle 7.3(8.4), MS SQL 6.5(7.0) System 10(11).
Четвертый этап определяет перспективы развития СУБД. Этот этап характеризуется появлением новой технологии доступа к данным – интранет. В этой технологии не используется специализированное клиентское программное обеспечение. Для работы с удаленной базой данных можно применить Internet Explorer и др.
Общепринятые обозначения
Введение
Предметом изучениякурса являются базы данных (БД); принципы и методы построения, жизненный цикл и типология БД; распределенные и объектно-ориентированные БД; организация процессов обработки данных в БД; ограничения целостности; технология оперативной обработки транзакции (ОLТР‑технология); информационные хранилища; сопряжение различных СУБД и языков програмирования; освоение и практическое использование современных СУБД и языка запросов SQL.
Учебное пособие содержит основные понятия, термины и определения теории проектирования баз данных, компактное описание языка запросов SQL и современных СУБД Access, Visual FoxPro, Microsoft SQL Server, Oracle с примерами и упражнениями и обзор других СУБД.
В конце каждой главы даны контрольные вопросы и вопросы для самопроверки с ответами (прил. 1). По этим вопросам проводятся тестирование на компьютере.
В период изучения курса студенты выполняют лабораторные работы (пункты 7.1, 7.2) ‑ по несколько задач из соответствующего пункта, одну курсовую работу (п. 7.3, прил. 6) и сдают экзамен (прил. 2).
Для описания команд, операторов, функций, методов, сценариев диалога, рисунков используются обозначения:
[...] ‑ не обязательная конструкция;
<...> ‑ конструкция, которая указывается пользователем;
{...|...|...} ‑ список конструкций возможных вариантов для выбора;
... ‑ повторение предыдущей конструкции требуемое число раз;
.../.../... ‑ команды подменю, страниц, кнопок и других элементов диалога;
<номер пункта>.<порядковый номер рисунка в пункте> ‑ нумерация рисунка в пункте (рисунок 1.3.5.2).
Значения, принятые по умолчанию, подчеркиваются.
Порядок изучения и классификация учебного материала
| Главы | Уровень изучения материала | ||
| Начальный | Основной | Углубленный | |
| Глава 1. Проектирование баз данных | 1.1, 1.2, 1.3.1-1.3.3,1.12 | 1.3.4‑1.3.8, 1.4.1, 1.4.2, 1.5.1., 1.5.2 | 1.3.9-1.3.11, 1.4.3-1.4.5, 1.5.3‑1.5.6, 1.6-1.11 |
| Глава 2. СУБД Visual FoxPro | 2.1-2.3, 2.4.1‑2.4.3, 2.4.5 2.8-2.10 | 2.4.4, 2.4.6‑2.4.17, 2.4.23, 2.11-2.15 | 2.4.18-2.4.22, 2.5-2.7, 2.16-2.23 |
| Глава 3. СУБД Access | 3.1, 3.2, 3.4, 3.5.1, 3.5.2, 3.6.1, 3.6.2, 3.7.2-3.7.4, 3.7.6 | 3.3 3.6.3-3.6.5, 3.7.1, 3.17, 3.18 | 3.5.3, 3.5.4, 3.6.6, 3.7.5, 3.7.7, 3.8-3.16 |
| Глава 4. СУБД SQL Server | 4.1, 4.2, 4.3.1-4.3.4, 4.3.9, 4.3.10 | 4.3.5, 4.3.6.1-4.3.6.3, 4.3.6.6, 4.3.6.7, 4.3.7 | 4.3.6.4-4.3.6.5, 4.3.6.8-4.3.6.13, 4.3.8, 4.4 |
| Глава 5. СУБД Oracle | 5.1, 5.2, 5.4.1-5.4.3, 5.4.4.1 | 5.3, 5.4.4.3, 5.4.6, 5.4.7, 5.4.9, 5.4.10 | 5.4.4.2, 5.4.4.4, 5.4.5, 5.4.8, 5.4.11 |
| Глава 6. Обзор СУБД | 6.7-6.9 | 6.2, 6.3 | 6.1, 6.4-6.6, 6.10-6.14 |
| Глава 7. Практикум | 7.1.1 | 7.1.2 | 7.1.3 |
Свои предложения и замечания можно посылать по электронной почте: [email protected].
Глава 1. Проектирование баз данных
Важным шагом в развитии информатики был переход к использованию централизованных систем управления файлами (содержание данного пункта скопировано из работы ). Пользователи могут выполнить с файлами ряд стандартных операций: создать файл, открыть, прочитать из файла некоторую запись (текущую, следующую, предыдущую, первую, последнюю), записать в файл на место текущей записи новую, добавить новую запись в конец файла. Структура записи файла была известна только программе, которая с ним работала, система управления файлами не знала ее. При изменении структуры файла требовалось изменять структуру программы, а это требовало новой компиляции. Такая ситуации характеризовалась как зависимость программ от данных. Это было первым существенным недостатком файловых систем, который явился толчком к созданию новых систем хранения и управления информацией.
Далее, поскольку файловые системы являются общим хранилищем файлов, принадлежащих, вообще говоря, разным пользователям, системы управления файлами должны обеспечивать авторизацию доступа к файлам. И отсутствие централизованных методов управления доступом к информации послужило еще одной причиной разработки СУБД.
Следующей причиной стала необходимость обеспечения эффективной параллельной работы многих пользователей с одними и теми же файлами. В общем случае системы управления файлами обеспечивали режим многопользовательского доступа. Если операционная система поддерживает многопользовательский режим, вполне реальна ситуация, когда два или более пользователя одновременно пытаются работать с одним и тем же файлом. Если все пользователи собираются только читать файл, ничего страшного не произойдет. Но если хотя бы один из них будет изменять файл, для корректной работы этих пользователей требуется взаимная синхронизация их действий по отношению к файлу. В системах управления файлами обычно применялся следующий подход. В операции открытия файла (первой и обязательной операции, с которой должен начинаться сеанс работы с файлом) среди прочих параметров указывался режим работы (чтение или изменение). Если к моменту выполнения этой операции некоторым пользовательским процессом PR1 файл был уже открыт другим процессом PR2 в режиме изменения, то в зависимости от особенностей системы процессу PR1 либо сообщалось о невозможности открытия файла, либо он блокировался до тех пор, пока в процессе PR2 не выполнялась операция закрытия файла.
При подобном способе организации одновременная работа нескольких пользователей, связанная с модификацией данных в файле, либо вообще не реализовывалась, либо была очень замедлена.
Эти недостатки послужили тем толчком, который заставил разработчиков информационных систем предложить новый подход к управлению информацией. Этот подход был реализован в рамках новых программных систем, названных впоследствии Системами Управления Базами Данных (СУБД), а сами хранилища информации, которые работали под управлением данных систем, назывались базами или банками данных (БД и БнД).
Первый этап развития СУБД связан с организацией баз данных на больших машинах типа IBM 360/370, ЕС-ЭВМ и мини-ЭВМ типа PDP11 (фирмы Digital Equipment Corporation – DEC), разных моделях HP (фирмы Hewlett Packard). Базы данных хранились во внешней памяти центральной ЭВМ, пользователями этих баз данных были задачи, запускаемые в основном в пакетном режиме. Интерактивный режим доступа обеспечивался с помощью консольных терминалов, которые не обладали собственными вычислительными ресурсами (процессором, внешней памятью) и служили только устройствами ввода-вывода для центральной ЭВМ. Программы доступа к БД писались на различных языках и запускались как обычные программы. Эти системы можно было отнести к системам распределенного доступа, потому что база данных была централизованной, хранилась на устройствах внешней памяти одной центральной ЭВМ, а доступ к ней поддерживался от многих пользователей-задач.
Второй этап связан с появлением персональных компьютеров
Появились СУБД которые позволяли хранить значительные объемы информации, они имели удобный интерфейс для заполнения данных, встроенные средства для генерации различных отчетов.
Особенности этого этапа следующие:
Все СУБД были рассчитаны на создание БД в основном с монопольным доступом.
Большинство СУБД имели развитый и удобный пользовательский интерфейс. В большинстве существовал интерактивный режим работы с БД как в рамках описания БД, так и в рамках проектирования запросов. Кроме того, большинство СУБД предлагали развитый и удобный инструментарий для разработки готовых приложений без программирования. Инструментальная среда состояла из готовых элементов приложения в виде шаблонов экранных форм, отчетов, этикеток, графических конструкторов запросов, которые достаточно просто могли быть собраны в единый комплекс.
Во всех настольных СУБД поддерживался только внешний уровень представления реляционной модели, то есть только внешний табличный вид структур данных.
При наличии высокоуровневых языков манипулирования данными типа SQL в настольных СУБД поддерживались низкоуровневые языки манипулирования данными на уровне отдельных строк таблиц.
В настольных СУБД отсутствовали средства поддержки ссылочной и структурной целостности базы данных. Э
Наличие монопольного режима работы фактически привело к вырождению функций администрирования БД и в связи с этим – к отсутствию инструментальных средств администрирования БД.
Сравнительно скромные требования к аппаратному обеспечению со стороны настольных СУБД.
Яркие представители этого семейства – очень широко использовавшиеся до недавнего времени СУБД Dbase (DbaseIII+, DbaselV), FoxPro, Clipper, Paradox.
Наибольшую популярность среди настольных систем, функционирующих в среде DOS, завоевали реляционные СУБД Dbase (компания Ashton-Tate), Paradox (Borland), R:base (Mierorim), FoxPro (Fox Software), Clipper 5.0 (Nantucket), db_VISTA (Raima) с сетевой моделью данных.
В течение продолжительного периода времени широко использовались СУБД, совместимые со стандартом Xbase. Однако доля Xbase на рынке настольных СУБД сокращается. СУБД Dbase, FoxBase, FoxPro являются представителями этого семейства. СУБД Dbase имеют простой командный язык манипулирования данными и пользовательский интерфейс типа меню, средства генерации отчетов и экранных форм. Эта СУБД отличается хорошим быстродействием при выполнении запросов в небольших базах данных. В большинстве реляционных СУБД этого поколения, работающих в среде DOS, программы на базовом языке выполняются в режиме интерпретации, то есть заранее не преобразовываются в машинный код, что снижает их производительность.
Система db_VISTA, с включающим универсальным языком С, поддерживает сетевую модель. Она пользовалась популярностью среди профессиональных программистов. Областью ее применения, в частности, являются банковские информационные системы. К сетевым СУБД относится также AdabasD, которая предназначена для создания больших баз данных и может работать на разных платформах (техническая и программная среда).
Реляционная СУБД Paradox (версии 3.5, 4.0, 5.0) появилась на рынке в 1985г. Она отличается от семейства Xbase-продуктов запросами по образцу (QBE), генератором приложений на основе объектного подхода, настраиваемым меню пользователя, диалоговыми средствами и автоматическим формированием макросов, в которых можно запомнить все отлаженные пользователем процессы. В Paradox используется, кроме языка запросов QBE, базовый язык программирования PAL (Paradox Application Language) -- язык для разработки приложений. Paradox, как и семейство Xbase, хранит свои объекты (таблицы, формы, отчеты, макросы) в отдельных файлах и обладает достаточной гибкостью, что позволяет модифицировать базу данных без перезагрузки данных. Обеспечивается создание сложных форм для нормализованных таблиц, через которые можно однократно вводить данные с внемашинных документов. Создание форм, запросов, отчетов, макросов легко выполняет пользователь-непрограммист. Для выполнения запроса в Paradox достаточно заполнить бланки запроса, которые на экране отображаются структурой таблицы базы данных.
К мощным реляционным СУБД профессионального класса относится PROGRESS (фирмы Progress Software Co., USA). Она имеет встроенный язык SQL и собственный язык 4GL, может работать на разнообразных программно-аппаратных платформах, поддерживает архитектуру клиент-сервер.
Перспективы развития архитектур СУБД связаны с развитием концепции обработки нетрадиционных данных и их интеграции, обмена данными из разных СУБД, многопользовательской технологии в локальных сетях.
С 1996 г. операционная система Windows 95 стала стандартом для настольных ПК. Для использования преимуществ этой операционной системы необходим переход к использованию 32-разрядных СУБД нижнего уровня. Наиболее известными и популярными СУБД такого типа являются: Access (Microsoft), Paradox 7 for Windows 95 and Windows NT (Borland) и Approach for Windows 95 (Lotus).
Относительно простой в изучении и использовании считается Approach for Windows 95, которая ориентирована на разработку несложных приложений. Более совершенными, обладающими мощным языком разработки приложений пользователя являются две первые из названных СУБД -- Paradox и Access.
К общим свойствам СУБД Approach, Paradox и Access относятся:
Графический многооконный интерфейс, позволяющий пользователю в диалоговом режиме создавать таблицы, формы, запросы, отчеты и макросы;
Специальные средства, автоматизирующие работу, -- многочисленные мастера (Wizards) в Access, ассистенты (Assistants) в Approach и эксперты (Experts) в Paradox;
Возможность работы в локальном режиме или в режиме клиента на рабочей станции (Windows NT 3.51, Novell NetWare 4.1);
Использование объектной технологии OLE2 для внедрения в базу данных разной природы (текстов, электронных таблиц, изображений и т. п.);
Наличие собственного языка программирования.
Особенности СУБД Approach, Paradox, Access:
В Approach, в отличие от Paradox и Access, не обеспечивается полная поддержка языка запросов SQL, что ограничивает ее возможности в многопользовательских системах только просмотром данных;
В Access предусмотрена автоматическая генерация кода SQL при создании запроса пользователем;
В Approach язык для разработки приложений Lotus Script уступает по интеграционным возможностям и удобству работы объектноориентированным языкам (в Paradox -- ObjectPAL, в Access -- Visual Basic);
Visual Basic в Access является наиболее мощным языком программирования, которым обладает свойством автономности от СУБД и переносимости в другие приложения Microsoft Office, обеспечивая хорошую интеграцию данных;
В Access имеется Мастер анализа таблиц, с помощью которого можно выполнить нормализацию таблицы.
Одной из важнейших тенденции развития СУБД является разработка «универсальных» СУБД, способных интегрировать в базе традиционные и нетрадиционные данные -- тексты, рисунки, звук и видео, страницы HTML и др. Это особенно актуально для Web. Имеются два подхода к построению таких СУБД; объектно-реляционный -- совершенствование существующих реляционных СУБД и объектный.
Следует отметить, что современные реляционные СУБД уже способны интегрировать данные, однако нетрадиционные данные недоступны для внутренней обработки. «Универсальные» СУБД должны выполнять такую обработку. В таких системах не нужны разнородные программы, которыми сложно управлять. По пути создания объектно-реляционных СУБД пошли такие фирмы, как IBM, Informix и Oracle. В IBM разработана объектно-реляционная СУБД DB2 для ОС AIX и OS, 2. На начальном этапе фирма Oracle выпустила реляционный продукт Oracle Universal Server, интегрирующий СУБД Oracle 7.3 и специализированные серверы (Web, пространственных данных, текстов, видеосообщений), поддерживающие данные в разных хранилищах. В объекто-реляцпонной Oracle 8 должны быть интегрированы реляционные и нетрадиционные типы данных. Informix создала объектно-реляционную СУБД Universal Server.
Корпорация Microsoft сделала ставку на объектно-ориентированный интерфейсOLE DB, который обеспечивает доступ к данным Microsoft SQL Server (реляционная СУБД).
Фирма Sybase ориентирована на использование специализированных серверов, а интеграцию данных намеревается проводить другими средствами, то есть идет по пути создания объектно-реляционной СУБД (Adaptive-Server).
Информационные хранилища на базе СУБД с параллельной обработкой рассчитаны на многопроцессорные системы. Такие СУБД разделяются по типу архитектуры -- без разделения ресурсов и с совместным использованием дискового пространства. В нервом случае за каждым из процессоров закреплены выделенные области памяти и диски, что дает хорошую скорость обработки. Во втором случае все процессоры делят между собой как оперативную память, так и место на диске.
Примерами СУБД без разделения ресурсов являются: DB2 (IBM), Informix Online Dynamic (Informix), Navigation Server (Sybase). СУБД с совместным использованием памяти является AdabasD версия 6.1 (Software AG). В СУБД Oracle 7.2 обеспечивается лучшая переносимость на различные платформы. Следует заметить, что выбор СУБД целесообразно осуществлять не только по типу архитектуры и качеству внешнего интерфейса, но прежде всего исходя из функциональных возможностей. Важными критериями выбора являются способность обработки сложных запросов (и скорость обработки), возможность переноса между платформами. Хорошей скоростью обработки сложных запросов отличается СУБД DB2 (IBM), а также DSA (Informix).
Классификация современных СУБД
К важным признакам классификации современных СУБД относятся:
Среда функционирования -- класс компьютеров и операционных систем (платформа), на которых работает СУБД, в том числе разрядность операционной системы, на которую ориентирована СУБД (16- или 32-разрядные);
Тип поддерживаемой в СУБД модели данных -- сетевая, иерархическая или реляционная;
Возможности встроенного языка СУБД, его переносимость в другие приложения (SQL, Visual Basic, ObjectPAL и т. п.);
Наличие развитых диалоговых средств конструирования (таблиц, форм, запросов, отчетов, макросов) и средств работы с базой данных;
Возможность работы с нетрадиционными данными в корпоративных сетях (страницы HTML, сообщения электронной почты, изображения, звуковые файлы, видеоклипы и т. п.);
Используемая концепция работы с нетрадиционными данными -- объектно-реляционные, объектные;
Уровень использования -- локальная (для настольных систем), архитектура клиент-сервер, с параллельной обработкой данных (многопроцессорная);
Использование объектной технологии OLE 2.0;
Возможности интеграции данных из разных СУБД;
Степень поддержки языка SQL и возможности работы с сервером баз данных (SQL-сервером);
Наличие средств отчуждаемых приложений, позволяющих не проводить полной инсталляции СУБД для тиражируемых приложений пользователя.
Я сейчас довольно активно работаю с базами данных и с СУБД 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). Однако в отличие от предыдущих моделей действительная структура этих моделей не совсем ясна. Попытки реализации подобных моделей представляют собой СУБД третьего поколения.
