История развития баз данных. Краткая история развития баз данных История создания и развития баз данных
Наибольшую популярность среди настольных систем, функционирующих в среде 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-сервером);
Наличие средств отчуждаемых приложений, позволяющих не проводить полной инсталляции СУБД для тиражируемых приложений пользователя.
История развития баз данных………………………………………………3-5
Начальные понятия. Этапы………………………………………………..6-8
Особенности и требования………………………………………………9-10
Заключение………………………………………………………………12-13
Используемые сайты………………………………………………………..14
История развития баз данных.
История развития баз данных уходит корнями в 1960-е годы. В те времена информация собиралась и хранилась в файлах. Каждый файл содержал определенные сведения и для охвата всей предметной области требовалось несколько файлов. Например, сведения о товарах хранились в одном файле, а сведения о клиентах - в другом. Информация о приобретении определенных товаров определенными клиентами - в третьем. Такая организация данных вносила свои сложности:
· представление данных в каждом файле было различным;
· необходимо было согласовывать данные в разных файлах для обеспечения непротиворечивости информации;
· необходимо было выбрать какие данные и в каком виде будут фигурировать в таких файлах, как файл приобретений товаров в примере;
· сложность разработки приложений и их обновления при изменении данных.
· Ситуация требовала улучшения и множество специалистов усердно работали над созданием чего-то более удобного в использовании. В начале 1970-х годов, спустя примерно 10 лет, ситуация начала улучшаться и появились первые базы данных.
В 1970 году Э. Ф. Кодд опубликовал статью, которая послужила основой для создания реляционной модели данных. Приемущество такой модели хранения данных заключается в минимальном дублировании данных и исключении некоторых типов ошибок, свойственных другим моделям. Согласно этой модели, данные хранятся в виде таблиц со столбцами и строками. Не все виды таблиц приемлемы для реляционной модели и нежелательные таблицы могут быть нормализованы для удовлетворения требованиям реляционной модели. В процессе нормализации таблица как-правило разбиваются на две или несколько более приемлемых таблиц.
В 1979 году небольшая компания Ashton-Tate выпустила продукт для микрокомпьютеров под названием dBase-II, назвав его реляционной СУБД. Благодаря успешной тактике, компании удалось распространить более 100 000 копий продукта среди пользователей компьютеров Osborne. Многие из пользователей компьютеров создавали программы для них и вскоре dBase стала очень популярной СУБД. В последствии Ashton-Tate была приобретена фирмой Borland. На самом деле продукт dBase не являлся реляционной СУБД, а представлял из себя язык программирования с расширенными функциями для обработки файлов. Пока развивалась dBase, другие производители начали перенос на микрокомпьютеры своих коммерческих СУБД для больших ЭВМ. Примерами таких СУБД являются Oracle, Ingress и Focus. Перенос СУБД на микрокомпьютеры послужил причиной улучшения пользовательского интерфейса, что повлекло за собой увеличение числа микрокомпьютеров, работающих с базами данных.
В середине 1980-х годов пользователи начали объединять свои компьютеры в локальные сети, что привело к возникновению клиент-серверной модели, а так же модели с совместным использованием файлов. Сеть позволяла совместно использовать дорогие принтеры и дисковые накопители большой емкости. В перспективе же пользователи хотели совместного использования их баз данных, что стимулировало развитие многопользовательских приложений баз данных для локальных сетей. Поскольку многопользовательская обработка данных в локальной сети отличается от многопользовательской обработки данных на мейнфрейме наличием нескольких вычислителей, возникали дополнительные сложности по координации действий вычислителей. Так появилась клиент-серверная архитектура обработки данных. Существует и более простая, но менее надежная архитектура, снованная на совместном использовании файлов.
В наши дни активно развиваются web-приложения баз данных, а так же базы данных с использованием Internet-технологий. Web-приложения баз данных делают данные доступными через обозреватель пользователя, в то время как базы данных с использованием Internet-технологий просто используют клиентские обозреватели и технологии типа XML и DHTML для работы с базой данных, не публикуя данные через Internet.
Существует еще две технологии баз данных, которые являются возможными, но пока не реализованы. Это объектно-ориентированные базы данных и распределенные базы данных. Распределенные базы данных представляют собой базу данных организации, распределенную по нескольким компьютерам локальной сети организации. Благодаря такой архитектуре возможно более гибкое разделение нагрузки по отделам предприятия, но реализация такой системой связана с радом проблем, некоторые из которых не решены до сих пор. Объектно-ориентированные базы данных позиционируются как средство для хранения структур данных, используемых
в объектно-ориентированном программировании. Поскольку объекты на порядок сложнее структур, то и реализация баз данных будет довольно сложной. Плюс ко всему, развитие объектно-ориентированных баз данных сдерживается наличием огромного количества реляционных БД, в которых хранятся огромные массивы информации.
Существуют различные определения базы данных. Обычно они либо неполны, либо слишком громоздки. Дадим простое определение, расширяя его по мере появления новых понятий.
Базой данных (БД) называют совокупность взаимосвязанных данных на машинных носителях, предназначенных для использования в интерактивном (диалоговом) режиме доступа и в программных приложениях. Обычно БД создается для хранения и доступа к данным из некоторой предметной области, то есть представляет собой информационную модель класса объектов.
Система управления базой данных (СУБД) – это языковые и программные средства для организации, пополнения, модификации и использования БД. Различают универсальные и специализированные СУБД. Универсальные СУБД являются системами широкого профиля и не имеют четко очереченных границ применения, а специализированные создаются для БД конкретного назначения: банковских, бухгалтерских и т. д. Специализированные СУБД в наибольшей степени учитывают специфику предметной области, что отражается в интерфейсе и процедурах обработки информации.
Выделяют класс промышленных или коммерческих СУБД как систем, разработанных профессиональными компаниями в области создания программного обеспечения, апробированных на практике и тиражируемых на некоторых коммерческих условиях. Промышленные СУБД относительно дешевы, достаточно надежны и документированы. Обычно их появлению предшествуют опытные разработки, пробные версии, предварительные публикации и т.п.
Начальные понятия. Этапы.
Администратором БД называют человека или группу лиц, ответственных за обслуживание БД. Администратор распределяет права доступа к информации, вносит изменения в структуру БД, отвечает за сохранность данных и их восстановление в случае сбоев, модернизирует программное обеспечение по мере появления новых версий. Администратор должен обладать квалификацией системного программиста и в то же время четко представлять проблемы пользователей.
Физическое описание данных это способы представление информации на машинных носителях.
Логическое описание данных это представление информации с точки зрения пользователя.
Логическое представление данных не всегда строго соответствует физическому. Например, пользователь представляет файл как нечто целое и неделимое, однако на внешних носителях файл может представляться фрагментировано, по кластерам. Более того, некоторые поля, такие как тексты неопределенной длины или изображения, могут физически размещаться в других файлах.
Физическая независимость данных – возможность изменения физического размещения данных без изменения их логической структуры и прикладных программ.
Логическая независимость данных – возможность изменения логической структуры данных (добавление новых полей, изменение порядка полей и их размерости) с сохранением работоспособности приложений, использующих прежнее представление.
Например, физическая независимость данных поддерживается обычно средствами операционной системы. Логическая независимость данных не обеспечивается в приложениях на Паскале и С.
Концепция БД сложилась в конце 60-х годов прошлого столетия и с тех пор постоянно развивалась. Известный специалист в области БД Д. Мартин рассматривает несколько этапов в развитии технологии обработки данных.
Первый этап сложился к началу 60-х годов прошлого века и характеризуется следующими признаками:
· информация преимущественно хранится в последовательных файлах на магнитных лентах;
· физическая структура данных строго соответствует логической;
· в качестве архива хранятся несколько копий файлов;
· файлы предназначены для единственной программы;
· программист планирует не только логическую, но и физическую организацию данных;
· при изменении физической или логической организации данных программа должна перерабатываться.
Недостатки первого этапа очевидны. Привязка файлов к одной программе приводит к многократному дублированию и противоречивости информации в разных приложениях. Трудоемкость разработки программ увеличивается, поскольку каждый программист должен предусматривать процедуры доступа к данным и их модификации. Даже при незначительных изменениях структуры данных прикладные программы должны корректироваться.
Второй этап относится к середине 60-х годов и имеет следующие особенности:
· появились внешние устройства прямого доступа, позволившие осуществить произвольный доступ к записям (прямой, индексно-последовательный);
· вошли в употребление процедуры поиска записи по ключевому полю (обычно одному);
· стало возможным переносить файлы на другие внешние устройства без изменения прикладных программ, что обычно обеспечивалось средствами языка управления данными соответствующей операционной системы.
Несмотря на очевидный прогресс, сохранились многие недостатки первого этапа.
Третий этап начался с конца 60-х годов. Основным достижением можно считать осознание необходимости централизации данных для доступа к ним различных приложений. При этом уменьшается избыточность и противоречивость информации, приложения используют стандартные средства доступа к данным. На этом этапе возросла сложность организации данных, был реализован эффективный поиск записей по многим ключам.
Именно на этом этапе появились первые СУБД. Прежде всего развивались теория и практика построения иерархических и сетевых СУБД. В этих моделях связи данных описываются с помощью деревьев и графов общего вида.
Четвертый этап датируется второй половиной 70-х годов. На этом этапе были реализованы в той или иной степени следующие основные характеристики СУБД:
· логическая и физическая независимость данных;
· удобство развтия БД;
· безопасность, секретность, целостность данных;
· поиск информации по различным запросам;
· языковые средства для администратора, прикладного программиста, пользователя-непрофессионала.
Безопасность, секретность и целостность данных – понятия близкие, но, тем не менее, различные. Под безопасностью понимают защиту данных от неавторизованной модификации помимо администратора СУБД. Секретность в общем случае означает запрет доступа к некоторой информации определенных пользователей. Наконец, целостность данных – это в первую очередь их непротиворечивость. Нарушения целостности возможны в случаях некорректной работы пользователей и сбоев оборудования.
С начала 70-х годов после публикаций Э. Кодда начались активные исследования реляционной модели данных. Основу реляционной СУБД составляют таблицы. Вплоть до 80-х годов реляционные СУБД считались перспективными, но трудными для реализации.
Опыт использования первых СУБД позволил выделить такие важные требования к ним, как:
· естественное представление различных структур данных;
· производительность;
· минимальные затраты на создание и поддержку БД;
· разнообразие возможностей поиска, в том числе незапланированных заранее;
· простота и дружественность;
· наличие непроцедурных языков пользователя (что получить, а не как).
Таким образом, к концу 70-х годов сформировались основные концепции СУБД, в соответствии с которыми были созданы первые промышленные СУБД. Они были в основном ориентированы не на рядовых пользователей, а на программистов достаточно высокой квалификации.
Новый этап в развитии СУБД наступил при появлениии персональных компьютеров. На этом этапе на передний план вышли такие особенности СУБД, как:
· дружественность и удобство работы пользователя (развитые диалоги, меню, оконный интерфейс, контекстная помощь);
· упрощение громоздких схем СУБД за счет частичной реализации ряда свойств;
· почти полный переход на реляционные СУБД;
· ориентация не только на программиста, но и на пользователя-непрофессионала;
· наличие средств автоматизации программирования в виде генераторов форм, меню, отчетов, запросов.
Новые СУБД распространялись вместе с персональными компьютерами ограмными тиражами. Так для СУБД dBase III Plus компании Ashton-Tate в 1986 году было зарегистрировано более 2 миллионов продаж. Вообще, СУБД линии dBase оказались одними из самых популярных. Язык программирования xBase, лежащий в их основе, стал классикой жанра. Не случайно ряд СУБД также использовали диалекты этого языка. В России особо популярными стали СУБД FoxBase+ и впоследствии FoxPro компании Fox Software, обладающие новыми возможностями по сравнению с dBase и непритязательные к техническим характеристикам компьютера. Позднее компания Fox Software была поглощена компанией MicroSoft, и соответствующие продукты выходили уже под ее маркой. Распространение получили такие СУБД как Paradox фирмы Borland, Access фирмы MicroSoft, сетевая СУБД dB Vista фирмы Raima Incorporation и многие другие. В России появились русифицированные версии некоторых из этих продуктов.
Дальнейший этап развития СУБД связан с возрастанием информационных потребностей и развитием сетевых технологий. Естественно, с усложнением архитектуры потребовались новые теоретические исследования, во много раз усложнилось и программное обеспечение.
Сначала получили распространение сетевые СУБД файл-серверной архитектуры. База данных в локальной сети централизованно хранится на специально выделенном компьютере, называемом файл-сервером. На клиентских местах устанавливаются копии СУБД. Необходимые данные запрашиваются по сети. В случае изменения БД корректирующая информация также отправляется по сети. При интенсивной работе с данными пропускная способность сети может оказаться недостаточной.
Клиент-серверные СУБД снижают трафик в сети. Клиент отправляет запрос к БД, который обрабатывается на сервере, возвращая полученный результат. Клиент-серверные СУБД могут масштабироваться до сотен и тысяч рабочих мест. Всеобщее распространение, подкрепленное стандартами, получил язык запросов SQL (Structured Query Language). Запрос к серверу формируется, как правило, на языке SQL, поэтому клиент-серверные СУБД стали называть SQL-серверами. Наиболее широко известны такие SQL-сервера как SQL Server, DB2, Oracle, Informix, Ingres, InterBase, MySQL.
Наконец, появились трехзвенные СУБД, в которых используется промежуточное звено – сервер приложений, являющийся посредником между клиентом и сервером БД. Сервер приложений призван полностью избавить клиента от забот по управлению данными. В результате получается "облегченный” клиент, не требующий больших ресурсов.
Одной из тенденций развития современных информационных технологий является распределенный характер информации. Данные находятся на компьютерах различных моделей, функционирующих под управлением различных операционных систем, а доступ к данным осуществляется разнородным программным обеспечением. Сами компьютеры территориально удалены друг от друга. Активно развивающиеся распределенные СУБД могут содержать сотни серверов БД и работать на предприятиях государственного масштаба. Интерес к распределенным СУБД в большой степени связан со стремительным развитием Интернета.
Основную часть рынка в настоящее время занимают реляционные СУБД. Вместе с тем многие приложения, такие как системы автоматизированного проектирования и управления, геоинформационные системы, системы хранения и поиска документов, системы мультимедиа и гипермедиа требуют более сложно организованных данных, которые не представимы в виде плоских таблиц. В связи с этим ведутся активные исследования и разработки в области создания объектно-ориентированных СУБД. Промежуточную позицию занимают объектно-реляционные СУБД, в которых прежние характеристики пытаются усилить новыми возможностями.
Заключение.
Хотя обработка баз данных всегда была важной темой, популярность Интернета сделала ее еще и одной из самых нужных специальностей. Навыки, которые вы разовьете, и знания, которые вы приобретете, будут чрезвычайно востребованы. Цель базы данных - помочь людям и организациям вести учет различных вещей. Хотя для этой цели можно использовать списки, они вызывают множество проблем. Их сложно изменять без возникновения несоответствий, удаления из списков могут иметь непредвиденные последствия, а неполные данные трудно записывать. Кроме того, вводя данные, легко вызвать их противоречивость. Наконец, различные части организации хотят поддерживать некоторые данные совместно, а некоторые - исключительным образом. Это трудно организовать при использовании списков.
Базы данных состоят из групп реляционных таблиц. В большинстве случаев каждая таблица содержит данные по определенной теме. Поддержка данных таким образом решает все проблемы, перечисленные для списков. Связи в таблицах представляются разными способами. В этой главе связи представлялись путем присвоения каждой строке уникального идентификатора и использования этого идентификатора для связи строки одной таблицы со строкой другой таблицы. Для представления связей использовались и внешние ключи. Таблицы можно создавать с помощью языка SQL, который является промышленным стандартом для обработки таблиц.
Система базы данных состоит из четырех основных элементов: пользователи, приложения базы данных, СУБД и сама база данных. Пользователи применяют базу данных для решения своих задач. Приложения производят формы, запросы и отчеты, выполняют логику приложения и управляют обработкой базы. СУБД создает, обрабатывает и администрирует базу данных. База данных - это самодокументированное собрание интегрированных записей. Она содержит пользовательские данные, метаданные, индексы, хранимые процедуры, триггеры и метаданные приложения. Хранимая процедура - это программа, которая обрабатывает участок базы данных и хранится в базе данных. Триггер - это процедура, которая вызывается при наступлении определенного события. На рис. 1.6 показаны функции компонентов базы данных.
Технология баз данных может использоваться в широком спектре приложений. Некоторые базы данных используются одним человеком, другие - группой людей, а третьи - большими организациями. В табл. 1.2 показаны некоторые характеристики этих разных типов баз данных.
Подобно всем информационным системам, системы баз данных разрабатываются в течение трех фаз: формулирования требований, проектирования и реализации. Во время фазы формулирования требований разрабатывается модель данных, или логическое представление структуры базы данных. Модели данных важны, потому что от них зависит проектирование базы данных и приложения. Диаграмма сущность-связь - средство, используемое для представления модели данных.
Модель данных преобразуется в таблицы и связи на фазе проектирования. Также проектируются индексы, ограничения, хранимые процедуры и триггеры. Диаграммы структур данных иногда используются для таблиц документов и их связей. Во время фазы реализации создаются таблицы, связи и ограничения, пишутся хранимые процедуры и триггеры, база данных заполняется данными и тестируется. Сегодня таблицы и связанные с ними конструкции создаются с помощью SQL или графических средств, являющихся частью СУБД.
Список сайтов.
http://www.pgtk.edu.ru/lections/doku.php?id=bd_history
http://citforum.ru/database/articles/temporal/
http://www.sql.ru/articles/mssql/2006/031701iintroductionindatabases.shtml
Похожая информация.
Первый этап - базы данных на больших ЭВМ . Первый этап развития СУБД связан с организацией баз данных на больших машинах типа IBM 360/370, ЕС-ЭВМ и мини-ЭВМ типа PDP11 (фирмы Digital Equipment Corporation - DEC), разных моделях HP (фирмы Hewlett Packard). Базы данных хранились во внешней памяти центральной ЭВМ, пользователями этих баз данных были задачи, запускаемые в основном в пакетном режиме. Интерактивный режим доступа обеспечивался с помощью консольных терминалов, которые не обладали собственными вычислительными ресурсами (процессором, внешней памятью) и служили только устройствами ввода-вывода для центральной ЭВМ.
Второй этап - эпоха персональных компьютеров . Появляется множество программ, предназначенных для работы неподготовленных пользователей. Эти программы просты в использовании и интуитивно понятны: это, прежде всего, различные редакторы текстов, электронные таблицы и другие. Каждый пользователь может автоматизировать многие аспекты деятельности. И, конечно, это сказалось и на работе с базами данных. Появились программы, которые назывались системами управления базами данных и позволяли хранить значительные объемы информации, они имели удобный интерфейс для заполнения данных, встроенные средства для генерации различных отчетов. Эти программы позволяли автоматизировать многие учетные функции, которые раньше велись вручную. Компьютеры стали инструментом для ведения документации и собственных учетных функций. Это все сыграло как положительную, так и отрицательную роль в области развития баз данных.
Третий этап - распределенные базы данных . Хорошо известно, что история развивается по спирали, поэтому после процесса «персонализации» начался обратный процесс - интеграция. Множится количество локальных сетей, все больше информации передастся между компьютерами, остро встает задача согласованности данных, хранящихся и обрабатывающихся в разных местах, но логически друг с другом связанных, возникают задачи, связанные с параллельной обработкой транзакций - последовательностей операций над БД, переводящих ее из одного непротиворечивого состояния в другое непротиворечивое состояние. Успешное решение этих задач приводит к появлению распределенных баз данных, сохраняющих все преимущества настольных СУБД и в то же время позволяющих организовать параллельную обработку информации и поддержку целостности БД.
Четвертый этап - перспективы развития систем управления базами данных . Этот этап характеризуется появлением новой технологии доступа к данным- интранет. Основное отличие этого подхода от технологии клиент-сервер состоит в том, что отпадает необходимость использования специализированного клиентского программного обеспечения. Для работы с удаленной базой данных используется стандартный броузер Internet, например Microsoft InternetExplorer, и для конечного пользователя процесс обращения к данным происходит аналогично использованию Internet. При этом встроенный в загружаемые пользователем HTML-страницы код, написанный обычно на языках Java, Java-script, Perl и других, отслеживает все действия пользователя и транслирует их в низкоуровневые SQL-запросы к базе данных, выполняя, таким образом, ту работу, которой в технологии клиент-сервер занимается клиентская программа.
Основы использования БД
Итак, начнем с самого начала. Что же такое база данных? База данных - организованная в соответствии с определёнными правилами и поддерживаемая в памяти компьютера совокупность данных, характеризующая актуальное состояние некоторой предметной области и используемая для удовлетворения информационных потребностей пользователей (Информация из Википедии)
Таким образом, к БД относятся:
Интерфейс для управления БД, называемый СУБД – Система управления базами данных
Собственно данные, хранящиеся в определенной форме
Существуют различные типы баз данных. Основной признак классификации – принцип хранения данных.
Реляционные
Объектно-ориентированные
Объектные
Объектно-реляционные
Иерархические
Файлы и файловые системы
Важным шагом в развитии именно информационных систем явился переход к использованию централизованных систем управления файлами. С точки зрения прикладной программы, файл - это именованная область внешней памяти, в которую можно записывать и из которой можно считывать данные. Правила именования файлов, способ доступа„к данным, хранящимся в файле, и структура этих данных зависят от конкретной системы управления файлами и, возможно, от типа файла. Система управления файлами берет на себя распределение внешней памяти, отображение имен файлов в соответствующие адреса во внешней памяти и обеспечение доступа к данным.
Конкретные модели файлов, используемые в системе управления файлами, мы рассмотрим далее, когда перейдем к физическим способам организации баз данных, а на этом этапе нам достаточно знать, что пользователи видят файл как линейную последовательность записей и могут выполнить над ним ряд стандартных операций:
создать файл (требуемого типа и размера);
записать в файл на место текущей записи новую, добавить новую запись в конец файла.
В разных файловых системах эти операции могли несколько отличаться, но общий смысл их был именно таким. Главное, что следует отметить, это то, что структура записи файла была известна только программе, которая с ним работала, система управления файлами не знала ее. И поэтому для того, чтобы извлечь некоторую информацию из файла, необходимо было точно знать структуру записи файла с точностью до бита. Каждая программа, работающая с файлом, должна была иметь у себя внутри структуру данных, соответствующую структуре этого файла. Поэтому при изменении структуры файла требовалось изменять структуру программы, а это требовало новой компиляции, то есть процесса перевода программы в исполняемые машинные коды. Такая ситуации характеризовалась как зависимость программ от данных. Для информационных систем характерным является наличие большого числа различных пользователей (программ), каждый из которых имеет свои специфические алгоритмы обработки информации, хранящейся в одних и тех же файлах. Изменение структуры файла, которое было необходимо для одной программы, требовало исправления и перекомпиляции и дополнительной отладки всех остальных программ, работающих с этим же файлом. Это было первым существенным недостатком файловых систем, который явился толчком к созданию новых систем хранения и управления информацией.
Далее, поскольку файловые системы являются общим хранилищем файлов, принадлежащих, вообще говоря, разным пользователям, системы управления файлами должны обеспечивать авторизацию доступа к файлам. В общем виде подход состоит в том, что по отношению к каждому зарегистрированному пользователю данной вычислительной системы для каждого существующего файла указываются действия, которые разрешены или запрещены данному пользователю. В большинстве современных систем управления файлами применяется подход к защите файлов, впервые реализованный в ОС UNIX. В этой ОС каждому зарегистрированному пользователю соответствует пара целочисленных идентификаторов; идентификатор группы, к которой относится этот пользователь, и его собственный идентификатор в группе. При каждом файле хранится полный идентификатор пользователя, который создал этот файл, и фиксируется, какие действия с файлом может производить его создатель, какие действия с файлом доступны для других пользователей той же группы и что могут делать с файлом пользователи других групп. Администрирование режимом доступа к файлу в основном выполняется его создателем-владельцем. Для множества файлов, отражающих информационную модель одной предметной области, такой децентрализованный принцип управления доступом вызывал дополнительные трудности. И отсутствие централизованных методов управления доступом к информации послужило еще одной причиной разработки СУБД.
Следующей причиной стала необходимость обеспечения эффективной параллельной работы многих пользователей с одними и теми же файлами. В общем случае системы управления файлами обеспечивали режим многопользовательского доступа. Если операционная система поддерживает многопользовательский режим, вполне реальна ситуация, когда два или более пользователя одновременно пытаются работать с одним и тем же файлом. Если все пользователи собираются только читать файл, ничего страшного не произойдет. Но если хотя бы один из них будет изменять файл, для корректной работы этих пользователей требуется взаимная синхронизация их действий по отношению к файлу
В системах управления файлами обычно применялся следующий подход. В операции открытия файла (первой и обязательной операции, с которой должен начинаться сеанс работы с файлом) среди прочих параметров указывался режим работы (чтение или изменение). Если к моменту выполнения этой операции некоторым пользовательским процессом PR1 файл был уже открыт другим процессом PR2 в режиме изменения, то в зависимости от особенностей системы процессу PR1 либо сообщалось о невозможности открытия файла, либо он блокировался до тех пор, пока в процессе PR2 не выполнялась операция закрытия файла.
При подобном способе организации одновременная работа нескольких пользователей, связанная с модификацией данных в файле, либо вообще не реализовывалась, либо была очень замедлена.
Эти недостатки послужили тем толчком, который заставил разработчиков информационных систем предложить новый подход к управлению информацией. Этот подход был реализован в рамках новых программных систем, названных впоследствии Системами Управления Базами Данных (СУБД), а сами хранилища информации, которые работали под управлением данных систем, назывались базами или банками данных (БД и БнД).
3 вопрос. Распределённые базы данных (РБД) - совокупность логически взаимосвязанных баз данных, распределённых в компьютерной сети.
Основные принципы
РБД состоит из набора узлов, связанных коммуникационной сетью, в которой:
каждый узел - это полноценная СУБД сама по себе;
узлы взаимодействуют между собой таким образом, что пользователь любого из них может получить доступ к любым данным в сети так, как будто они находятся на его собственном узле.
Каждый узел сам по себе является системой базы данных. Любой пользователь может выполнить операции над данными на своём локальном узле точно так же, как если бы этот узел вовсе не входил в распределённую систему. Распределённую систему баз данных можно рассматривать как партнёрство между отдельными локальными СУБД на отдельных локальных узлах.
Фундаментальный принцип создания распределённых баз данных («правило 0»): Для пользователя распределённая система должна выглядеть так же, как нераспределённая система.
Фундаментальный принцип имеет следствием определённые дополнительные правила или цели. Таких целей всего двенадцать:
Локальная независимость. Узлы в распределённой системе должны быть независимы, или автономны. Локальная независимость означает, что все операции на узле контролируются этим узлом.
Отсутствие опоры на центральный узел. Локальная независимость предполагает, что все узлы в распределённой системе должны рассматриваться как равные. Поэтому не должно быть никаких обращений к «центральному» или «главному» узлу с целью получения некоторого централизованного сервиса.
Непрерывное функционирование. Распределённые системы должны предоставлять более высокую степень надёжности и доступности.
Независимость от расположения. Пользователи не должны знать, где именно данные хранятся физически и должны поступать так, как если бы все данные хранились на их собственном локальном узле.
Независимость от фрагментации. Система поддерживает независимость от фрагментации, если данная переменная-отношение может быть разделена на части или фрагменты при организации её физического хранения. В этом случае данные могут храниться в том месте, где они чаще всего используются, что позволяет достичь локализации большинства операций и уменьшения сетевого трафика.
Независимость от репликации. Система поддерживает репликацию данных, если данная хранимая переменная-отношение - или в общем случае данный фрагмент данной хранимой переменной-отношения - может быть представлена несколькими отдельными копиями или репликами, которые хранятся на нескольких отдельных узлах.
Обработка распределённых запросов. Суть в том, что для запроса может потребоваться обращение к нескольким узлам. В такой системе может быть много возможных способов пересылки данных, позволяющих выполнить рассматриваемый запрос.
Управление распределёнными транзакциями. Существует 2 главных аспекта управления транзакциями: управление восстановлением и управление параллельностью обработки. Что касается управления восстановлением, то чтобы обеспечить атомарность транзакции в распределённой среде, система должна гарантировать, что все множество относящихся к данной транзакции агентов (агент - процесс, который выполняется для данной транзакции на отдельном узле) или зафиксировало свои результаты, или выполнило откат. Что касается управления параллельностью, то оно в большинстве распределённых систем базируется на механизме блокирования, точно так, как и в нераспределённых системах.
Аппаратная независимость. Желательно иметь возможность запускать одну и ту же СУБД на различных аппаратных платформах и, более того, добиться, чтобы различные машины участвовали в работе распределённой системы как равноправные партнёры.
Независимость от операционной системы. Возможность функционирования СУБД под различными операционными системами.
Независимость от сети. Возможность поддерживать много принципиально различных узлов, отличающихся оборудованием и операционными системами, а также ряд типов различных коммуникационных сетей.
Независимость от типа СУБД. Необходимо, чтобы экземпляры СУБД на различных узлах все вместе поддерживали один и тот же интерфейс, и совсем необязательно, чтобы это были копии одной и той же версии СУБД.
Типы распределённых баз данных
Распределённые базы данных
Мультибазы данных с глобальной схемой. Система мультибаз данных - это распределённая система, которая служит внешним интерфейсом для доступа ко множеству локальных СУБД или структурируется, как глобальный уровень над локальными СУБД.
Федеративные базы данных. В отличие от мультибаз не располагают глобальной схемой, к которой обращаются все приложения. Вместо этого поддерживается локальная схема импорта-экспорта данных. На каждом узле поддерживается частичная глобальная схема, описывающая информацию тех удалённых источников, данные с которых необходимы для функционирования.
Мультибазы с общим языком доступа - распределённые среды управления с технологией «клиент-сервер»
4 вопрос. Проектирование баз данных - это сложный процесс решения целого ряда задач, которые связаны с созданием баз данных.
Основные задачи проектирования СУБД
Обеспечение возможности для корректного получения данных по всем запросам;
Обеспечение хранения в базе данных всей необходимой информации; Сократить избыточность и дублирование данных;
Обеспечить целостность всех данных в БД и исключить их потери;
Главные этапы в проектировании БД;
Инфологическое (Концептуальное) проектирование – это грамотное построение формализованной модели всей предметной области. Подобная модель создается с использованием стандартных языковых средств, чаще всего графических, например ER-диаграмм. Такая модель создается без какой-либо ориентации на конкретную СУБД.
Главные элементы данной модели:
Описание всех объектов предметной области и всех связей между ними;
Описание всех информационных потребностей пользователей, например, описание самых основных запросов к базе данных и т.д.;
Составление полного описания документооборота. Описание всех документов, которые используются в качестве исходных данных для базы данных;
Описание основных алгоритмических зависимостей, возникающих между данными;
Подробное описание ограничений целостности. Сюда входят требования ко всем допустимым значениям данных и к их связям;
Виды проектирования:
Логическое или даталогическое проектирование – заключается в отображении инфологической модели на какую-либо модель данных, которая используется в конкретной СУБД. Для реляционных СУБД характерна даталогическая модель, а именно: набор всех таблиц с указанием основных или ключевых полей и всех связей между этими таблицами. Даталогическое проектирование любой инфологической модели, которая построена в виде ER-диаграмм, представляет построение таблиц по каким-либо определённым формализованным правилам.
Физическое проектирование СУБД – это процесс реализации какой-либо даталогической модели, используя средства конкретной СУБД, а также выбор различных решений, которые связаны с физической средой хранения всех данных.
5 вопрос. Реляционная модель данных (РМД) - логическая модель данных, прикладная теория построения баз данных, которая является приложением к задачам обработки данных таких разделов математики как теории множеств и логика первого порядка.
На реляционной модели данных строятся реляционные базы данных.
Реляционная модель данных включает следующие компоненты:
Структурный аспект (составляющая) - данные в базе данных представляют собой набор отношений.
Аспект (составляющая) целостности - отношения (таблицы) отвечают определенным условиям целостности. РМД поддерживает декларативные ограничения целостности уровня домена (типа данных), уровня отношения и уровня базы данных.
Аспект (составляющая) обработки (манипулирования) - РМД поддерживает операторы манипулирования отношениями (реляционная алгебра, реляционное исчисление).
Кроме того, в состав реляционной модели данных включают теорию нормализации.
Термин «реляционный» означает, что теория основана на математическом понятии отношение (relation). В качестве неформального синонима термину «отношение» часто встречается слово таблица. Необходимо помнить, что «таблица» есть понятие нестрогое и неформальное и часто означает не «отношение» как абстрактное понятие, а визуальное представление отношения на бумаге или экране. Некорректное и нестрогое использование термина «таблица» вместо термина «отношение» нередко приводит к недопониманию. Наиболее частая ошибка состоит в рассуждениях о том, что РМД имеет дело с «плоскими», или «двумерными» таблицами, тогда как таковыми могут быть только визуальные представления таблиц. Отношения же являются абстракциями, и не могут быть ни «плоскими», ни «неплоскими».
Для лучшего понимания РМД следует отметить три важных обстоятельства:
модель является логической, то есть отношения являются логическими (абстрактными), а не физическими (хранимыми) структурами;
для реляционных баз данных верен информационный принцип: всё информационное наполнение базы данных представлено одним и только одним способом, а именно - явным заданием значений атрибутов в кортежах отношений; в частности, нет никаких указателей (адресов), связывающих одно значение с другим;
наличие реляционной алгебры позволяет реализовать декларативное программирование и декларативное описание ограничений целостности, в дополнение к навигационному (процедурному) программированию и процедурной проверке условий.
Принципы реляционной модели были сформулированы в 1969-1970 годах Э. Ф. Коддом (E. F. Codd). Идеи Кодда были впервые публично изложены в статье «A Relational Model of Data for Large Shared Data Banks», ставшей классической.
Строгое изложение теории реляционных баз данных (реляционной модели данных) в современном понимании можно найти в книге К. Дж. Дейта. «C. J. Date. An Introduction to Database Systems» («Дейт, К. Дж. Введение в системы баз данных»).
Наиболее известными альтернативами реляционной модели являются иерархическая модель, и сетевая модель. Некоторые системы, использующие эти старые архитектуры, используются до сих пор. Кроме того, можно упомянуть об объектно-ориентированной модели, на которой строятся так называемые объектно-ориентированные СУБД, хотя однозначного и общепринятого определения такой модели нет.
6 вопрос. Оператор выбораSELECT.
Команда select (выбор) используется для извлечения данных из таблицы. Эту команду можно использовать для выбора данных как по строкам, так по столбцам из одной или нескольких таблиц.
Запрос это обращение к базе данных с целью получения результирующих данных. Этот процесс также называется нахождением данных. Все SQL запросы выражаются через оператор выбора (select). Этот оператор можно использовать как для выбора записей (строк) из одной или нескольких таблиц, так и для построения проекций (projections), т.е. выбора данных по некоторому подмножеству атрибутов (столбцов) из одной или нескольких таблиц.
SELECT- ключевое слово, которое сообщает СУБД, что эта команда - запрос. Все запросы начинаются этим словом с доследующим пробелом, За ним может следовать способ выборки - с удалением дубликатов (DISTINCT) или без удаления (ALL, подразумевается по умолчанию). Затем следует список перечисленных через запятую столбцов, которые выбираются запросом из таблиц, или символ "*" (звездочка) для выбора всей строки. Любые столбцы, не перечисленные здесь, не будут включены в результирующее отношение, соответствующее выполнению команды. Это, конечно, не значит, что они будут удалены или их информация будет стерта из таблиц, потому что запрос не воздействует на информацию в, таблицах - он только показывает данные.
7 вопрос . Математические функции
В арсенале каждой СУБД обязательно имеется набор встроенных функций для обработки стандартных типов данных. В MySQLдля встроенных функций между именем и открывающей скобкой не должно быть пробелов, иначе будет сообщение об отсутствии подобной функции в БД. В некоторых СУБД, какOracle, если функция не имеет аргументов, то скобки можно опустить.
abs(x) - абсолютное значение;
ceil(x) - наименьшее целое, которое не меньше аргумента;
exp(x) - экспонента;
floor(x) - наибольшее целое, которое не больше аргумента;
ln(x) - натуральный логарифм;
power(x, y) - возводит x в степень y;
round(x [,y]) - округление x до y разрядов справа от десятичной точки. По умолчанию y равно 0;
sign(x) - возвращает -1 для отрицательных значений x и 1 для положительных;
sqrt(x) - квадратный корень;
trunc(x [,y]) - усекает x до у десятичных разрядов. Если у равно 0 (значение по умолчанию), то х усекается до целого числа. Если у меньше 0, от отбрасываются цифры слева от десятичной точки.
Тригонометрические функции работают с радианами:
acos(x) - арккосинус;
asin(x) - арксинус;
atan(x) - арктангенс;
cos(x) - косинус;
sin(x) - синус;
tan(x) - тангенс.
ceil(fraction) – округляет дробное число до ближайшего большего целого числа.
floor(fraction) – округляет дробное число до ближайшего меньшего целого числа.
number_format("number", "decimals", "decimal point", "thousands_sep") – возвращает форматированную версию указанного числа ("number").
pow(number,exponent) – возвращает результат возведения заданного числаnumberв степеньexponent.
rand(min,max) – порождает случайное число из заданного диапазона.
round(fraction) – округляет дробное число до ближайшего целого числа.
sqrt(number) – возвращает квадратный корень заданного числаnumber.
8 вопрос. Преимущества и недостаткиMySQL.
Недостатки MySQL
MySQLдействительно очень быстрый сервер, но для достижения этого разработчикам пришлось пожертвовать некоторыми требованиями к реляционным СУБД.
Нет поддержки внешних (foreign) ключей.
Преимущества MySQL:
наилучшая скорость обработки данных на объеме до 500000 записей;
бесплатные открытые лицензии;
простота использования;
поддержка большинством хостинговых компаний;
возможность использования на различных платформах (Unix,Windows, др.);
9 вопрос. Декомпозиция плоской таблицы.
Смысл декомпозиции заключается в следующем. Плоская таблица (большая таблица, в которой собраны воедино все данные для решения задачи с высокой степенью повторяемости данных) преобразуется в совокупность взаимосвязанных отдельных таблиц.
определяется количество сущностей (объектов), описываемых плоской таблицей.
поля плоской таблицы разделяются между таблицами (объектными отношениями), соответствующими объектам (сущностям);
определяется поле (набор полей), используемых в качестве ключа для связи между отдельными таблицами. Иногда для этой цели могут использоваться специальные таблицы (связные отношения).
ни одно из полей во всех отношениях не должно содержать групп значений. Н
если в некоторых полях данные повторяются слишком часто, можно создать дополнительные таблицы (отношения), играющие роль справочников.
Вышеизложенная последовательность действий – это шаги нормализации – метода организации реляционной базы данных с целью сокращения избыточности.
10 Вопрос .Команды создания баз данных, таблиц и индексов
create database if not exists – Создание базы данных
create table if not exists tovar (ID int unsigned not null auto_increment primary key,
tovar_name char (100) not null ,
tovar_mark char (100) not null,
Cena int not null ,
data_buy date default curdate() ,
family char (100) not null); создание таблицы
создание индекса в столбце au_idтаблицыauthors
create index au_id_ind
Историю развития баз данных можно разделить на четыре периода.
1. Период становления – начало 60-х - начало 70-х гг . В этот период появляется сам термин «база данных» и создается несколько первоначальных систем. Основой появления баз данных явилось предложение конца 50-х годов использовать файлы для хранения исходных данных. Основное требование к таким файловым системам – быть совместно используемым хранилищем данных. В последующем стало очевидным, что совместно используемые данные, должны обладать специфическими свойствами, в частности: независимость данных, отсутствие дублирования и противоречивости, контроль прав доступа к данным, эффективная техника доступа к данным, а также многие другие.
Осознание этих фактов, а также появление больших компьютеров с магнитными дисками в качестве носителей данных привело к появлению в середине 60-х гг. первых систем управления базами данных, из которых наиболее развитой оказалась система IMS фирмы IMB, которая поддерживала иерархическую структуру данных. Бахман в 1963 г. разработал первую промышленную систему баз данных IDS. СистемаIDSподдерживала сетевую организацию данных на магнитных носителях.
Ассоциация CODASYL, являющаяся органом, разработавшим язык программирования Кобол, в 1967 г. организовала рабочую группу по базам данных. Эта группа обобщила языковые спецификации систем баз данных и в 1969 и 1971 гг. издала соответствующие отчеты, которые по наименованию рабочей группы (DataBaseTaskGroup) получили названиеDBTG69,DBTG71. Основой избранного Рабочей группой подхода послужила сетевая структура данных и способы навигации по ней, разработанные в системе IDS, однако сетевая модель данных в отчетах DBTG получила существенное развитие и обоснование.
Типичным представителем системы, поддерживающей предложения DBTGCODASYLявилась Integrated Database Management System (IDMS) компании Cullinet Software, Inc., предназначенная для использования на машинах основного класса фирмы IBM под управлением большинства операционных систем.
В этот же период четко выкристаллизовались два подхода относительно проблемы замкнутости систем баз данных. Системы замкнутого типа характеризуются тем, что они не содержат в своем составе традиционных языков программирования, а имеют непроцедурные языки запросов. Основной целью в данном случае является создание системы, с применением которой мог бы справиться не специалист по программированию К таким системам относились TDMS иUL/1.
Системы с включаемыми языками помимо собственно языков манипулирования базами данных предоставляют также языковые и инструментальные средства разработки приложений, с использованием существующих языков программирования. Этот принцип, в частности, исповедовался DBTG.
В конце данного периода появился термин информационно-управляющая система (MIS). В то время подMISпонималась система баз данных, ориентированная на поиск данных и обеспечивающая возможность работы с удаленного терминала.
Период развития – 70-е годы . Концепция баз данных широко распространяется благодаря повышению характеристик аппаратного обеспечения компьютеров. Идет успешное внедрение систем, поддерживающих иерархическую и сетевую структуры данных.
Все этот период продолжалась работа DBTG CODASYL. Была специфицирована система языков для баз данных CODASYL, которая включила следующие группы языковых спецификаций:
Язык описания данных ЯОД (Data Definition Language - DDL). Представляет собой описание концептуальной схемы в терминах сетевой структуры данных.
Средства базы данных языка Кобол . Представляет собой средства обеспечения интерфейса языка Кобол с базой данных, описанной в DDL. В Кобол включены средства языка манипулирования данными.
Средства базы данных языка Фортран . Представляет собой средства обеспечения интерфейса языка Фортран с базой данных, описанной в DDL. В Кобол включены средства языка манипулирования данными.
Средства конечного пользователя . Определяет интерфейс пользователя случае, когда такой пользователь управляет базой данных, описанной в DDL.
Язык описания хранения данных ЯОХД (Data Stored Definition Language - DSDL). Представляет собой язык, который отображает концептуальную схему, описанную в DDL, во внутреннюю схему.
В 1975 г. появился отчет рабочей группы ANSI/X3/SPARCАмериканского Национального Института Стандартов, который явился значительной вехой в развитии проблематики баз данных. Перед группой была поставлена задача исследовать, в какой мере целесообразно ставить вопрос о стандартизации баз данных и СУБД и что именно может быть подвержено стандартизации. Группа пришла к выводу, что если и ставить вопрос о стандартизации, то только относительно интерфейсов, которые могут существовать между различными компонентами СУБД, сами программные компоненты ни в коем случае подвергаться стандартизации не могут. В связи с этим они направили свои последующие усилия на выявление таких интерфейсов и, в конце концов, пришли к формулировке трехуровневой архитектуре баз данных, которая стала классической и не потеряла свою актуальность до сих пор.
Однако этот период в большей мере характеризуется появлением реляционной модели данных, предложенной в 1970 г. сотрудником института фирмы ИБМ в Сан-Хосе Э.Ф. Коддом, всесторонними исследованиями теоретических и прикладных вопросов этой модели, разработкой экспериментальных реляционных СУБД. Теоретические исследования привели, в конце концов, к созданию формальной теории баз данных, которая до этого носила описательный характер. На протяжении многих лет многие ведущие формы проводили экспериментальные исследования по созданию прототипов реляционных СУБД, повышению их эффективности и функциональности. В конце 70-х гг. появляются первые промышленные реляционные СУБД.
Период зрелости – 80-е годы . Реляционная модель получила полное теоретическое обоснование. Разработаны крупные реляционные СУБД Oracle, Informix, и другие. Промышленные реляционные системы получают широкое распространение во всех сферах человеческой деятельности. Реляционные системы практически вытеснили с мирового рынка ранние СУБД иерархического и сетевого типа.
Дальнейшее развитие реляционных СУБД шло в следующих направлениях:
Удобство применения . Появление персональных компьютеров сделал принципиальным вопрос удобства использования программ, что также относилось и к СУБД. На протяжении всего этого периода интенсивно развивается внешний интерфейс взаимодействия пользователей с базами данных.
Многоплановость . Изначально базы данных разрабатывались для хранения и обработки символьной информации и традиционно использовались в таких сферах, как обработка экономической информации, статистика, банковское дело, системы резервирования, информационные системы различного направления. Появление спроса к базам данных в нетрадиционных сферах их применения, системы автоматизации проектирования, издательское дело и другие, потребовали хранения в базах данных и обработки изображений, звуков, полнотекстовой информации.
Этот период также характеризуется теоретическими и экспериментальными исследованиями в области баз знаний. Разрабатываются многочисленные экспертные системы, использующие базы знаний. В подавляющем большинстве случаев базы знаний разрабатываются на основе реляционных СУБД.
Постреляционный период – с начало 90-х гг . В этот период начались проводиться интенсивные исследования по дедуктивным и объектно-ориентированным базам данных, а также разработка исследовательских прототипов таких систем.
Особое место в развитии проблематики объектно-ориентированных СУБД занимает деятельность группы по управлению объектными базами данных ODMG(ObjectDataManagementGroup), - неприбыльным консорциумом производителей объектных баз данных и других организаций, заинтересованных в выработке стандартов по хранению объектов в базах данных.ODMGбыла создана в 1991 г. В 1993 г. группа выпустила свой первый стандарт –ODMG-93. В 1995 г. был опубликован усовершенствованный вариант этого стандарта.
В связи с развитием Интернет-технологий прикладываются большие усилия по внедрению баз данных в Интернет. Возникают различные подходы по включению СУБД с их базами данных во всемирную паутину, начиная от простейших «публикаций» баз данных в Интернет и заканчивая разработкой web-серверов баз данных, которые в состоянии предоставлять весь спектр услуг пользователям Интернета по использованию баз данных на сервере.
Наконец, интенсивно развиваются исследования и разработки по представлению и манипулированию структурами данных в Интернет.
Базы данных и знаний 9
Важным этапом развития ИС явился переход к использованию централизованных систем управления файлами. Широкое распространение получили индексированные файлы . Файл является простым набором записей (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). Однако в отличие от предыдущих моделей действительная структура этих моделей не совсем ясна. Попытки реализации подобных моделей представляют собой СУБД третьего поколения.
