БАЗЫ ДАННЫХ
База данных – поименованная совокупность структурированных данных, относящихся к определенной предметной области, находящаяся в виде файла(ов) на винчестере или различного рода носителях.
Другое определение определяет, что база данных определяется как совокупность взаимосвязанных данных, характеризующихся возможностью использования для большого количества приложений, возможностью быстрого получения и модификации необходимой информации, минимальной избыточностью информации, независимостью от прикладных программ, общим управляемым способом поиска.
Существует ряд других определений базы данных, акцентирующих внимание на различных их особенностях, однако, общим в них является утверждение, что база данных в широком смысле представляет собой совокупность сведений о конкретных объектах реального мира в какой-либо предметной области. Практически для любого пользователя при работе с базой данных важнейшими факторами являются возможность упорядочения данных по актуальным для него признакам и быстрое извлечение выборок данных в соответствии с произвольным сочетанием признаков.
Несмотря на обилие специализированных баз данных, используемых различными приложениями, существуют общие требования к их организации:
· возможность однократного ввода данных и их многократного использования, причем различные пользователи могут использовать одни и те же данные по-разному;
· простота и легкость использования данных;
· гибкость доступа к данным, позволяющая обращаться к данным и извлекать их с помощью различных методов доступа;
· возможность выполнения незапланированных (нестандартных, нештатных) запросов практически по любым критериям отбора;
· возможность внесения требуемых структурных изменений без нарушения существующих способов использования данных (т.е. адаптация базы данных к изменяющимся условиям эксплуатации);
· минимальная избыточность данных (т.е. минимальное дублирование данных в различных таблицах базы данных);
· достоверность данных при любых обновлениях базы данных;
· постоянная готовность базы данных к обслуживанию пользователей;
· обеспечение разграничения прав доступа к различным разделам базы данных с учетом проводимой политики безопасности;
· защита данных от несанкционированного изменения;
· обеспечение высокой производительности при выполнении запросов;
· минимизация стоимости хранения данных и затрат на их выборку.
Для описания данных в конкретных предметных областях используется значительное число моделей различного уровня обобщения (с различным уровнем абстракции). С общих позиций принято выделять три схемы описания данных: концептуальную, внешнюю и внутреннюю.
Концептуальная схема дает описание логической структуры всей базы данных. При этом описание структуры осуществляется на смысловом уровне, без учета особенностей представления данных в компьютере. На этом уровне определяются объекты, характеризующие каждый объект свойства, взаимные связи между объектами. В рамках терминологии баз данных объекты представляются в виде записей, свойства объектов определяются с помощью атрибутов, а взаимодействие объектов описывается с помощью связей. Именно эти сущности: записи, атрибуты и связи являются тремя основными формами представления данных в базах данных.
Атрибут представляет собой элементарную характеристику данных и может быть представлен числом, символьной строкой, датой и т.п. Запись образуется из совокупности значений аргументов, соответствующих одному объекту. Для однозначной идентификации каждой записи вводится понятие ключа записи, который формируется одним или несколькими атрибутами, образующими уникальное имя записи. Именно наличие уникального имени позволяет при работе с базой данных найти необходимую запись.
Обычно степень детализации описания данных в концептуальной схеме задается определением типов атрибутов и ограничениями на допустимые значения атрибутов.
Внешняя схема представляет собой отображение концептуальной схемы с позиции конкретного пользователя (группы пользователей), имеющего определенные права доступа к части данных. С учетом проведения в общем случае политики разграничения доступа к данным для различных групп (категорий) пользователей применительно к конкретной базе данных можно говорить о присущей ей совокупности отличающихся друг от друга внешних схем. В случае, когда все пользователи имеют одинаковые права доступа к базе данных, концептуальная и внешняя схемы совпадают.
Внутренняя схема представляет собой описание способов размещения данных во внешней памяти компьютера. Именно реализованные способы размещения данных в значительной степени влияют на производительность при работе с базой данных.
В соответствии с рассмотренными схемами описания данных проектирование баз данных разделяется на два крупных этапа:
· логическое проектирование, целью которого является наилучшее отображение объектов конкретной предметной области в абстрактные объекты модели данных с учетом семантики этой области (этап соответствует концептуальной схеме);
· физическое проектирование, ориентированное на реализацию конкретных решений по рациональному расположению данных в памяти компьютера, организацию необходимых индексных массивов (ускоряющих поиск записей) и др. При этом уже определен тип конкретной системы управления базой данных, что, во многом, влияет на процесс проектирования.
Взаимосвязи между различными объектами могут быть классифицированы следующим образом:
· “один к одному”, когда одна запись может быть связана только с одной записью;
· ”один ко многим”, когда одна запись взаимосвязана со многими другими записями;
· ”многие ко многим”, когда одна и та же запись может входить в отношения со многими другими записями в различных вариантах.
Характер применения того или иного вида взаимосвязей определяет три основных модели баз данных: иерархическую, сетевую и реляционную. Первые две модели базируются на представлении информации об объектах посредством графов, последняя модель использует таблицы.
Для иллюстрации особенностей логической структуры каждой из моделей баз данных рассмотрим конкретный пример. Пусть необходимо разработать логическую структуру базы данных для хранения сведений о трех поставщиках: П1, П2, П3, которые могут поставлять товары Т1, Т2, Т3 в следующих сочетаниях: поставщик П1 – все три вида товаров, поставщик П2 – товары Т1 и Т3, поставщик П3 – товары Т2 и Т3.
Рассмотрим логическую модель базы данных, построенную на основе иерархического подхода. Иерархическая модель организует данные в виде древовидной структуры, в которой располагаются (классифицируются) по уровням соподчиненности (иерархии) объектов. Такая модель реализует отношения “один ко многим”. Применительно к иерархической модели основными понятиями структуры являются: уровень, элемент (узел), связь. Узел представляет собой совокупность атрибутов данных, описывающих некоторый объект. На схеме узлы отображаются вершинами графа. В иерархической модели имеется один корневой узел (корень дерева). Он находится на самом верху модели. В иерархической модели должно соблюдаться правило: каждый порожденный узел не может иметь больше одного порождающего узла; в структуре может быть только один непорожденный узел (корень). Очевидно, что в иерархической модели узел отображает собою запись. В иерархической модели важную роль играют уровни, отражающие степень подчиненности того или иного узла в иерархии. Связи между исходным узлом и порождающими узлами описывают отношение “один ко многим”.
Для рассматриваемого примера (рис.4.1) иерархическая модель имеет три уровня. На верхнем уровне отображается информация в целом по поставщикам (П), на втором уровне – о конкретных поставщиках П1, П2, П3, на третьем уровне – о товарах, которые могут поставлять конкретные поставщики. При поиске конкретных товаров на основе иерархической модели необходимо двигаться от корня к нижнему уровню, проходя через узлы промежуточных уровней, используя при этом однотипные процедуры доступа к данным, что значительно упрощает доступ. Достоинством иерархической структуры также является возможность описания структуры как на логическом, так и на физическом уровнях. Однако иерархическая модель имеет ряд недостатков: жесткая фиксация взаимосвязей между элементами данных, что обуславливает необходимость
Рис.4.1. Иерархическая модель базы данных
внесения изменений в структуру модели при любых изменениях характера взаимосвязей между элементами. Модернизация модели сопряжена со значительными сложностями, поскольку удаление узла на любом из уровней (за исключением нижнего уровня) блокирует возможность доступа к порожденным им узлам. Доступ к порожденным узлам возможен только через исходный узел, поэтому существует только один путь доступа к каждому узлу.
Сетевая модель данных реализует возможность связи любого элемента структуры с любым другим ее элементом. Для рассматриваемого примера модель базы данных примет вид (рис. 4.2). В ней отображены независимые (основные) типы данных П1, П2, П3 - информация о поставщиках и зависимые – информация о товарах Т1, Т2, Т3. Следует отметить, что должно выполняться общее правило: связь должна объединять основную и зависимую записи.
Рис. 4.2. Сетевая модель базы данных
В целом в сетевой структуре отношения между элементами описаны взаимосвязями “один ко многим” и ”многие ко многим”. При реализации в моделях только связей типа “один ко многим” их называют простыми сетевыми структурами. При наличии хотя бы одной связи ”многие ко многим” модели называют сложными сетевыми структурами. Необходимость разделения сетевых моделей на два типа объясняется тем, что управление структурами, включающими в себя связи типа ”многие ко многим”, требует применение значительно более сложных методов.
Применительно к сетевой модели основными понятийными структурами являются область (часть модели), записи (элемент области), поле и набор. По существу набор представляет собой экземпляр поименованной двухуровневой (двухуровневое дерево) совокупности записей. Каждый тип набора представляет собой отношение между двумя или несколькими типами записей. Каждый набор должен содержать один экземпляр записей, имеющий тип записи–владельца (в примере на рисунке это независимые или основные типы), и может содержать любое количество экземпляров каждого типа записей–членов набора (зависимы типы). Каждый тип набора идентифицируется индивидуальным именем, что позволяет использовать одну и ту же пару типов объектов в различных взаимосвязях и строить, таким образом, сложные структуры данных. Именно в возможности участия каждой записи в любом числе наборов проявляется существенное отличие между сетевой и иерархической моделями данных.
Потенциальная сложность сетевой модели оборачивается ее недостатком, поскольку для обслуживающего организованную на основе сетевой модели базу данных программиста требуется затрачивать значительно больше усилий для реализации процедур доступа к нужным данным. Кроме того, значительные трудности возникают при реорганизации структуры базы данных из-за обилия взаимосвязей между объектами.
На практике наибольшее распространение при разработке баз данных получила реляционная модель данных (relation – отношение), которая позволяет представить взаимосвязи между элементами данных в виде двумерных таблиц, называемых отношениями. Для отношений характерны следующие свойства:
· каждый элемент таблицы представляет собой один элемент данных;
· исключается возможность одинаковых строк в таблицах;
· все столбцы в таблице однородны, т.е. в пределах одного столбца все элементы данных имеют одинаковый тип (числовой, символьный, дата и др.);
· каждый столбец имеет уникальное имя;
· порядок следования строк и столбцов в таблице может быть любым.
В реляционной модели каждая строка таблицы представляет собой отдельную запись, а заголовки столбцов являются названиями полей (атрибутов) в записях. Для идентификации каждой записи таблицы используется уникальное имя (первичный ключ), которое образуется одним или несколькими атрибутами. Характерной особенностью ключа является исключение возможности дублирования его значений в нескольких записях (т.е. любое конкретное значение ключа для любой записи таблицы уникально). Если ключ состоит из значений нескольких атрибутов, то его называют составным, а если из одного атрибута – то простым. Для того чтобы связать между собой две таблицы реляционной базы данных необходимо ключ первой таблицы ввести в состав ключа второй таблицы. Если при этом возникают значительные затруднения, то можно в первую таблицу ввести ключ (атрибут) из второй таблицы, который будет выполнять роль внешнего ключа. При этом тип данных первичного и внешнего ключей должны совпадать (для первой таблицы).
Для рассматриваемого примера реляционная модель базы данных примет вид (рис. 4.3), отображающий три таблицы (отношения): R1, R2 и R3, состоящие соответственно из записей о поставщиках, товарах и поставках товаров поставщиками.
Таблица R1 отображает информацию о поставщиках, включающую в себя уникальный код поставщика, фамилию (она может повторяться как и значения последующих полей), используемый для поставки транспорт, город.
Таблица R2 описывает виды товаров, каждый из которых характеризуется уникальным кодом, названием, массой, видом упаковки.
В таблице R3 отражена поставка товаров. Эта таблица связывает между собой две другие таблицы. Она описывает поставку товара Тi поставщиком Пj в конкретном количестве. Таким образом, каждая поставка определяется кодом поставщика, кодом товара и количеством товара.
В целом реляционная база данных с логической точки зрения может быть представлена множеством двумерных таблиц различного предметного наполнения. Достоинствами реляционной модели базы данных являются:
· простота логической модели (представлена в виде привычных таблиц);
· независимость данных;
· возможность построения простого языка манипулирования данными;
· гибкость системы защиты (для каждого отношения может быть установлена правомерность доступа).
R 1 (поставщики)
Код Поставщика | Фамилия | Способ доставки | Город |
П1 | Иванов | автомобиль | Тула |
П2 | Петров | железная дорога | Рязань |
П3 | Махлис | самолет | Калуга |
R 2 (товары)
Код товара | Название | Масса | Штук в упаковке |
Т1 | шампунь | 0,4 | |
Т2 | мыло | 0,2 | |
Т3 | крем | 0,1 |
R 3 (поставка товаров)
Код поставщика | Код товара | Количество |
П1 | Т1 | |
П1 | Т2 | |
П1 | Т3 | |
П2 | Т1 | |
П2 | Т3 | |
П3 | Т2 | |
П3 | Т3 | |
Рис. 4.3. Реляционная база данных поставщиков и товаров
При работе с реляционными моделями используется как математическая терминология, так и терминология, изначально принятая в области обработки данных. Близкими по сути являются термины: отношение и таблица; кортеж, запись и строка; атрибут, поле и столбец.
Во многом широкое распространение и перспективы использования реляционной модели баз данных объясняется наличием соответствующего математического аппарата, позволяющего построить структуру с рациональной группировкой атрибутов в отношениях, с минимальным дублированием данных и с возможно простыми процедурами обработки данных.
Улучшению свойств отношений между объектами служат известные процедуры нормализации. Нормализация отношений – формальный аппарат ограничений на формирование отношений (таблиц), который позволяет устранить дублирование, обеспечивает непротиворечивость хранимых в базе данных, уменьшает трудозатраты на ведение базы данных.
Об отношении говорят, что оно имеет нормальную форму или нормализовано, если оно удовлетворяет определенным ограничивающим условиям.
В теории реляционных баз данных принято выделять пять нормальных форм (первые три нормальных формы отношений выделены Е. Коддом и им же предложен алгоритм, позволяющий преобразовать любое отношение к третьей нормальной форме).
Так, отношение называется нормализованным или приведенным к первой нормальной форме, если все его атрибуты простые (их невозможно представить в виде совокупности отдельных частей). Каждой нормальной форме соответствует свой конкретный набор ограничений, и отношение находится в некоторой нормальной форме, если оно удовлетворяет свойственному ей набору ограничений. Следует отметить, что каждая последующая нормальная форма в определенном смысле улучшает свойства предыдущей формы, при переходе к следующей нормальной форме свойства предыдущих нормальных форм сохраняются. На практике во многих случаях третья нормальная форма отношений является вполне достаточной и при ее достижении процесс нормализации отношений заканчивают.
Естественно, что качественный результат при разработке реляционных баз данных при большом числе атрибутов и сложных взаимосвязях данных может быть получен с привлечением к их проектированию профессионалов, знакомых с соответствующим математическим аппаратом.
В целом реляционная модель баз данных имеет дело с тремя аспектами данных: со структурой данных, с целостностью данных и с манипулированием данными. Под структурой понимается логическая организация данных в базе данных, под целостностью данных – безошибочность и точность хранящейся в базе данных информации, под манипулированием данными – действия, совершаемые над данными в базе данных. Эти три аспекта отражают основные процедуры процесса накопления данных (хранение, актуализация и извлечение).
Переход после этапа логического проектирования базы данных к этапу создания физической модели базы данных, реализуемой и используемой на компьютере, осуществляется с помощью совокупности программ, позволяющих создать во внешней памяти компьютера базу данных и обеспечить возможность работы с данными. Эти программы называют системами управления базами данных (СУБД). Они служат для поддержания базы данных в актуальном состоянии и обеспечивают эффективный доступ пользователей к данным с учетом принятой политики разграничения прав доступа.
Подавляющая часть имеющихся на рынке программного обеспечения СУБД относится к системам общего назначения и не ориентированны на какие-либо предметные области. Применение СУБД в качестве инструментального средства для создания автоматизированных информационных систем позволяет существенно сократить сроки разработки и уменьшить финансовые затраты.
Современные СУБД общего назначения представляют собой сложные программные комплексы, обеспечивающие выполнение всех необходимых функций, связанных с созданием и эксплуатацией базы данных информационной системы. Следует отметить, что конкретные СУБД поддерживают конкретные модели баз данных (реляционную, сетевую и др.).
В течение более десятка лет общепризнанным лидером в области построения промышленных баз данных является корпорация Oracle. На рынке баз данных в целом (включая реляционные, иерархические и сетевые базы данных) Oracle занимает первое место с результатом 33,8% рынка. Ближайший конкурент - IBM - со всеми своими многочисленными СУБД - DB2, IMS и др. - имеет 30,1 % рынка. Рынок реляционных баз данных распределен следующим образом: Oracle - 42,1 %, IBM - 29,2% и др. На рынке реляционных баз данных на платформе UNIX Oracle имеет 66,2%, IBM - 14,4%.
Флагманский продукт корпорации - СУБД Oracle - удовлетворяет всем требованиям, предъявляемым при построении промышленных информационных систем. Ядром СУБД является сервер базы данных, который поставляется в одном из четырех вариантов в зависимости от масштаба информационной системы, в рамках которой предполагается его применение.
Для проектов информационных систем крупного и среднего масштаба корпорация Oracle предлагает корпоративную редакцию сервера - Oracle Database Enterprise Edition, устанавливаемую на кластерах, мэйнфреймах и суперкомпьютерах под управлением Unix.
Oracle Database Standard Edition включает практически всю функциональность СУБД Oracle, необходимую для создания промышленных баз данных. СУБД может использоваться как сервер масштаба рабочей группы и как центральный сервер БД в небольшой организации.
Версия Oracle9i Personal Edition поддерживает работу пользователя на базе персонального компьютера и позволяет достичь полной совместимости с другими СУБД семейства Oracle.
Версия Oracle9i Lite ориентирована на поддержку мобильной работы пользователей. В состав продукта входит все необходимое для разработки, внедрения и управления приложениями для мобильных устройств на всех популярных операционных системах: Palm OS, Symbian EPOC, Microsoft Windows CE, и Microsoft Windows 95/98/NT/2000. Ядром Oracle9i Lite является реляционная база данных, специально спроектированная для работы на мобильных устройствах, в которой полностью реализованы механизм транзакций, ссылочной целостности и спецификации языка SQL.
В целом СУБД Oracle обеспечивает прозрачность распределенных баз данных и сетевого окружения. Пользователи СУБД могут рассматривать физически распределенную на несколько узлов сети базу данных как одну локальную базу; при этом обращение к удаленным данным осуществляется так же, как и к локальным. В СУБД Oracle в рамках одного SQL-запроса можно запрашивать данные из нескольких БД. Таблицы, участвующие в сложной операции соединения при выборке данных в процессе выполнения запроса, могут располагаться в базах данных различных узлов сети. Используемые методы оптимизации позволяют минимизировать обмен данными в сети во время выполнения распределенных запросов.
Открытая архитектура СУБД Oracle позволяет использовать в одной среде разнородные источники данных, включая базы данных СУБД Oracle, базы данных, функционирующие под управлением СУБД других производителей, различного рода приложения (таким образом, поддерживается работа в гетерогенной среде данных).
Помимо СУБД Oracle на рынке Web-серверов баз данных широкой популярностью пользуется СУБД Microsoft SQL Server 2000.
Наиболее известными СУБД, используемыми на персональных компьютерах, являются: Access 2000, Borland InterBase 6.x, Oracle 9i Personal Edition, Visual FoxPro 7.0 и др.
ВОПРОСЫ ДЛЯ САМОКОНТРОЛЯ
1. Проведите сравнительный анализ возможностей электронных таблиц и СУБД.
2. Укажите основные особенности эволюции языков программирования.
3. В чем особенности объектно-ориентированного программирования?
4. Определите содержательный смысл термина “база данных”.
5. Опишите особенности различных структур баз данных.
6. Какую роль играет связывание таблиц применительно к базам данных?
7. Какими возможными путями база данных может быть передана другому пользователю?
8. Какую роль играют индексные файлы?
9. Определите основные функциональные возможности СУБД.
10. Укажите основные разновидности запросов при работе с базами данных.
11. Каково назначение языка SQL?
12. Укажите особенности и опасности применения языка Java.
13. Определите преимущества языков высокого уровня по сравнению с машинно-зависимыми языками.
14. Объясните причины популярности языка С.
15. Опишите основные концепции развития языков программирования.
16. Приведите классификацию языков программирования.
17. Определите типовой состав среды программирования.
18. Укажите потенциальные преимущества языка Assembler перед языками высокого уровня.
19. Определите основные критерии сравнения сред программирования.
20. Укажите особенности RAD-сред.
21. Охарактеризуйте основные требования, предъявляемые к модулям при разработке программ.
22. Укажите основное назначения языков программирования.
23. Определите особенности оптимизирующих компиляторов.