Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://allbest.ru
Модели базы данных
Введение
информационный программный данные
Современная жизнь немыслима без эффективного управления. Важной категорией являются системы обработки информации, от которых во многом зависит эффективность работы любого предприятия ли учреждения. Такая система должна:
обеспечивать получение общих и/или детализированных отчетов по итогам работы;
позволять легко определять тенденции изменения важнейших показателей;
обеспечивать получение информации, критической по времени, без существенных задержек;
выполнять точный и полный анализ данных.
Современные СУБД в основном являются приложениями Windows, так как данная среда позволяет более полно использовать возможности персональной ЭВМ, нежели среда DOS. Снижение стоимости высокопроизводительных ПК обусловил не только широкий переход к среде Windows, где разработчик программного обеспечения может в меньше степени заботиться о распределении ресурсов, но также сделал программное обеспечение ПК в целом и СУБД в частности менее критичными к аппаратным ресурсам ЭВМ.
Среди наиболее ярких представителей систем управления базами данных можно отметить: Lotus Approach, Microsoft Access, Borland dBase, Borland Paradox, Microsoft Visual FoxPro, Microsoft Visual Basic, а также баз данных Microsoft SQL Server и Oracle, используемые в приложениях, построенных по технологии «клиент-сервер». Фактически, у любой современной СУБД существует аналог, выпускаемый другой компанией, имеющий аналогичную область применения и возможности, любое приложение способно работать со многими форматами представления данных, осуществлять экспорт и импорт данных благодаря наличию большого числа конвертеров. Общепринятыми, также, являются технологи, позволяющие использовать возможности других приложений, например, текстовых процессоров, пакетов построения графиков и т.п., и встроенные версии языков высокого уровня (чаще - диалекты SQL и/или VBA) и средства визуального программирования интерфейсов разрабатываемых приложений. Поэтому уже не имеет существенного значения на каком языке и на основе какого пакета написано конкретное приложение, и какой формат данных в нем используется. Более того, стандартом «де-факто» стала «быстрая разработка приложений» или RAD (от английского Rapid Application Development), основанная на широко декларируемом в литературе «открытом подходе», то есть необходимость и возможность использования различных прикладных программ и технологий для разработки более гибких и мощных систем обработки данных. Поэтому в одном ряду с «классическими» СУБД все чаще упоминаются языки программирования Visual Basic 4.0 и Visual C++, которые позволяют быстро создавать необходимые компоненты приложений, критичные по скорости работы, которые трудно, а иногда невозможно разработать средствами «классических» СУБД. Современный подход к управлению базами данных подразумевает также широкое использование технологии «клиент-сервер».
Таким образом, на сегодняшний день разработчик не связан рамками какого-либо конкретного пакета, а в зависимости от поставленной задачи может использовать самые разные приложения. Поэтому, более важным представляется общее направление развития СУБД и других средств разработки приложений в настоящее время.
Цель любой информационной системы -- обработка данных об объектах реального мира. В широком смысле слова база данных -- это совокупность сведений о конкретных объектах реального мира в какой-либо предметной области. Под предметной областью принято понимать часть реального мира, подлежащего изучению для организации управления и в конечном счете автоматизации, например, предприятие, вуз и т д.
База данных (БД) -- это поименованная совокупность структурированных данных, относящихся к определенной предметной области.
Система управления базами данных (СУБД) -- это комплекс программных и языковых средств, необходимых для создания баз данных, поддержания их в актуальном состоянии и организации поиска в них необходимой информации.
Централизованный характер управления данными в базе данных предполагает необходимость существования некоторого лица (группы лиц), на которое возлагаются функции администрирования данными, хранимыми в базе.
По способу доступа к данным базы данных разделяются на базы данных с локальным доступом и базы данных с удаленным (сетевым) доступом.
Системы централизованных баз данных с сетевым доступом предполагают различные архите ктуры подобных систем;
* файл-сервер;
* клиент-сервер.
Файл-сервер. Архитектура систем БД с сетевым доступом предполагает выделение одной из машин сети в качестве центральной (сервер файлов). На такой машине хранится совместно используемая централизованная БД. Все другие машины сети выполняют функции рабочих станций, с помощью которых поддерживается доступ пользовательской системы к централизованной базе данных. Файлы базы данных в соответствии с пользовательскими запросами передаются на рабочие станции, где в основном и производится обработка. При большой интенсивности доступа к одним и тем же данным производительность информационной системы падает. Пользователи могут создавать также на рабочих станциях локальные БД, которые используются ими монопольно.
Клиент-сервер. В этой концепции подразумевается, что помимо хранения централизованной базы данных центральная машина (сервер базы данных) должна обеспечивать выполнение основного объема обработки данных. Запрос на данные, выдаваемый клиентом (рабочей станцией), порождает поиск и извлечение данных на сервере. Извлеченные данные (но не файлы) транспортируются по сети от сервера к клиенту. Спецификой архитектуры клиент-сервер является использование языка запросов SOL.
Понятие базы данных тесно связано с такими понятиями структурных элементов, как поле, запись, файл (таблица).
Поле -- элементарная единица логической организации данных, которая соответствует неделимой единице информации -- реквизиту. Для описания поля используются следующие характеристики:
имя, например. Фамилия, Имя, Отчество, Дата рождения;
тип, например, символьный, числовой, календарный;
длина, например, 15 байт, причем будет определяться максимально возможным количеством символов;
точность для числовых данных, например два десятичных знака для отображения дробной части числа.
Запись -- совокупность логически связанных полей. Экземпляр записи -- отдельная реализация записи, содержащая конкретные значения ее полей.
Файл (таблица) -- совокупность экземпляров записей одной структуры.
В структуре записи файла указываются поля, значения которых являются ключами первичными (ПК), которые идентифицируют экземпляр записи, и вторичными (ВК), которые выполняют роль поисковых или группировочных признаков (по значению вторичного ключа можно найти несколько записей).
Ядром любой базы данных является модель данных. Модель данных представляет собой множество структур данных, ограничений целостности и операций манипулирования данными. С помощью модели данных могут быть представлены объекты предметной области и взаимосвязи между ними.
Модель данных -- совокупность структур данных и операций их обработки.
СУБД основывается на использовании иерархической, сетевой или реляционной модели, на комбинации этих моделей или на некотором их подмножестве [I].
Рассмотрим три основных типа моделей данных: иерархическую, сетевую и реляционную.
Иерархическая структура представляет совокупность элементов, связанных между собой по определе нным правилам. Объекты, связанные иерархическими отношениями, образуют ориентированный граф (перевернутое дерево).
К основным понятиям иерархической структуры относятся: уровень, элемент (узел), связь. Узел -- это совокупность атрибутов данных, описывающих некоторый объект. На схеме иерархического дерева узлы представляются вершинами графа. Каждый узел на более низком уровне связан только с одним узлом, находящимся на более высоком уровне. Иерархическое дерево имеет только одну вершину (корень дерева), не подчиненную никакой другой вершине и находящуюся на самом верхнем (первом) уровне. Зависимые (подчиненные) узлы находятся на втором, третьем и т.д. уровнях. Количество деревьев в базе данных определяется числом корневых записей.
К каждой записи базы данных существует только один (иерархический) путь от корневой записи.
В сетевой структуре при тех же основных понятиях (уровень, узел, связь) каждый элемент может быть связан с любым другим элементом.
Эти модели характеризуются простотой структуры данных, удобным для пользователя табличным представлением и возможностью использования формального аппарата алгебры отношений и реляционного исчисления для обработки данных.
Реляционная модель ориентирована на организацию данных в виде двумерных таблиц. Каждая реляционная таблица представляет собой двумерный массив и обладает следующими свойствами:
· каждый элемент таблицы -- один элемент данных;
· все столбцы в таблице однородные, т.е. все элементы в столбце имеют одинаковый тип (числовой, символьный и т.д.) и длину;
· каждый столбец имеет уникальное имя;
· одинаковые строки в таблице отсутствуют;
· порядок следования строк и столбцов может быть произвольным.
Отношения представлены в виде таблиц, строки которых соответствуют кортежам или записям, а столбцы -- атрибутам отношений, доменам, полям.
Поле, каждое значение которого однозначно определяет соответствующую запись, называется простым ключом (ключевым полем). Если записи однозначно определяются значениями нескольких полей, то такая таблица базы данных имеет составной ключ.
Чтобы связать две реляционные таблицы, необходимо ключ первой таблицы ввести в состав ключа второй таблицы (возможно совпадение ключей); в противном случае нужно ввести в структуру первой таблицы внешний ключ -- ключ второй таблицы.
3.По нятие информационного объекта
Информационный объект -- это описание некоторой сущности (реального объекта, явления, процес са, события) в виде совокупности логически связанных реквизитов (информационных элементов). Т а кими сущностями для информационных объектов могут служить: цех, склад, материал, вуз, студент, сдача экзаменов и т.д.
Информационный объект определенного реквизитного состава и структуры образует класс (тип), которому присваивается уникальное имя (символьное обозначение), например Студент, Сессия, Ст ипендия.
Информационный объект имеет множество реализации -- экземпляров, каждый из которых представлен совокупностью конкретных значений реквизитов и идентифицируется значением ключа (простого -- один реквизит или составного -- несколько реквизитов). Остальные реквизиты информационного объекта являются описательными. При этом одни и те же реквизиты в одних информационных объектах могут быть ключевыми, а в других -описательными. Информационный объект может иметь несколько ключей.
Нормализация отношений -- формальный аппарат ограничений на формирование отношений (таблиц), который позволяет устранить дублирование, обеспечивает непротиворечивость хранимых в базе данных, уменьшает трудозатраты на ведение (ввод, корректировку) базы данных.
Выделены три нормальные формы отношений и предложен механизм, позволяющий любое отношение преобразовать к третьей (самой совершенной) нормальной форме.
Первая нормальная форма
Отношение называется нормализованным или приведенным к первой нормальной форме, если все его атрибуты простые (далее неделимы). Преобразование отношения к первой нормальной форме может привести к увеличению количества реквизитов (полей) отношения и изменению ключа.
Например, отношение Студент = (Номер, Фамилия, Имя, Отчество, Дата, Группа) наводится в первой нормальной форме.
Функциональная зависимость реквизитов -- зависимость, при которой экземпляре информационного объекта определенному значению ключевого реквизита соответствует только одно значение описательного реквизита.
Такое определение функциональной зависимости позволяет при анализе всех взаимосвязей реквизитов предметной области выделить самостоятельные информационные объекты.
В случае составного ключа вводится понятие функционально полной зависимости.
Функционально полная зависимость не ключевых атрибутов заключается в том, что каждый не ключевой атрибут функционально зависит от ключа, но не находится в функциональной зависимости ни от какой части составного ключа.
Отношение будет находиться во второй нормальной форме, если оно находится в первой нормальной форме, и каждый не ключевой атрибут функционально полно зависит от составного ключа.
Транзитивная зависимость наблюдается в том случае, если один из двух описательных реквизитов зависит от ключа, а другой описательный реквизит зависит от первого описательного реквизита.
Отношение будет находиться в третьей нормальной форме, если оно находится во второй нормал ьной форме, и каждый неключевой атрибут нетранзитивно зависит от первичного ключа.
Для устранения транзитивной зависимости описательных реквизитов необходимо провести "расщепление" исходного информационного объекта. В результате расщепления часть реквизитов удаляется из исходного информационного объекта и включается в состав других (возможно, вновь созданных) информационных объектов.
Внешний уровень поддерживает частные представления данных, требуемые конкретным пользователям. Внешняя модель является подмножеством концептуальной модели. Возможно пересечение внешних моделей по данным. Частная логическая структура данных для отдельного приложения (задачи) или пользователя соответствует внешней модели или подсхеме БД. С помощью внешних моделей поддерживается санкционированный доступ к данным БД приложений (ограничен состав и структура данных концептуальной модели БД доступных в приложении, а также заданы допустимые режимы обработки этих данных: ввод, редактирование, удаление, поиск).
Появление новых или изменение информационных потребностей существующих приложений требуют определения для них корректных внешних моделей, при этом на уровне концептуальной и внутренней модели данных изменений не происходит. Изменения в концептуальной модели, вызванные появлением новых видов данных или изменением и структур, могут затрагивать не все приложения, т.е. обеспечивается определенная независимость программ от данных. Изменения в концептуальной модели должны отражаться и внутренней модели, и при неизменной концептуальной модели возможна самостоятельна модификация внутренней модели БД с целью улучшения ее характеристик (время доступа данным, расхода памяти внешних устройств и др.). Таким образом, БД реализует принцип относительной независимости логической и физической организации данных.
Важнейшим этапом проектирования базы данных является разработка инфологической (информационно-логической) модели предметной области, не ориентированной на СУБД. В инфологической модели средствами структур данных в интегрированном виде отражают состав и структуру данных, а также информационные потребности приложение (задач и запросов).
Информационно-логическая (мифологическая) модель предметной области отражает предметную область в виде совокупности информационных объектов и их структурных связей.
Инфологическая модель предметной области строится первой. Предварительная инфологическая модель строится еще на пред проектной стадии и затем уточняется на более поздних стадиях проект ирования баз данных. Затем на ее основе строятся концептуальная (логическая), внутренняя (физическая) и внешняя модели.
Системой управления базами данных называют программную систему, предназначенную для создания на ЭВМ общей базы данных, используемой для решения множества задач. Подобные системы служат для поддержания базы данных в актуальном состоянии и обеспечивают эффективный доступ пользователей к содержащимся в ней данным в рамках предоставленных пользователям полномочий.
СУБД общего назначения не ориентированы на какую-либо предметную область или на информационные потребности какой-либо группы пользователей. Каждая система такого рода реализуется как программный продукт, способный функционировать на некоторой модели ЭВМ в определенной операционной системе и поставляется многим пользователям как коммерческое изделие. Такие СУБД обладают средствами настройки на работу с конкретной базой данных. Использование СУБД общего назначения в качестве инструментального средства для создания автоматизированных информационных систем, основанных на технологии баз данных, позволяет существенно сокращать сроки разработки, экономить трудовые ресурсы. Этим СУБД присущи развитые функциональные возможности и даже определенная функциональная избыточность.
Используемые в настоящее время СУБД обладают средствами обеспечения целостности данных и надежной безопасности, что дает возможность разработчикам гарантировать большую безопасность данных при меньших затратах сил на низкоуровневое программирование. Продукты, функционирующие в среде WINDOWS, выгодно отличаются удобством пользовательского интерфейса и встроенными средствами повышения производительности.
Производительность СУБД оценивается:
временем выполнения запросов;
скоростью поиска информации в неиндексированных полях;
временем выполнения операций импортирования базы данных из других форматов;
скоростью создания индексов и выполнения таких массовых операций, как обновление, вставка, удаление данных;
максимальным числом параллельных обращений к данным в многопользовательском режиме;
временем генерации отчета.
На производительность СУБД оказывают влияние два фактора:
СУБД, которые следят за соблюдением целостности данных, несут дополнительную нагрузку, которую не испытывают другие программы;
производительность собственных прикладных программ сильно зависит от правильного проектирования и построения базы данных.
Самые быстрые программные изделия отнюдь не обладают самыми развитыми функциональными возможностями на уровне процессора СУБД.
Самой быстрой СУБД является FoxPro 2.6, однако она не обладает средствами соблюдения целостности данных в отличие от более медленной СУБД Access 2.0.
Эта характеристика подразумевает наличие средств, позволяющих удостовериться, что информация в базе данных всегда остается корректной и полной. Должны быть установлены правила целостности, и они должны храниться вместе с базой данных и соблюдаться на глобальном уровне. Целостность данных должна обеспечиваться независимо от того, каким образом данные заносятся в память (в инт ерактивном режиме, посредством импорта или с помощью специальной программы).
Некоторые СУБД имеют хорошо разработанный процессор СУБД для реализации таких возможностей, как уникальность первичных ключей, ограничение (пресечение) операций и даже каскадное обновление и удаление информации. В таких системах проверка корректности, назначаемая полю или таблице, будет проводиться всегда после изменения данных, а не только во время ввода информации с помощью экранной формы. Это свойство можно настраивать для каждого поля и для записи в целом, что позволяет контролировать не только значения отдельных полей, но и взаимосвязи между несколькими полями данной записи.
Эта характеристика отражает:
* возможность обработки СУБД информации, подготовленной другими программными средствами;
* возможность использования другими программами данных, сформированных средствами рассматриваемой СУБД.
Особый интерес представляют следующие форматы файлов: ASCII-файлы, .DBF,WK*, .XLS.
Все рассматриваемые здесь СУБД обладают хорошими возможностями импорта-экспорта данных.
Доступ к данным посредством языка SQL
Язык запросов SQL (Structured Query Language) реализован в целом ряде популярных СУБД для различных типов ЭВМ либо как базовый, либо как альтернативный. В силу своего широкого использования является международным стандартом языка запросов. Язык SQL предоставляет развитые возможности как конечным пользователям, так и специалистам в области обработки данных .
Совместимость с SQL-системами играет большую роль, когда предполагается проведение работы с корпоративными данными. СУБД, хорошо подготовленные к работе в качестве средств первичной обработки информации для SQL-систем, могут открыть двери в системы с архитектурой клиент-сервер.
СУБД имеют доступ к данным SQL в следующих случаях:
базы данных совместимы с ODBC (Open Database Connectivity -- открытое соединение баз данных);
реализована естественная поддержка SQL-баз данных;
возможна реализация SQL-запросов локальных данных.
Многие СУБД могут "прозрачно" подключаться к входным SQL-подсисТемам с помощью ODBC или драйверов, являющихся их частью, поэтому существует возможность создания прикладных программ для них. Некоторые программные продукты также с SQL при обработке интерактивных запросов на получение данных, находящихся сервере или на рабочем месте.
Access 2.0 и Paradox for Windows работают с источниками SQL-данных, совместимых с системой ODBC.
FoxPro (for dos и for Windows) поставляются с дополнительными библиотеками, которые обеспечивают доступ к SQL-базам данных, способным работать совместно с системой ODBC, но эта возможность менее интегрирована, чем средства первичного ввода информации в Access и Paradox for Windows.
Можно напрямую управлять базами данных Access с помощью языка SQL и передавать сквозные SQL-запросы совместимым со спецификацией ODBC SQL-базам данных, таким, как MS SQL Server и Oracle, так что Access способна служить средством разработки масштабируемых систем клиент-сервер.
Реализация языковых средств интерфейсов может быть осуществлена различными способами. Для высококвалифицированных пользователей (разработчиков сложных прикладных систем) языковые средства чаще всего представляются в их явной синтаксической форме, В других случаях функции языков могут быть доступны косвенным образом, когда они реализуются в форме различного рода меню, диалоговых сценариев или заполняемых пользователем таблиц. По таким входным данным интерфейсные средства формируют адекватные синтаксические конструкции языка интерфейса и передают их на исполнение или включают в генерируемый программный код приложения. Интерфейсы с неявным использованием языка широко используются в СУБД для персональных ЭВМ. Примером такого языка является язык QBE (Query-By-Example).
Первая из этих функций обеспечивается языком описания (определения) данных (ЯОД). Описание базы данных средствами ЯОД называется схемой базы данных. Оно включает описание структуры базы данных и налагаемых на нее ограничений целостности в рамках тех правил, которые регламентированы моделью данных используемой СУБД. ЯОД некоторых СУБД обеспечивают также возможности задания ограничений доступа к данным или полномочий пользователей.
FoxPro 2.6 придает xBASE-программам оконные, событийно-управляемые качества. При составлении прикладной программы FoxPro использует диспетчер проекта, управляющий различными файлами исходного текста и данных. Эта составляющая отслеживает индивидуальные элементы: программы, наборы экранных форм, отчеты и файлы баз данных и позволяет компилировать прикладную программу в исполнимый файл.
При работе с СУБД на экран выводятся рабочее поле и панель управления. Панель управления при этом включает меню, вспомогательную область управления и строку подсказки. Расположение этих областей на экране может быть произвольным и зависит от особенностей конкретной программы. Некоторые СУБД позволяют выводить на экран окно директив (командное окно) или строку команд. Познакомиться с видом экрана таких программных средств можно на примере окна СУБД Access 2.0.
В строке состояния (статусной строке) пользователь найдет сведения о текущем режиме работы программы, имени файла текущей базы данных и т. п. Панель инструментов (пиктографическое меню) содержит определенное количество кнопок (пиктограмм), предназначенных для быстрой активизации выполнения определенных команд меню и функций программы. Чтобы представить на экране области таблицы базы данных, формы или отчета, которые на нем в настоящий момент не отображены, используют вертикальную и горизонтальную линейки прокрутки.
Важная особенность СУБД -- использование буфера промежуточного хранения при выполнении ряда операций. Буфер используется при выполнении команд копирования и перемещения для временного хранения копируемых или перемещаемых данных, после чего они направляются по новому адресу. При удалении данных они также помещаются в буфер. Содержимое буфера сохраняется до тех пор, пока в него не будет записана новая порция данных.
наведением курсора на выбранную в меню команду при помощи клавиш управления курсором и нажатием клавиши ввода;
вводом с клавиатуры первой буквы выбранной команды.
Получить дополнительную информацию о командах, составляющих меню СУБД и их использовании можно, войдя в режим помощи.
Несмотря на особенности СУБД совокупность команд, предоставляемых в распоряжение пользователю некоторой усредненной системой управления базами данных, может быть разбита на следующие типовые группы:
команды для работы с файлами;
команды редактирования;
команды форматирования;
команды для работы с окнами;
команды для работы в основных режимах СУБД (таблица, форма, запрос, отчет);
получение справочной информации.
При работе с файлами программа дает возможность пользователю:
* создавать новые объекты базы данных;
* сохранять и переименовывать ранее созданные объекты;
* открывать уже существующие базы данных;
* закрывать ранее открытые объекты;
* выводить на принтер объекты базы данных.
Процесс печати начинается с выбора драйвера принтера. Для каждого типа принтера необходим свой драйвер. Следующий шаг состоит в задании параметров страницы, формировании колонтитулов, а также в выборе вида и размера шрифта. Далее следует установить число копий, качество печати и количество или номера печатаемых страниц документа.
Команда предварительного просмотра позволяет получить представление об общем виде выводимой на принтер информации еще до печати. Размещение информации на странице может быть оптимально приспособлено к ее выбранным параметрам посредством масштабирования и центрирования.
В некоторых СУБД в рассматриваемую группу команд введены команды, обеспечивающие возможность экспорта-импорта и присоединения таблиц, созданных другими программными средствами.
Важное значение имеет визуальное представление данных при выводе. Большинство СУБД предоста вляют в распоряжение пользователя большое число команд, связанных с оформлением выводимой информации. При помощи этих команд пользователь может варьировав направление выравнивания данных, виды шрифта, толщину и расположение линий, высоту букв, цвет фона и т. п. При выполнении любой команды форматирования следует выделить
Выбор формата и направления выравнивания производится автоматически в зависимости от характера вводимых данных. Данные, интерпретируемые программой как текст, выравниваются по левому краю, а числа -- по правому. Автоматический выбор формата и способа выравнивания производится только в том случае, если для заполняемых ячеек пользователем предварительно не заданы другие параметры.
Большинство СУБД дает возможность открывать одновременно множество окон, организуя тем самым "многооконный режим" работы; При этом некоторые окна будут видны на экране, другие находиться под ними. Открыв несколько окон, вы можете сразу работать с несколькими таблицами, быстро пер емещаясь от одной к другой. Существуют специальные команды, позволяющие открывать новое окно, переходить в другое окно, изменять взаимное расположение и размеры окон на экране. Кроме того, у пользователя имеется возможность разделить окно на две части для одновременного просмотра различных частей большой таблицы или фиксировать некоторую часть таблицы, которая не будет исчезать с экрана при перемещении курсора в дальние части таблицы.
Системы управления базами данных имеют в своем составе электронные справочники, предоставля
ющие пользователю инструкции о возможностях выполнения основных операций, информацию по конкретным командам меню и другие справочные данные. Особенностью получения справочной информации с помощью электронного справочника является то, что она выдает информацию в зависимости от ситуации, в которой оказался пользователь. Так, если в меню пользователем была выбрана определенная команда, то после обращения к справочной системе (обычно инициируется клавишей
* запрос-выборка, предназначенный для отбора данных, хранящихся в таблицах, и не изменяющий эти данные;
* запрос-изменение, предназначенный для изменения или перемещения данных; к этому типу запросов относятся: запрос на добавление записей, запрос на удаление записей, запрос на создание таблицы, запрос на обновление;
* запрос с параметром, позволяющий определить одно или несколько условий отбора во время выполнения запроса,
Самым распространенным типом запроса является запрос на выборку. Результатом выполнения запроса является таблица с временным набором данных (динамический набор). Записи динамического набора могут включать поля из одной или нескольких таблиц базы данных. На основе запроса можно построить отчет или форму.
Практически любая СУБД позволяет вывести на экран и принтер информацию, содержащуюся в базе данных, из режимов таблицы или формы. Такой порядок вывода данных может использоваться только как черновой вариант, так как позволяет выводить данные только точно в таком же виде, в каком они содержатся в таблице или форме.
Каждый пользователь, работающий с СУБД, имеет возможность использования специальных средств построения отчетов для вывода данных. Используя специальные средства создания отчетов, пользователь получает следующие дополнительные возможности вывода данных:
* включать в отчет выборочную информацию из таблиц базы данных;
* добавлять информацию, не содержащуюся в базе данных;
* при необходимости выводить итоговые данные на основе информации базы данных;
* располагать выводимую в отчете информацию в любом, удобном для пользователя виде (вертикальное или горизонтальное расположение полей);
* включать в отчет информацию из разных связанных таблиц базы данных.
7. Информационная модель СУБД
Предварительное планирование, подготовка данных, последовательность создания информационной модели.
При проектировании системы обработки данных больше всего нас интересует организация данных. Помочь понять организацию данных призвана информационная модель.
Процесс создания информационной модели начинается с определения концептуальных требований ряда пользователей. Концептуальные требования могут определяться и для некоторых задач (приложений), которые в ближайшее время реализовывать не планируется. Это может несколько повысить трудоемкость работы, однако поможет наиболее полно учесть все нюансы функциональности, требуемой для разрабатываемой системы, и снизит вероятность переделки в дальнейшем. Требования отдельных пользователей должны быть представлены в едином «обобщенном представлении». Последнее называют концептуальной моделью.
Объект - это абстракция множества предметов реального мира, обладающих одинаковыми характеристиками и законами поведения. Объект представляет собой типичный неопределенный экземпляр такого множества.
Объекты объединяются в классы по общим характеристикам. Например, в предложении «Белый Дом является зданием», «Белый Дом» представляет объект, а «здание» - класс. Классы обозначаются абстрактными существительными.
Класс - это множество предметов реального мира, связанных общностью структуры и поведением.
Концептуальная модель представляет объекты и их взаимосвязи без указывания способов их физического хранения. Таким образом, концептуальная модель является, по существу, моделью предметной области. При проектировании концептуальной модели все усилия разработчика должны быть направлены в основном на структуризацию данных и выявление взаимосвязей между ними без рассмотрения особенностей реализации и вопросов эффективности обработки. Проектирование концептуальной модели основано на анализе решаемых на этом предприятии задач по обработке данных. Концептуальная модель включает описания объектов и их взаимосвязей, представляющих интерес в рассматриваемой предметной области и выявляемых в результате анализа данных. Имеются в виду данные, используемые как в уже разработанных прикладных программах, так и в тех, которые только будут реализованы.
Проектирование концептуальной модели базы данных:
Анализ данных: сбор основных данных (например, объекты, связи между объектами).
Определим первоначальные данные:
Заявки - поступающие от магазинов на определённый период.
Договора - заключаются с поставщиками на определённый вид товара.
Поставщики - организации или физические лица, с которыми заключаются договора на поставку товара.
Заказчики - в основном магазины, а также предприятия и организации, подающие заказ на приобретение того или иного товара.
Счета - ведутся на этапе заключения договором с поставщиками, а также с заказчиками.
Накладные - создаются на основании получения заказа о заказчика, для отгрузки.
Справки - получение/выдача различных справок как заказчику так и поставщику.
Товар - присутствует на основании заявки и договора с поставщиком.
Взаимосвязь выражает отображение или связь между двумя множес твами данных. Различают взаимосвязи типа «один к одному», «один ко многим» и «многие ко многим».
Например, если заказчик производит заказ на покупку товара впервые, осуществляется первичная регистрация его данных и сведений о сделанном заказе. Если же заказчик производит заказ повторно, осуществляется регистрация только данного заказа. Вне зависимости от того, сколько раз данный заказчик производил заказы, он имеет уникальный идентификационный номер (уникальный ключ заказа). Информация о каждом заказчике включает наименование заказчика, адрес, телефон, факс, фамилию, имя, отчество, признак юридического лица и примечание. Таким образом, свойствами объекта Заказчик являются «уникальный ключ заказчика», «наименование заказчика».
Следующий представляющий для нас интерес объект -- Товар. Этот объект имеет свойства «уникальный ключ товара», «наименование товара».
Второй рассматриваемый объект -- Поставщик. Его свойствами являются «уникальный ключ поставщика», «наименование поставщика».
Третий рассматриваемый объект -- Заказчик. Его свойствами являются «уникальный ключ заказчика», «наименование заказчика».
Допустим, в определенный момент времени один заказчик может сд елать только один заказ. В этом случае между объектами Заказчик и Товар устанавливается взаимосвязь «один к одному».
В определенный момент времени один заказчик может стать облад ателем нескольких товаров, при этом несколько заказчиков не могут являться обладателями одного товара (на условии если заказчик не претендует на часть товара). Взаимосвязь «один ко многим» можно обозначить с помощью одинарной стрелки в направлении к «одному» и двойной стрелки в направлении ко «многим» .В этом случае одной записи данных первого объекта (его часто называют родительским или основным) будет соответствовать несколько записей второго объекта (дочернего или подчиненного). Взаимосвязь «один ко многим» очень распространена при разработке реляционных баз данных. В качестве родительского объекта часто выступает справочник, а в дочернем хранятся уникальные ключи для доступа к записям справочника. В нашем примере в качестве такого справочника можно представить объект Заказчик, в котором хранятся сведения о всех заказчиках. При обращении к записи для определенного заказчика нам доступен список всех покупок, которые он сделал, и сведения о которых хранятся в объекте Товар.
...Понятие и структура банка данных. Основные структурные элементы базы данных. Система управления базами данных. Преимущества централизации управления данными. Понятие информационного объекта. Современные технологии, используемые в работе с данными.
курсовая работа , добавлен 02.07.2011
Обзор и сравнительная характеристика программного обеспечения для создания СУБД. Принципы организации данных. Основные возможности MS Access. Разработка структуры и реализация средствами SQL базы данных для учета заказов, наличия и продажи автозапчастей.
курсовая работа , добавлен 27.05.2013
Современные системы управления базами данных (СУБД). Анализ иерархической модели данных. Реляционная модель данных. Постреляционная модель данных как расширенная реляционная модель, снимающая ограничение неделимости данных, хранящихся в записях таблиц.
научная работа , добавлен 08.06.2010
Базы данных с двумерными файлами и реляционные системы управления базами данных (СУБД). Создание базы данных и обработка запросов к ним с помощью СУБД. Основные типы баз данных. Базовые понятия реляционных баз данных. Фундаментальные свойства отношений.
реферат , добавлен 20.12.2010
Технология отображения концептуальной модели базы данных на реляционную модель данных. Описание связей между атрибутами отношения при помощи функциональной зависимости. Нормализация как процесс последовательной замены таблицы ее полными декомпозициями.
презентация , добавлен 19.08.2013
Теоретические аспекты СУБД. Основные понятия. Функциональные возможности СУБД. Архитектура систем управления. Разработка базы данных. Крупные массивы данных размещают, как правило, отдельно от исполняемого программы, и организуют в виде базы данных.
курсовая работа , добавлен 23.02.2006
Концептуальная модель базы данных "Бюро по трудоустройству". Разработка информационного и программного обеспечения объектов автоматизации. Реализация базы данных в СУБД MsAccess. Запросы к базе данных. Таблицы, отчеты и макросы. Интерфейс пользователя.
курсовая работа , добавлен 30.05.2016
Порядок проектирования и разработки базы данных и программного обеспечения. Информация о структуре базы данных, созданных таблицах, формах, отчетах, запросах, хранимой информации. Логическая и концептуальная модели данных; выбор программного обеспечения.
курсовая работа , добавлен 20.01.2010
Развитая автоматизированная информационная система как условие обеспечения эффективного функционирования организации. Проектирование и построение информационной логической модели базы данных. Краткая характеристика Access. Разработка структуры таблиц.
курсовая работа , добавлен 27.02.2009
Классификация моделей построения баз данных. Работа с реляционными базами данных: нормализация таблиц, преобразование отношений полей, преобразование функциональной модели в реляционную. Понятие языка определения данных и языка манипуляции данными.
Темы: логические модели баз данных, идентификация объектов и записей, поиск записей.
Ядром любой базы данных является модель данных. Модель данных — совокупность структур данных и операций их обработки. По способу установления связей между данными различают иерархическую, сетевую и реляционную модели.
Иерархическая модель позволяет строить базы данных с древовидной структурой. В них каждый узел содержит свой тип данных (сущность) На верхнем уровне дерева в этой модели имеется один узел — «корень», на следующем уровне располагаются узлы, связанные с этим корнем, затем узлы, связанные с узлами предыдущего уровня и т д., причем каждый узел может иметь только одного предка (рис. 1)
Поиск данных в иерархической системе всегда начинается с корня. Затем производится спуск с одного уровня на другой пока не будет достигнут искомый уровень. Перемещения по системе от одной записи к другой осуществляются с помощью ссылок.
Использование ссылок для организации доступа к отдельным элементам структуры не позволяет сократить процедуру поиска, в основу которой положен последовательный перебор. Процедура поиска будет эффективнее, если будет предварительно установлен некоторый порядок перехода к следующему элементу дерева.
Основные достоинства иерархической модели — простота описания иерархических структур реального мира и быстрое выполнение запросов, соответствующих структуре данных, однако, они часто содержат избыточные данные. Кроме того, не всегда удобно каждый раз начинать поиск нужных данных с корня, а другого способа перемещения по базе в иерархических структурах нет.
Иерархические модели характерны для многих областей, однако во многих случаях отдельная запись требует более одного представления или связана с несколькими другими. В результате получаются обычно более сложные структуры по сравнению с древовидными. В сетевой структуре любой элемент может быть связан с любым другим элементом. Примеры сетевых структур приведены на рис. 2
Сетевую структуру можно описать с помощью исходных и порожденных элементов. Удобно представлять ее так, чтобы порожденные элементы располагались ниже исходных.
Желательно отличать простые и сложные сетевые структуры.
Если один информационный объект связан с целой совокупностью других объектов или все объекты связаны со всеми, то такая структура называется сложной.
Например, одна группа студентов связана со всеми студентами группы. Или в примере учебного заведения на рис. 3 каждый преподаватель может обучать много (теоретически всех) студентов, и каждый студент может обучаться у многих (теоретически всех) преподавателей. Поскольку на практике это, естественно, невозможно, приходится прибегать к некоторым ограничениям.
Некоторые структуры содержат циклы. Циклом считается ситуация, в которой предшественник узла является в то же время его последователем. Отношения «исходный — порожденный» образуют при этом замкнутый контур. Например, завод выпускает различную продукцию. Некоторые изделия производятся на других заводах-субподрядчиках. С одним контрактом может быть связано производство нескольких изделий. Представление этих отношений и образует цикл.
Иногда объекты связаны с другими объектами того же типа. Такая ситуация называется петлей. На рис. 4 приведены две достаточно распространенные ситуации, где могут использоваться петли. В массиве служащих специфицированы связи, существующие между некоторыми служащими. В базу данных списка материалов введено дополнительное усложнение: некоторые узлы сами состоят из узлов.
Разделение сетевых структур на простые и сложные необходимо потому, что сложные структуры требуют более сложных методов физического представления. Это не всегда является недостатком, поскольку сложную сетевую структуру можно (а в большинстве случаев и следует) преобразовать к простому виду.
Использование иерархической и сетевой моделей ускоряет доступ к информации в базе данных. Но поскольку каждый элемент данных должен содержать ссылки на некоторые другие элементы, требуются значительные ресурсы как дисковой, так и основной памяти ЭВМ. Недостаток основной памяти, конечно, снижает скорость обработки данных. Кроме того, для таких моделей характерна сложность реализации системы управления базами данных (СУБД).
В задачах обработки информации атрибуты именуют (обозначают) и приписывают им значения.
При обработке информации пользователь имеет дело с совокупностью объектов, информацию о свойствах каждого из которых надо сохранять (записывать) как данные, чтобы при решении задач их можно было найти и выполнить необходимые преобразования.
Таким образом, любое состояние объекта характеризуется совокупностью атрибутов, имеющих некоторое из значений в этот момент времени. Атрибуты фиксируются на некотором материальном носителе в виде записи. Запись — совокупность (группа) формализованных элементов данных (значений атрибутов, представленных в том или ином формате). Значение атрибута идентифицирует объект, т.е. использование значения в качестве поискового признака позволяет реализовать простой критерий отбора по условию сравнения.
Отдельный объект всегда уникален, поэтому запись, содержащая данные о нем, также должна иметь уникальный идентификатор, причем никакой другой объект не должен иметь такой же идентификатор. Поскольку идентификатор — суть значение элемента данных, в некоторых случаях для обеспечения уникальности требуется использовать более одного элемента. Например, для однозначной идентификации записей о дисциплинах учебного плана необходимо использовать элементы СЕМЕСТР и НАИМЕНОВАНИЕ ДИСЦИПЛИНЫ, так как возможно преподавание одной дисциплины в разных семестрах.
Предложенная выше схема представляет атрибутивный способ идентификации содержания объекта. Она является достаточно естественной для хорошо структурированных (фактографических) данных. Причем, структурированность относится не только к форме представления данных (формат, способ хранения), но и к способу интерпретации значения пользователем (значение параметра не только представлено в предопределенной форме, но и обычно сопровождается указанием размерности величины, что позволяет пользователю понимать ее смысл без дополнительных комментариев). Таким образом, фактографические данные предполагают возможность их непосредственной интерпретации.
Однако этот способ практически не подходит для идентификации слабо структурированной информации, связанной с объектами, имеющими идеальную природу. Такие объекты зачастую определяются логически и опосредованно — через другие объекты. Для их описания используются естественные или искусственные. Соответственно, для понимания смысла пользователю необходимо использовать соответствующие правила языка, и располагать некоторой информацией, позволяющей идентифицировать и связать получаемую информацию с наличным знанием. То есть процесс интерпретации такого рода данных имеет опосредованный характер и требует использования дополнительной информации, причем такой, которая не обязательно присутствует в формализованном виде в базе данных.
Программисту или пользователю необходимо иметь возможность обращаться к отдельным, нужным ему записям или отдельным элементам данных.
Для этого можно использовать следующие способы:
Задать машинный адрес данных и в соответствии с физическим форматом записи прочитать значение. Это случаи, когда программист должен быть «навигатором».
Сообщить системе имя записи или элемента данных, которые он хочет получить, и возможно, организацию набора данных. В этом случае система сама произведет выборку (по предыдущей схеме), но для этого она должна будет использовать вспомогательную информацию о структуре данных и организации набора. Такая информация по существу будет избыточной по отношению к объекту, однако общение с базой данных не будет требовать от пользователя знаний программиста.
В качестве ключа , обеспечивающего доступ к записи, можно использовать идентификатор — отдельный элемент данных. Ключ , который идентифицирует запись единственным образом, называется первичным (главным).
В том случае, когда ключ идентифицирует некоторую группу записей, имеющих определенное общее свойство, ключ называется вторичным (альтернативным) . Набор данных может иметь несколько вторичных ключей, необходимость введения которых определяется требованием оптимизации процессов нахождения записей по соответствующему ключу.
Иногда в качестве идентификатора используют составной сцепленный ключ — несколько элементов данных, которые в совокупности, например, обеспечат уникальность идентификации каждой записи набора данных.
При этом ключ может храниться в составе записи или отдельно. Например, ключ для записей, имеющих неуникальные значения атрибутов, для устранения избыточности целесообразно хранить отдельно.
Введенное понятие ключа является логическим и его не следует путать с физической реализацией ключа — индексом, обеспечивающим доступ к записям, соответствующим отдельным значениям ключа.
Один из способов использования вторичного ключа в качестве входа — организация инвертированного списка, каждый вход которого содержит значение ключа вместе со списком идентификаторов соответствующих записей. Данные в индексе располагаются в возрастающем или убывающем порядке, поэтому алгоритм нахождения нужного значения довольно прост и эффективен, а после нахождения значения запись локализуется по указателю физического расположения. Недостатком индекса является то, что он занимает дополнительное пространство и его надо обновлять каждый раз, когда удаляется, обновляется или добавляется запись.
В общем случае инвертированный список может быть построен для любого ключа, в том числе составного.
В контексте задач поиска можно сказать, что существуют два основных способа организации данных: Первый способ представляет прямую организацию массива, второй — является инверсией первого. Прямая организация массива удобна для поиска по условию «Каковы свойства указанного объекта?», а инвертированная — для поиска по условию «Какие объекты обладают указанным свойством?».
Имеется множество способов реализации элементарных единиц данных, и поэтому известны многообразные модели данных. Модель данных дает правила для их структурирования. Как правило, операции над данными соотносятся с их структурой. Разновидности существующих моделей данных соответствуют разнообразию областей применения и предпочтений пользователей.
Для представления данных используются модели, основанные на формах представления информации. Такие модели называются синтаксическими.
В специальной литературе встречается описание довольно большого количества моделей данных . Широкое распространение получили иерархическая, сетевая и реляционная. Кроме них к самым известным относятся еще бинарная модель и семантическая сеть.
Классической, наиболее давно используемой считается модель данных, в основе которой лежит иерархическая структура типа дерева (фрагмент представлен на рис. 10). Часто используется также модель «упорядоченное дерево», в которой значим относительный порядок поддеревьев. В такой модели каждая следующая единица информации связана только с одной предыдущей, а предыдущие могут быть связаны с несколькими последующими.
Сетевая модель данных основана на таком представлении информации, при котором одна единица информации может быть связана с произвольным числом других (рис. 11).
Реляционная модель данных базируется на табличных методах и средствах представления данныхи манипулирования ими. В такой модели информация о предметной области отображается в таблицу, называемую «отношением» (рис. 12). Строка такой таблицы называется кортежем, столбец – атрибутом. Каждый атрибут может принимать некоторое подмножество значений из определенной области – домена.
Подавляющее большинство СУБД, ориентированных на персональные ЭВМ, являются системами, построенными на основе реляционной модели данных, – реляционными СУБД.
Бинарная модель данных – это графовая модель, в которой вершины отражают представления простых однозначных атрибутов, а дуги – представления бинарных связей между атрибутами (рис. 13).
Бинарная модель не получила широкого распространения, но в ряде случаев находит практическое применение. Так, в области искусственного интеллекта уже давно ведутся исследования с целью представления информации в виде бинарных отношений .
Семантические сети в качестве моделей данных были предложены исследователями, работавшими над различными проблемами искусственного интеллекта. Так же, как в сетевой и бинарной моделях, базовые структуры семантической сети могут быть представлены графом, множество вершин и дуг которого образует сеть. Однако семантические сети предназначены для представления и систематизации знаний самого общего характера.
Таким образом, семантической сетью можно считать любую графовую модель (например, помеченный бинарный граф), если изначально четко оговорено, что обозначают вершины и дуги и как они используются.
Семантические сети являются богатыми источниками идей моделирования данных, чрезвычайно полезных в плане решения проблемы представления сложных ситуаций. Они могут применяться независимо или совместно с идеями, положенными в основу других моделей данных. Их интересной особенностью служит то, что расстояние, измеренное на сети (семантическое расстояние, или метрика), играет важную роль, определяя близость взаимосвязанных понятий. При этом предусмотрена возможность в явной форме подчеркнуть, что семантическое расстояние велико. Как показано на рис. 14, МАГАЗИН соотносится с личностью ПРОДАВЕЦ, и в то же время ПРОДАВЦУ присущ ВЕС. Взаимосвязь личности со специальностью очевидна, однако из этого не обязательно следует взаимосвязь МАГАЗИНА и ВЕСА.
Нужно сказать, что моделям данных типа семантической сети при всем богатстве их возможностей в моделировании сложных ситуаций свойственны усложненность и некоторая неэкономичность в концептуальном плане.
Остановимся подробнее на реляционной, иерархической и сетевой моделях данных.
Реляционная модель данных характеризуется следующими компонентами:
– информационной конструкцией: отношением с двухуровневой структурой;
– допустимыми операциями: проекцией, выборкой, соединением и некоторыми другими;
– ограничениями: функциональными зависимостями между атрибутами отношения.
Каждому классу объектов Р материального мира ставится в соответствие некоторое множество атрибутов, например А 1 , А 2 , ..., А n . Отдельный объект класса Р описывается строкой величин (a 1 , а 2 , ..., a n) , где a i – значение атрибута A i .
Строка (a 1 , а 2 , ..., a n ) называется кортежем. Всему классу объектов соответствует множество кортежей, именуемое отношением. Обозначим отношение, описывающее класс объектов Р , также через Р .
Выражение Р (А 1 , А 2 , ..., А n ) называется схемой отношения Р .
Для каждого компонента кортежа должна быть указана его связь с соответствующим атрибутом. В реляционной модели данных для обеспечения этой связи порядок компонентов кортежа совпадает с порядком следования атрибутов в схеме отношения.
Каждое отношение отражает состояние класса объектов в некоторый момент времени. Следовательно, одной схеме отношения в разные моменты времени могут соответствовать разные отношения.
Множество значений отношения можно представить в виде таблицы, в которой соблюдаются следующие соответствия:
– название таблицы и перечень названий граф соответствуют схеме отношения;
– строке таблицы соответствует кортеж отношения;
– все строки таблицы (а значит, все кортежи) различны;
– порядок строк и столбцов произвольный (в частности, реляционная модель данных не предполагает специальную сортировку строк).
Описание процессов обработки отношений может быть выполнено двумя способами:
– указанием перечня операций, выполнение которых приводит к требуемому результату (процедурный подход),
– описанием свойств, которым должно удовлетворять результирующее отношение (декларативный подход).
Рассмотрим процедурный подход . Множество отношений и операций над ними образует реляционную алгебру. Как правило, список операций содержит проекцию, выборку, объединение, пересечение, вычитание, соединение.
Проекцией называется операция, которая переносит в результирующее отношение столбцы исходного отношения, указанные в условии операции. Алгебраическая запись проекции имеет вид
Т = R [X ],
где R – исходное отношение; Т – результирующее отношение; X – список атрибутов в структуре отношения Т (условие проекции).
Рассмотрим отношение O 1 , содержащее сведения о продаже продукции в 2010 г. (табл. 1).
Таблица 1
Отношение Т 1 , содержащее сведения только о фактическом выпуске продукции, получается в результате выполнения проекции
Т 1 = О 1 [Магазин, Продукция, Факт]
и имеет вид табл. 2.
Таблица 2
Столбцы можно указывать в любом порядке:
Т 1 = О 1 [Продукция, Магазин, Факт].
Выборкой называется операция, переносящая в результирующее отношение те строки из исходного отношения, которые удовлетворяют условию выборки. Условие выборки проверяется в каждой строке отношения по отдельности и не может охватывать информацию из нескольких строк. Существуют две простейшие разновидности условия выборки:
1) Имя атрибута 1 <знак сравнения> Значение, где допускаются знаки сравнения =, #, >, ≥, <, ≤. Например: Цена > 100.
Имена атрибутов должны содержаться в структуре исходного отношения. Алгебраическая запись выборки имеет вид
T = R [p ],
где R – исходное отношение; Т – результирующее отношение; р – условие выборки.
Например, получим значения Т 2 = О 1 [Продукция = «П 1 »] (табл. 3).
Таблица 3
Операции объединения, пересечения и вычитания производятся над двумя исходными отношениями с одинаковой структурой.
Обозначим исходные отношения через R 1 и R 2 , результирующее – через Т .
Объединение Т = U (R 1 , R 2) содержит строки, присутствующие либо в отношении R 1 , либо в R 2 .
Пересечение Т = I (R 1 , R 2) содержит строки, присутствующие в отношениях R 1 и R 2 одновременно.
Вычитание Т = M (R 1 , R 2) содержит те строки из R 1 , которые отсутствуют в R 2 .
Операция соединения отношений выполняется над двумя исходными отношениями и создает одно результирующее. Каждая строка первого исходного отношения сопоставляется по очереди со всеми строками второго отношения, и если для этой пары строк соблюдается условие соединения, то они сцепляются и образуют очередную строку в результирующем отношении. Условие соединения имеет вид
Имя атрибута 1 <знак сравнения> Имя атрибута 2,
где Имя атрибута 1 находится в одном исходном отношении, а Имя атрибута 2 – в другом. Будем использовать следующее обозначение операции соединения:
T = R l [p ] R 2 ,
где R 1 и R 2 – исходные отношения; Т – результирующее отношение; р – условие соединения.
Один из наиболее важных частных случаев соединения называется натуральным соединением и имеет следующие особенности:
– знаком сравнения в условии соединения является «=»;
– Имя атрибута 1 и Имя атрибута 2 должны совпадать, а точнее, содержать пересечение списков атрибутов исходных отношений;
– список атрибутов результирующего отношения образуется в результате объединения списков атрибутов исходных отношений.
Обозначение натурального соединения не содержит условия соединения и имеет вид Т = R l * R 2 .
Декларативный подход к обработке реляционных баз данных основан на интерпретации понятий и методов математической логики . В частности, реляционное исчисление базируется на исчислении предикатов. Назовем необходимые для реляционного исчисления понятия математической логики.
1. Символы переменных и констант. В языковых конструкциях реляционного исчисления им соответствуют имена атрибутов и переменных, а также константы.
2. Логические связки «и», «или», «не» и знаки сравнения =, # (не равно), >, <, ≥, ≤.
3. Термы, т. е. любые константы и переменные, а также функции, аргументами которых служат термы.
4. Элементарные формулы – предикаты, аргументами которых выступают термы. Предикаты, связанные операциями «и», «или», «не», также являются элементарными формулами. Элементарными формулами служат, например, выражения Фамилия = «Петров» и Сумма ≤ Итог.
5. Формулы, т. е. результат применения кванторов общности или существования к элементарным формулам. Формула соответствует запросу к реляционной базе данных, выраженному средствами реляционного исчисления.
Главная задача проектирования базы данных ЭИС – определение количества отношений (или иных составных единиц информации) и их атрибутного состава.
Задача группировки атрибутов в отношения, набор которых заранее не фиксирован, допускает множество различных вариантов решений. Рациональные варианты группировки должны учитывать следующие требования:
– множество отношений должно обеспечивать минимальную избыточность представления информации;
– корректировка отношений не должна приводить к двусмысленности или потере информации;
– перестройка набора отношений при добавлении в базу данных новых атрибутов должна быть минимальной.
Нормализация представляет собой один из наиболее изученных способов преобразования отношений, позволяющих улучшить характеристики БД по перечисленным критериям .
Ограничения на значения, хранимые в реляционной базе данных, достаточно многочисленны . Соблюдение этих ограничений в конкретных отношениях связано с наличием так называемых нормальных форм. Процесс преобразования отношений базы данных к той или иной нормальной форме именуется нормализацией отношений. Нормальные формы нумеруются последовательно от 1 по возрастанию. Чем больше номер нормальной формы, тем больше ограничений на хранимые значения должно соблюдаться в соответствующем отношении.
Ограничения, типичные для реляционной модели данных, – это функциональные и многозначные зависимости, а также их обобщения. В принципе, множество дополнительных ограничений может расти и, следовательно, будет увеличиваться число нормальных форм. Применяемые ограничения ориентированы на сокращение избыточной информации в реляционной базе данных.
Отношение в первой нормальной форме (1НФ) – это обычное отношение с двухуровневой структурой. Следующие нормальные формы (вторая и третья) используют ограничения, связанные с понятием функциональной зависимости. Функциональные зависимости определяются для атрибутов, находящихся в одном и том же отношении, удовлетворяющем 1НФ.
Простейший случай функциональной зависимости охватывает два атрибута. В отношении R (A , B , ..., J ) атрибут А функционально определяет атрибут В , если в любой момент времени каждому значению А В (обозначается А → В ).
Иначе говоря, В функционально зависит от А (В = f (A )). Первое обозначение оказывается более удобным, когда число функциональных зависимостей растет и их взаимосвязи становятся труднообозримыми; оно и будет использоваться в дальнейшем. Отсутствие функциональной зависимости обозначается как А → В .
Для атрибутов А и В некоторого отношения возможны следующие ситуации:
– отсутствие функциональной зависимости;
– наличие А → В (или В → А ), но не обеих зависимостей вместе;
– наличие взаимно-однозначного соответствия А ↔ В .
Понятие функциональной зависимости распространяется на ситуацию с тремя и более атрибутами в следующей форме. Группа атрибутов (А , В , С ) функционально определяет атрибут D в отношении T (A , B , C , D , ..., J ), если каждому сочетанию значений <а, b , с > соответствует единственное значение d (а – значение A ; b – значение В ; с – значение С ; d – значение D ). Наличие такой функциональной зависимости будем обозначать А , В , С → D .
Существование функциональных зависимостей связано с применяемыми способами кодирования атрибутов. Так, для множества учреждений можно утверждать, что каждый отдел (как объект предметной области) относится к единственному учреждению. Однако этого недостаточно для доказательства функциональной зависимости Отдел → Учреждение. Если в каждом учреждении отделы нумеруются последовательно, начиная с 1, то функциональная зависимость неверна. Если же код отдела, кроме номера, содержит и код учреждения (или уникальность кодов обеспечивается каким-либо другим способом), то функциональная зависимость Отдел → Учреждение справедлива.
Для показателя со множеством атрибутов-признаков Р = (Р 1 , Р 2 , ..., Р n ) и атрибутом-основанием Q справедлива функциональная зависимость Р → Q , хотя нельзя утверждать, что это единственная зависимость на указанных атрибутах.
Вероятным ключом отношения называется такое множество атрибутов, каждое сочетание значений которых встречается только в одной строке отношения, и никакое подмножество атрибутов этим свойством не обладает. Вероятных ключей в отношении может быть несколько. Их важность при обработке данных определяется тем, что выборка по известному значению вероятного ключа дает в результате одну строку отношения либо ни одной.
На практике атрибуты вероятного ключа отношения связываются со свойствами тех объектов и событий, информация о которых хранится в отношении. Если в результате корректировки отношения изменились имена атрибутов, образующих ключ, то информация будет серьезно искажена. Следовательно, систематическая проверка свойств вероятного ключа позволяет контролировать достоверность информации в отношении.
Когда в отношении присутствует несколько вероятных ключей, одновременное наблюдение за ними очень затруднено. Целесообразно выбрать один из них в качестве основного (первичного). Первичным ключом отношения называется такой вероятный ключ, по значениям которого производится контроль достоверности информации в отношении.
Применительно к экономической информации в подавляющем большинстве случаев отношения, полученные из существующих экономических документов, содержат единственный вероятный ключ, который является и первичным ключом. Это объясняется тем, что содержимое экономических документов понимается всеми пользователями одинаково. Далее будем иметь в виду только такие отношения. Присутствие двух и более вероятных ключей в отношениях с осмысленной информацией можно объяснить наличием нескольких возможных способов интерпретации одних и тех же данных. Первичный ключ часто называется просто ключом.
В отношениях с большим числом строк нахождение первичного ключа путем непосредственного применения определения достаточно затруднено. Кроме того, на стадии проектирования ЭИС значения многих отношений просто неизвестны, поэтому практически первичный ключ отношения вычисляется по имеющимся функциональным зависимостям.
Каждое значение первичного ключа встречается только в одной строке отношения. Значение любого атрибута в этой строке также единственное. Если через К обозначить атрибуты первичного ключа в отношении R (A , B , C , ..., J ), то справедливы следующие функциональные зависимости: К → А , К → В , К → С , ..., К → J . Набор атрибутов первичного ключа функционально определяет любой атрибут отношения. Обратное утверждение также верно: если найдена группа атрибутов, которая функционально определяет все атрибуты отношения по отдельности, и эту группу нельзя сократить, то найден первичный ключ отношения.
Для исходного множества функциональных зависимостей существует ряд закономерностей, знание которых позволяет получать производные зависимости. Отметим некоторые из них:
– если А , В → А , то и А , В → В ;
– А → В и А → С тогда и только тогда, когда А → ВС ;
– если А → В и В → С , то А →С ;
– если А → В , то АС → В (С произвольно);
– если А → В , то АС → ВС (С произвольно);
– если А → В и ВС → D , то АС → D .
Если заранее известно, что вероятный ключ в отношении только один, то его можно найти простым способом. Вероятный ключ (если он единственный, т. е. совпадает с первичным ключом) – это набор атрибутов, которые не встречаются в правых частях всех функциональных зависимостей. Иными словами, из полного списка атрибутов отношения необходимо вычеркнуть атрибуты, встречающиеся в правых частях всех функциональных зависимостей. Оставшиеся атрибуты образуют первичный ключ.
Отношение имеет вторую нормальную форму (2НФ), если оно соответ-ствует 1НФ и не содержит неполных функциональных зависимостей.
Неполная функциональная зависимость состоит из двух зависимостей:
– вероятный ключ отношения функционально определяет некоторый неключевой атрибут,
– часть вероятного ключа функционально определяет этот же неключевой атрибут.
Отношение, не соответствующее 2НФ, характеризуется избыточностью хранимых данных. База данных находится в 2НФ, если все ее отношения находятся в 2НФ.
Отношение соответствует 3НФ, если оно соответствует 2НФ и среди его атрибутов отсутствуют транзитивные функциональные зависимости (ФЗ).
Транзитивная ФЗ включает в себя две ФЗ:
– вероятный ключ отношения функционально определяет неключевой атрибут;
– этот атрибут функционально определяет другой неключевой атрибут.
Если К – ключ отношения, А , В – неключевые атрибуты и К → А , А → В – справедливые ФЗ, то они являются транзитивными. Частный случай транзитивной ФЗ – неполная ФЗ, когда К = С , Е и К → Е , Е → А .
База данных находится в 3НФ, если все ее отношения находятся в 3НФ.
Реляционная база данных, в целом соответствующая третьей нормальной форме, характеризуется рядом свойств, знание которых облегчает и упорядочивает процессы обработки данных. Реализацию запросов к базе данных с помощью операторов реляционной алгебры можно описать следующими правилами.
1. В словесной формулировке запроса выделить имена атрибутов, составляющие оболочку, вход и выход запроса, а также условия выборки.
2. Зафиксировать множество атрибутов оболочки. Если все необходимые атрибуты находятся в каком-либо одном отношении, то последующие операции выборки и проекции проводятся только с ним. Если требуемые атрибуты распределены по нескольким отношениям, то эти отношения необходимо соединить. Каждая пара отношений соединяется по условию равенства атрибутов с совпадающими именами (или определенных на общем домене). После каждого соединения с помощью проекции можно отсечь ненужные для последующих операций атрибуты.
4. Если запрос можно разделить на части (подзапросы), то его реализация также разделяется на части, где результатом каждого подзапроса является отдельное отношение.
5. Указанная последовательность действий стандартна, но, возможно, создает промежуточные отношения слишком большого размера. Этот недостаток можно компенсировать, выполняя некоторые выборки и проекции над исходными отношениями (до проведения соединения) и меняя взаимный порядок требуемых соединений.
Сетевая БД представляется как множество отношений и веерных отношений . Отношения разделяются на основные и зависимые.
Веерным отношением W (R , S ) называется пара отношений, состоящая из одного основного (R ), одного зависимого отношения (S ) и связи между ними, при условии, что каждое значение зависимого отношения связано с единственным значением основного отношения . Это условие является ограничением, характерным для сетевой модели данных в целом. Способ реализации этого ограничения в памяти ЭВМ неодинаков у различных сетевых СУБД.
Допустимые в сетевой модели данных операции представляют собой различные варианты выборки.
Сетевые базы данных в зависимости от ограничений на вхождение отношений в веерные отношения разделяются на двухуровневые и многоуровневые сети.
Ограничение двухуровневых сетей состоит в том, что каждое отношение может существовать в одной из перечисленных ниже ролей:
– вне каких-либо веерных отношений;
– в качестве основного отношения в любом количестве веерных отношений;
– в качестве зависимого отношения в любом количестве веерных отношений.
Запрещается существование отношения в качестве основного в одном контексте и одновременно в качестве зависимого – в другом.
Многоуровневые сети не предусматривают никаких ограничений на взаимосвязь веерных отношений, в некоторых сетевых СУБД разрешены даже циклические структуры сети.
Для двухуровневых сетевых СУБД вводятся еще два ограничения (с теоретической точки зрения необязательные):
– первичный ключ основного отношения может быть только одноатрибутным;
– веерное отношение существует, если первичный ключ основного отношения выступает частью первичного ключа зависимого отношения.
Для организации веерного отношения в памяти ЭВМ в структуру основного и зависимого отношений вводится дополнительный атрибут, называемый адресом связи. Значения адресов связи совместно обеспечивают в веерном отношении соответствие каждого значения зависимого отношения S единственному значению основного отношения R .
Значение отношения при хранении в памяти ЭВМ часто называется записью. Адресом связи именуется атрибут в составе записи, в котором хранится начальный адрес или номер следующей обрабатываемой записи.
Связь значений зависимого отношения с единственным значением основного отношения в простейшем случае обеспечивается следующим образом. Адрес связи некоторой записи основного отношения указывает на одну из записей зависимого отношения (значением адреса связи основного отношения служит начальный адрес этой записи зависимого отношения), адрес связи указанной записи зависимого отношения – на следующую запись зависимого отношения, связанную с той же записью основного отношения, и т. д. Последняя запись зависимого отношения в этой цепочке адресует названную выше запись основного отношения. Получается кольцевая структура адресов связи, называемая веером , где роль «ручки» веера играет запись основного отношения. На графических иллюстрациях адрес связи изображается стрелкой, направленной от адреса связи данной записи к той записи, начальный адрес (номер) которой служит значением этого адреса связи.
Существуют стандартные соглашения о способах включения и исключения данных в веерном отношении. Способ включения может характеризоваться как автоматический и неавтоматический.
Автоматический способ указывает на то, что при появлении нового значения основного отношения оно сразу же ставится в соответствие некоторому значению зависимого отношения и образует новый элемент веерного отношения. Несоблюдение этого правила характерно для неавтоматического способа.
Способы исключения могут быть обязательными и необязательными. При обязательном способе после того, как значение включено в основное отношение, оно становится его постоянным членом. Его можно обновлять, но нельзя удалять из отношения. Необязательный способ разрешает удалить любое значение основного отношения.
Из аналогии определений веерного отношения и функциональной зависимости следует утверждение: если существует веерное отношение, то ключ зависимого отношения функционально определяет ключ основного отношения, и наоборот, если ключ одного отношения функционально определяет ключ второго отношения, то первое отношение может быть зависимым, а второе – основным в некотором веерном отношении.
В схеме сетевой БД отношения и веерные отношения часто трактуются как файлы и связи, что позволяет рассматривать сетевую структуру как множество файлов
F = {F l (X 1), F 2 (X 2), ..., F i (X i ), ..., F n (X n )},
где X i – атрибуты ключа в файле F i .
Дополнительно вводится граф сетевой структуры В с вершинами {X l , X 2 , ..., X i , ..., X n }. Дуга <X i , X j > в графе В существует, если X i является частью X j и F j [X i ] представляет собой подмножество F i . Последнее условие имеет тот же смысл, что и синтаксическое включение отношений в реляционной модели данных. Здесь предполагается, что ключ основного файла содержится в зависимом файле. Граф В аналогичен графу соединений для реляционной БД.
База данных DBA называется ациклической , если между любыми двумя вершинами на графе В существует не более одного пути. Двухуровневые сети всегда ациклические.
Для множества файлов F ациклической базы данных DBA вполне применима операция
m (DBA ) = F 1 & F 2 & ... & F i & ...& F n ,
называемая максимальным пересечением . Ее аналогом может служить последовательность соединений в реляционной БД.
В сетевых СУБД количество операций выборки достаточно велико. Функции операции проекции для сетевой СУБД выполняет описание подсхемы сетевой базы данных. Схемой сетевой БД называется описание всех отношений с указанием атрибутного состава и ключей каждого отношения, а также веерных отношений. В прикладной программе имеется возможность объявить часть отношений сетевой базы данных, в каждом отношении – некоторое подмножество атрибутов (с обязательным оставлением атрибутов-ключей) и лишь некоторые веерные отношения. Соответствующее описание данных называется подсхемой. Отношения, веерные отношения и атрибуты, не указанные в подсхеме, становятся недоступными прикладной программе. В отличие от операции проекции база данных, соответствующая подсхеме, создается не физически, а путем ограничения доступа к исходной БД, которая определена в схеме.
Результаты допустимых соединений фактически зафиксированы в сетевой СУБД с помощью цепочек адресов связи. Доступ к результатам возможного соединения начинается от некоторого основного отношения к вееру значений в соответствующем зависимом отношении, достигаемые значения ключей в зависимом отношении запоминаются и используются для поиска в каком-либо другом основном отношении; от этого основного отношения возможен переход к новому зависимому и т. д.
Иерархическая модель данных имеет много общих черт с сетевой моделью данных, хронологически она появилась даже раньше . Допустимыми информационными конструкциями в иерархической модели данных выступают отношение, веерное отношение и иерархическая база данных. В отличие от ранее рассмотренных моделей данных, в которых предполагалось, что информационным отображением одной предметной области является одна база данных, в иерархической модели допускается отображение одной предметной области в несколько иерархических баз данных.
Понятия отношения и веерного отношения в иерархической модели данных не изменяются.
Иерархической базой данных называется множество отношений и веерных отношений, для которых соблюдаются два ограничения :
1) существует единственное отношение, называемое корневым, которое не является зависимым ни в одном веерном отношении;
2) все остальные отношения (за исключением корневого) являются зависимыми отношениями только в одном веерном отношении.
Схема иерархической БД по составу компонентов идентична сетевой БД. Названные выше ограничения поддерживаются иерархическими СУБД.
Ограничение, которое поддерживается в иерархической модели данных, состоит в невозможности нарушения требований, фигурирующих в определении иерархической базы данных. Это ограничение обеспечивается специальной укладкой значений отношений в памяти ЭВМ. Ниже мы рассмотрим одну из простейших реализаций укладки иерархической БД.
Необходимо отметить, что существуют различные возможности прохождения иерархически организованных значений в линейной последовательности. Принцип, применяемый для иерархических баз данных, называется концевым прохождением. Перечислим его правила.
1. Начиная с первого значения корневого отношения перечисляются первые значения соответствующих отношений на каждом уровне вплоть до последнего.
2. Перечисляются все значения в том веерном отношении, на котором остановился шаг 1.
3. Перечисляются значения всех вееров этого веерного отношения.
4. От достигнутого уровня происходит подъем на предыдущий уровень, и если возможно применить шаг 1, то процесс повторяется.
Записью иерархической базы данных называется множество значений, содержащее одно значение корневого отношения и все вееры, отходящие от него в соответствии со структурой иерархической базы данных. В нашем примере одну запись образуют данные, относящиеся к одному факультету (см. рис. 11).
Для веерных отношений в составе иерархической базы данных справедлива уже известная закономерность: если существует веерное отношение, то ключ зависимого отношения функционально определяет ключ основного отношения. И наоборот: если ключ одного отношения функционально определяет ключ второго отношения, то первое отношение может быть зависимым, а второе – основным в некотором веерном отношении.
Кроме того, ограничение на существование единственного корневого отношения в иерархической базе данных трансформируется в требование: первичный ключ каждого некорневого отношения должен функционально определять первичный ключ корневого отношения.
Алгоритм получения структуры иерархической БД составлен А.И. Мишениным .
При сравнении моделей данных очень трудно отделить факторы, характеризующие принципиальные особенности модели, от факторов, связанных с реализацией этих моделей данных средствами конкретных СУБД.
Рассматривая преимущества и недостатки самых известных моделей данных, следует отметить ряд несомненных достоинств реляционного подхода:
– простота: в реляционной модели всего одна информационная конструкция, которая формализует табличное представление данных, привычное для пользователей-экономистов;
– теоретическое обоснование: наличие теоретически аргументированных методов нормализации отношений и проверки ацикличности структуры позволяет получать базы данных с требуемыми характеристиками;
– независимость данных: изменение структуры реляционной БД, как правило, приводит к минимальным изменениям в прикладных программах.
Среди недостатков реляционной модели данных необходимо назвать следующие:
– низкую скорость при выполнении операции соединения;
– большой расход памяти для представления реляционной БД. Хотя проектирование в 3НФ рассчитано на минимальную избыточность (каждый факт представляется в БД один раз), другие модели данных при тех же условиях обеспечивают меньший расход памяти. Например, длина адреса связи обычно намного меньше, чем длина значения атрибута.
Достоинствами иерархической модели данных являются:
– простота: хотя модель использует три информационные конструкции, иерархический принцип соподчиненности понятий естественен для многих экономических задач (например, для организации статистической отчетности);
– минимальный расход памяти: для задач, допускающих реализацию с помощью любой из трех моделей данных, иерархическая модель позволяет получить представление с минимально требуемой памятью.
Недостатки иерархической модели:
– неуниверсальность: многие важные варианты взаимосвязи данных невозможно реализовать средствами иерархической модели без повышения избыточности в базе данных;
– допустимость только навигационного принципа доступа к данным;
– доступ к данным производится только через корневое отношение.
Необходимо отметить следующие преимущества сетевой модели данных:
– универсальность: выразительные возможности сетевой модели данных наиболее обширны в сравнении с остальными моделями;
– возможность доступа к данным через значения нескольких отношений (например, через любые основные отношения).
В качестве недостатков сетевой модели данных можно назвать:
– сложность, т. е. обилие понятий, вариантов их взаимосвязей и особенностей реализации;
– допустимость только навигационного принципа доступа к данным.
Результаты, полученные для ациклических баз данных, позволяют говорить о равноценных возможностях представления информации у ациклических реляционных БД, двухуровневых сетевых БД и иерархической БД без логических связей.
При анализе моделей данных не затрагивалась проблема упорядоченности значений в отношениях баз данных. Для реляционной модели эта упорядоченность с теоретической точки зрения необязательна, а в двух других моделях широко используется для повышения эффективности реализации запросов.
На окончательный выбор модели данных влияют многие дополнительные факторы, например, наличие хорошо зарекомендовавших себя СУБД, квалификация прикладных программистов, размер базы данных и др.
В последнее время реляционные СУБД заняли преимущественное положение как средство разработки ЭИС. Недостатки реляционной модели компенсируются ростом быстродействия и ресурсов памяти современных ЭВМ. Вследствие процессов децентрализации управления в экономике многие базы данных ЭИС имеют простую структуру, которая легко трансформируется в понятные системы таблиц (отношений).
Контрольные вопросы и задания
1. Перечислите наиболее известные виды моделей данных.
2. Расскажите об иерархической и сетевой моделях данных. В чем их сходство и различия?
3. Охарактеризуйте реляционную модель.
4. Опишите бинарную модель и область ее применения.
5. Какова специфика семантических сетей и их назначения?
6. Перечислите информационные конструкции для различных технологий.
7. Назовите компоненты реляционной модели данных.
8. Дайте определения кортежа и отношения.
9. Какими способами можно описать процессы обработки отношений?
10. Раскройте сущность процедурного описания процессов обработки данных.
11. Расскажите о декларативном подходе к обработке реляционных баз данных.
12. Что такое нормализация отношений?
13. Сколько атрибутов в простейшей функциональной зависимости?
14. Дайте определение функциональной зависимости атрибутов в терминах реляционного подхода.
15. Что такое вероятный ключ отношения?
16. Что такое первичный ключ? Как по-другому он называется?
17. Расскажите о закономерностях для множества функциональных зависимостей.
18. Охарактеризуйте вторую и третью нормальные формы отношений.
19. Расскажите о доступе к реляционной базе данных.
20. Назовите информационные конструкции в сетевой модели.
21. Что такое «веерное отношение»?
22. Дайте определение двухуровневых сетей.
23. Дайте определение многоуровневых сетей.
24. Что представляет собой «адрес связи»?
25. Что называют «веером»?
26. Какие компоненты содержит схема сетевой БД?
27. Какие стандартные соглашения о способах включения и исключения данных в веерном отношении вам известны?
28. Что такое файлы и связи?
29. Что такое «максимальное пересечение»?
30. Назовите информационные конструкции в иерархической модели.
31. Дайте определение иерархической базы данных.
32. Расскажите о правилах концевого прохождения.
33. Дайте определение записи иерархической базы.
34. Назовите преимущества и недостатки реляционного подхода.
35. Перечислите достоинства и недостатки иерархической модели.
36. Охарактеризуйте сильные и слабые стороны сетевой модели данных.
38. Выполните задания 2.1–2.20 по операциям над отношениями из практикума .
39. Выполните задания 2.21–2.32 по теме «Функциональные зависимости и ключи» из практикума .
40. Выполните задания 2.33–2.60 по теме «Нормальные формы отношений» из практикума .
41. Выполните задания 2.61–2.71 по теме «Ациклические базы данных» из практикума .
42. Выполните задания 2.72–2.93 по теме «Сетевая и иерархическая модели данных» из практикума .
Это БД, основанная на древовидной структуре. По принципу построения она чем-то схожа с файловой системой компьютера. У использования такой модели есть свои достоинства и недостатки, которые будут рассмотрены в этой статье, вместе с подробными примерами.
Как известно, различают четыре вида посторения БД:
Наиболее известным примером иерархической базы данных является продукт, созданный компанией IBM ("АйБиЭм"), под названием Information Management System (переводится как "Информационная система управления"), сокращенно IMS. Первая версия IMS вышла еще в прошлом, двадцатом веке, в шестьдесят восьмом году. Она используется для хранения и контроля данных и поныне.
Иерархическая модель данных строится по следующему принципу:
Иерархическая база данных - это хранилище, применимое для тех систем, которым изначально свойственна древовидная структура. Для них выбирать подобное моделирование - логично.
Пример иерархической базы данных с изначально систематизированными степенями - воинское подразделение, в котором, как известно, четко определены ранги. Также это могут быть сложные механизмы, состоящие из все более упрощающихся к низу иерархии частичек. Для моделирования таких систем и приведения их к виду рассматриваемой БД нет необходимости в декомпозиции. Тем не менее такая ситуация складывается не всегда.
Кроме того, существует тенденция, при которой направленный вниз по структуре запрос проще, чем аналогичный вверх.
Структура иерархической базы данных позволяет успешно и практически беспроблемно (в зависимости от навыков и умений) совершать следующие операции (представлены самые основные, список всегда можно расширить мелкими дополнениями):
Термин "древовидная" для описания структуры упоминается в этой статье уже далеко не единожды. Пора рассказать, откуда он произошел. Все потому что иерархическая база данных - это такая БД, которая использует тип данных "дерево". Рассмотрим подробнее, что он из себя представляет.
Это составной тип: в каждый из элементов (узлов) вкладывается несколько последующих (один или более). А начинается все с одного корневого элемента. Суть в том, что каждый из кусочков типа "дерево", является подтипом, тоже "деревом". Много-много разветвленных, и все также упорядоченных структур.
Элементарные типы могут быть простыми и составными, но по существу это всегда записи. Но в простом записи присутствует один а в составном - целая их совокупность.
Иерархической модели свойственен принцип потомков, когда каждый предыдущий сегмент является предком для последующего. Кроме того, потомок по отношению к вышестоящему типу является типом подчиненным, в то время как равнозначные один другому записи считаются близнецами.
Основными данными иерархической БД являются значения (числа или символы), которые хранятся в записях. Обходят такую базу данных обычно снизу вверх и слева направо.
Иерархическая база данных - это имеющая корневую папку БД, постепенно разветвляющаяся книзу. Учитывая, что подобная структура весьма схожа с файловой системой, такие базы успешно применяются для выполнения различных операций над данными ЭВМ. Итог: рациональное распределение ее памяти, а также весьма достойные показатели времени, затраченного на работу.
Иерархическая модель идеальна для применения ее для упорядоченной информации.
Однако те же особенности рассматриваемых СУБД, которые стали их основными достоинствами, определяют также и их недостатки. К примеру, громоздкость и сложность логических связей - опытному специалисту при работе с ранее неизвестной базой будет трудно разобраться, а простой пользователь и вовсе в ней "заблудится". Эта сложность понимания приводит к тому, что на самом деле не так много СУБД построены на иерархической модели. Примером иерархической базы данных является, кроме уже описанного продукта компании "АйБиЭм", "Ока" и МИРИС (производство России), а также Data Edge и Team-UP (от зарубежных корпораций).
Иерархическая база данных - это многообразие различных уровней, на которых строятся взаимосвязи. Схематично она выглядит как перевернутый граф. Пример иерархической базы данных - любое государственное административное учреждение. Взять, допустим, школу.
На самом верхней уровне будет располагаться "лидер" администрации - директор. В его подчинении завучи, у завучей - преподаватели, который руководят параллелями классов. В каждой параллели энное их количество, а в каждом классе есть некоторое число учеников.
По такому же принципу можно расписать и управление какой-нибудь корпорацией. Глава компании или даже совет директоров на самом верху. Далее - все большее количество подразделений, в каждом из которых действует своя структура. Есть и общие черты: начальник в каждом отделе, его помощник, его секретарь, собственно, офисные сотрудники и так далее.
Могут быть и более серьезные области применения. Яркий пример иерархической базы данных- это файловая система. Всем привычный "Проводник" строится в самом ядре операционной системы "Виндоус" именно по такой схеме, так же, как и многие другие файловые менеджеры.
Существуют:
Почему мы вновь вспомнили о классификации? Поскольку, в отличие от реляционной, сетевая БД имеет с иерархической схожие черты.
Время вспомнить в базах данных. Есть связи "один-к-одному", "один-ко-многим" и "многие-ко-многим". Нас интересует последняя. В сетевой БД она проявляется следующим образом: у одного узла-наследника может быть сразу несколько предков. Свойство иметь несколько потомков также сохраняется. Можно сказать, что иерархические базы данных, сетевые базы данных сами по себе уже пример такого наследования. Предком в данном случае является именно иерархическая БД, так как принцип построения структуры в сетевых БД остается прежним.
Название "реляционная" произошло от английского слова "отношение". Как уже упоминалось в начале статьи, они часто выражаются таблично. Но в предыдущем пункте мы указали, что иерархическая БД также может организовывать связи, значит ли это, что и между этими двумя типами есть некая объединяющая их тонкая ниточка?
Да. Помимо того, что и первый, и второй вид все еще относятся к базам данных, кроме этого признака есть еще одно общее свойство. Например, иерархическую БД (и сетевую заодно с ней) можно выразить в таблице. Суть здесь не в том, в каком виде представить информацию конечному пользователю (это уже вопрос юзабилити интерфейса), но по какому принципу была структурирована информация. Так, четкое деление на отделы со своими начальниками, подразделениями и прочим по-прежнему будет выражено в иерархии, но для удобства занесено в таблицу.
Иерархические базы данных имеют форму деревьев с дугами-связями и узлами-элементами данных. Иерархическая структура предполагала неравноправие между данными - одни жестко подчинены другим. Подобные структуры, безусловно, четко удовлетворяют требованиям многих, но далеко не всех реальных задач.2. Сетевая модель данных. В сетевых БД наряду с вертикальными реализованы и горизонтальные связи. Однако унаследованы многие недостатки иерархической и главный из них, необходимость четко определять на физическом уровне связи данных и столь же четко следовать этой структуре связей при запросах к базе.
3. Реляционная модель. Реляционная модель появилась вследствие стремления сделать базу данных как можно более гибкой. Данная модель предоставила простой и эффективный механизм поддержания связей данных.
Во-первых , все данные в модели представляются в виде таблиц и только таблиц. Реляционная модель - единственная из всех обеспечивает единообразие представления данных. И сущности, и связи этих самых сущностей представляются в модели совершенно одинаково - таблицами . Правда, такой подход усложняет понимание смысла хранящейся в базе данных информации, и, как следствие, манипулирование этой информацией.
Избежать трудностей манипулирования позволяет второй элемент модели - реляционно-полный язык (отметим, что язык является неотъемлемой частью любой модели данных, без него модель не существует). Полнота языка в приложении к реляционной модели означает, что он должен выполнять любую операцию реляционной алгебры или реляционного исчисления ( полнота последних доказана математически Э.Ф. Коддом). Более того, язык должен описывать любой запрос в виде операций с таблицами, а не с их строками. Одним из таких языков является SQL .
Третий элемент реляционной модели требует от реляционной модели поддержания некоторых ограничений целостности . Одно из таких ограничений утверждает, что каждая строка в таблице должна иметь некий уникальный идентификатор , называемый первичным ключом. Второе ограничение накладывается на целостность ссылок между таблицами. Оно утверждает, что атрибуты таблицы, ссылающиеся на первичные ключи других таблиц, должны иметь одно из значений этих первичных ключей.
4. Объектно-ориентированная модель. Новые области использования вычислительной техники, такие как научные исследования, автоматизированное проектирование и автоматизация учреждений, потребовали от баз данных способности хранить и обрабатывать новые объекты - текст, аудио- и видеоинформацию, а также документы. Основные трудности объектно-ориентированного моделирования данных проистекают из того, что такого развитого математического аппарата, на который могла бы опираться общая , не существует. В большой степени, поэтому до сих пор нет базовой объектно-ориентированной модели. С другой стороны, некоторые авторы утверждают, что общая объектно-ориентированная модель данных в классическом смысле и не может быть определена по причине непригодности классического понятия модели данных к парадигме объектной ориентированности. Несмотря на преимущества объектно-ориентированных систем - реализация сложных типов данных , связь с языками программирования и т.п. - на ближайшее время превосходство реляционных СУБД гарантировано.
Рассмотрим более подробно эти модели данных далее.
Иерархические базы данных - самая ранняя модель представления сложной структуры данных. Информация в иерархической базе организована по принципу древовидной структуры, в виде отношений "предок- потомок ". Каждая запись может иметь не более одной родительской записи и несколько подчиненных. Связи записей реализуются в виде физических указателей с одной записи на другую. Основной недостаток иерархической структуры базы данных - невозможность реализовать отношения " многие-ко-многим ", а также ситуации, когда запись имеет несколько предков.
Иерархические базы данных . Иерархические базы данных графически могут быть представлены как перевернутое дерево , состоящее из объектов различных уровней. Верхний уровень ( корень дерева ) занимает один объект , второй - объекты второго уровня и так далее.
Между объектами существуют связи, каждый объект может включать в себя несколько объектов более низкого уровня. Такие объекты находятся в отношении предка ( объект , более близкий к корню) к потомку ( объект более низкого уровня), при этом объект -предок может не иметь потомков или иметь их несколько, тогда как объект - потомок обязательно имеет только одного предка. Объекты, имеющие общего предка, называются близнецами.
Иерархической базой данных является Каталог папок Windows , с которым можно работать, запустив Проводник. Верхний уровень занимает папка Рабочий стол . На втором уровне находятся папки Мой компьютер , Мои документы, Сетевое окружение и Корзина , которые являются потомками папки Рабочий стол , а между собой является близнецами. В свою очередь , папка Мой компьютер является предком по отношению к папкам третьего уровня -папкам дисков ( Диск 3,5(А:), (С:), (D:), (Е:), (F:)) и системным папкам ( сканер , bluetooth и.т.д.) - на рис. 4.1 .
Рис.
4.1.
Организация данных в СУБД иерархического типа определяется в терминах: элемент, агрегат, запись ( группа ), групповое отношение , база данных .
Атрибут (элемент данных) | - наименьшая единица структуры данных. Обычно каждому элементу при описании базы данных присваивается уникальное имя. По этому имени к нему обращаются при обработке. Элемент данных также часто называют полем. |
Запись | - именованная совокупность атрибутов. Использование записей позволяет за одно обращение к базе получить некоторую логически связанную совокупность данных. Именно записи изменяются, добавляются и удаляются. Тип записи определяется составом ее атрибутов. Экземпляр записи - конкретная запись с конкретным значением элементов. |
Групповое отношение | - иерархическое отношение между записями двух типов. Родительская запись (владелец группового отношения) называется исходной записью, а дочерние записи (члены группового отношения) - подчиненными. Иерархическая база данных может хранить только такие древовидные структуры. |
Корневая запись каждого дерева обязательно должна содержать ключ с уникальным значением. Ключи некорневых записей должны иметь уникальное значение только в рамках группового отношения. Каждая запись идентифицируется полным сцепленным ключом, под которым понимается совокупность ключей всех записей от корневой, по иерархическому пути.
При графическом изображении групповые отношения изображают дугами ориентированного графа, а типы записей - вершинами ( диаграмма Бахмана).
Для групповых отношений в иерархической модели обеспечивается автоматический режим включения и фиксированное членство. Это означает, что для запоминания любой некорневой записи в БД должна существовать ее родительская запись .
Рассмотрим следующую модель данных предприятия (см. рис. 4.2): предприятие состоит из отделов, в которых работают сотрудники. В каждом отделе может работать несколько сотрудников, но сотрудник не может работать более чем в одном отделе.
Поэтому, для информационной системы управления персоналом необходимо создать групповое отношение, состоящее из родительской записи ОТДЕЛ (НАИМЕНОВАНИЕ_ОТДЕЛА, ЧИСЛО_РАБОТНИКОВ) и дочерней записи СОТРУДНИК (ФАМИЛИЯ, ДОЛЖНОСТЬ, ОКЛАД). Это отношение показано на рис. 4.2 (а) (Для простоты полагается, что имеются только две дочерние записи).
Для автоматизации учета контрактов с заказчиками необходимо создание еще одной иерархической структуры: заказчик - контракты с ним - сотрудники, задействованные в работе над контрактом. Это дерево будет включать записи ЗАКАЗЧИК (НАИМЕНОВАНИЕ_ЗАКАЗЧИКА, АДРЕС), КОНТРАКТ(НОМЕР, ДАТА,СУММА), ИСПОЛНИТЕЛЬ (ФАМИЛИЯ, ДОЛЖНОСТЬ, НАИМЕНОВАНИЕ_ОТДЕЛА) (