Ядром любой базы данных является модель данных.Модель данных – совокупность структур данных и операций их обработки.
По способу установления связей между данными различаютиерархическую, сетевую и реляционную модели.
Иерархическая модель позволяет строить базы данных с древовидной структурой. В них каждый узел содержит свой тип данных (сущность). На верхнем уровне дерева в этой модели имеется один узел – «корень», на следующем уровне располагаются узлы, связанные с этим корнем, затем узлы, связанные с узлами предыдущего уровня и т. д., причем каждый узел может иметь только одного предка (рис. 1.).
Рисунок 1 Схема иерархической модели данных
Поиск данных в иерархической системе всегда начинается с корня. Затем производится спуск с одного уровня на другой пока не будет достигнут искомый уровень. Перемещения по системе от одной записи к другой осуществляются с помощью ссылок.
Основные достоинства иерархической модели – простота описания иерархических структур реального мира и быстрое выполнение запросов, соответствующих структуре данных, однако, они часто содержат избыточные данные. Кроме того, не всегда удобно каждый раз начинать поиск нужных данных с корня, а другого способа перемещения по базе в иерархических структурах нет.
Указанный недостаток снят всетевой модели, где, теоретически возможны связи «всех информационных объектов со всеми» (рис. 2). Пример – учебное заведение, где каждый преподаватель может обучать много (теоретически всех) студентов, и каждый студент может обучаться у многих (теоретически всех) преподавателей.
Использованиеиерархической и сетевой моделей ускоряет доступ к информации в базе данных. Но поскольку каждый элемент данных должен содержать ссылки на некоторые другие элементы,
Рисунок 2 Сетевая структура модели данных
требуются значительные ресурсы как дисковой, так и основной памяти ЭВМ. Недостаток основной памяти, конечно, снижает скорость обработки данных. Кроме того, для таких моделей характерна сложность реализации системы управления базами данных (СУБД).
Реляционная модель . Модель опирается на систему понятийреляционной алгебры, важнейшие из которых: таблица, строка, столбец, отношение и первичный ключ, а все операции сводятся к манипуляциям с таблицами.
В реляционной модели информация представляется в виде прямоугольных таблиц. Каждая таблица состоит из строк и столбцов и имеет имя, уникальное внутри базы данных.
Таблица отражает объект реального мира – сущность, а каждая ее строка (запись) отражает один конкретный экземпляр объекта – экземпляр сущности. Каждый столбец таблицы имеет уникальное для своей таблицы имя. Столбцы расположены в таблице в соответствии с порядком следования их имен при ее создании.
В отличие от столбцов строки не имеют имен, порядок их следования в таблице не определен, а количество логически не ограничено. Так как строки в таблице не упорядочены, невозможно выбрать строку по ее позиции. Хотя в файле у каждой строки имеется номер, он не характеризует строку. Его значение изменяется при удалении строк из таблицы. Логически среди строк не существует «первой» и «последней».
В каждой таблице реляционной модели должен быть столбец или совокупность столбцов, значения которых однозначно идентифицируют каждую строку таблицы. Этот столбец или их совокупность и называетсяпервичным ключом таблицы (рис. 3).
Если таблица удовлетворяет требованию уникальности первичного ключа, она называетсяотношением. В реляционной модели все таблицы должны быть преобразованы в отношения. Отношения реляционной модели связаны между собой. Связи поддерживаются внешними ключами.Внешний ключ – это столбец (совокупность столбцов), значение которого однозначно характеризует значение первичного ключа другого отношения (таблицы).
Введение. Основные понятия баз данных
Базы данных (БД) используются в различных областях и сферах человеческой деятельности. Например, могут существовать БД, несущие информацию о клиентах, товарах, предоставляемых услугах, коммерческих операциях и т.п. В специализированной литературе предлагается множество определений баз данных, которые отражают те или иные аспекты субъективного мнения различных авторов. Мы будем понимать под базой данных совокупность объектов (товаров, клиентов, расчетов) представленных, таким образом, чтобы обеспечивалась возможность их поиска и обработки с помощью компьютера. Средства управления этими данными называются системами управления базами данных (СУБД ).
История развития систем управления базами данных (СУБД) насчитывает десятки лет. Первая промышленная СУБД фирмы IBM была введена в эксплуатацию в 1968 году, а в 1975 году появился первый стандарт, который определил ряд основных понятий в теории систем баз данных.
Развитие вычислительной техники, появление персональных компьютеров, мощных рабочих станций и компьютерных сетей обусловило развитие технологии баз данных. Компьютеры стали инструментом для ведения документации, что заставляло разработчиков программного обеспечения создавать системы, которые принято называть настольными СУБД.
С появлением локальных сетей информация передается между компьютерами, поэтому возникла задача согласования данных, хранящихся и обрабатывающихся в разных местах, но связанных логически. Решение этой задачи привело к появлению распределенных баз данных, позволяющих организовать параллельную обработку информации и сохранять целостность баз данных.
Для распределенного хранения данных и доступа к базе компьютеры объединяют в локальные, региональные и даже глобальные сети. В настоящее время широко используется технология клиент-сервер для построения сетей. Система клиент-сервер - это обычная локальная вычислительная сеть, которая содержит группу компьютеров-клиентов и один специальный компьютер – сервер. Компьютеры-клиенты обращаются к серверу за различными услугами. Компьютер-сервер может пересылать им различные программы, например, обработку текстов, работы с таблицами, выполнение запросов к базе данных и возвращать результаты. Основная идея состоит в том, что каждый компьютер выполняет то, что он делает наиболее эффективно. Сервер извлекает и обновляет данные, клиент выполняет специальные расчеты и предоставляет результаты конечному пользователю. Вначале серверы выполняли простейшие функции: серверы печати, файловые серверы, по запросу клиента на доступ к какому-нибудь файлу сервер пересылал данный файл компьютеру-клиенту. Сервер базы данных – это программа, которая запускается на компьютере-сервере и обслуживает доступ клиентов к базе данных. Таким образом, в основе системы клиент-сервер лежит принцип разделения труда. Клиент - это компьютер, с которым работает пользователь, а компьютер-сервер выполняет обслуживание группы клиентов: доступ к базе данных, обновление базы данных и т.п. Прогрессивным путем коллективного доступа к базам данных в последние 20 лет является использование всемирной сети Интернет с группой ее служб.
Примерами серверов могут служить:
Сервер телекоммуникаций, обеспечивающий сервис по связи локальной сети с другими сетями и серверами;
Вычислительный сервер, дающий возможность производить вычисления, которые невозможно выполнить на рабочих станциях;
Дисковый сервер, обладающий расширенными ресурсами внешней памяти и предоставляющий их в использование компьютерам-клиентам и, возможно, другим серверам;
Файловый сервер, поддерживающий общее хранение файлов для всех рабочих станций;
Сервер баз данных - фактически обычная СУБД, принимающая и обслуживающая запросы по локальной сети.
Хотя обычно одна база данных целиком хранится в одном узле сети и поддерживается одним сервером, серверы баз данных представляют собой простое и дешевое приближение к распределенным базам данных, поскольку общая база данных доступна для всех пользователей локальной сети.
Доступ к базе данных от прикладной программы или пользователя производится путем обращения к клиентской части системы. В качестве основного интерфейса между клиентской и серверной частями выступает язык баз данных SQL. Собирательное название SQL-сервер относится ко всем серверам баз данных, основанных на SQL. Соблюдая предосторожности при программировании, можно создавать прикладные информационные системы, мобильные в классе SQL-серверов.
Одним из перспективных направлений СУБД является гибкое конфигурирование системы, при котором распределение функций между клиентской и пользовательской частями СУБД определяется при установке системы.
СУБД должны обеспечивать логическую целостность данных. Логическая целостностьбазы данных должна подразумевать поддержание непротиворечивой и полной информации, адекватно отражающей предметную область.
С требованием логической целостности данных связано понятие транзакции. Транзакция – группа логически объединённых последовательных операций по работе с данными, обрабатываемая или отменяемая целиком. Например, если оформлять заказ на определенный товар нужно выполнить ряд операций: регистрация заявки на товар, резервирование товара, уменьшение этого товара на складе. При нарушении на любом из этапов произойдет сбой, и логическая целостность БД будет нарушена. С целью предотвращения подобных случаев вводится транзакция «Оформление заказа», в которой над БД либо должны произвестись все необходимые операции, т.е. товар продается, количество его на складе уменьшается, либо происходит возврат к исходному состоянию (товар не продан и его количество на складе осталось прежним).
СУБД осуществляют взаимодействие между БД и пользователями системы, а также между БД и прикладными программами, реализующими определенные функции обработки данных.
СУБД обеспечивают надежное хранение больших объемов данных сложной структуры во внешней памяти компьютера и эффективный доступ к ним. К основным функциям СУБД относятся:
· определение данных - определяется информация, которая должна храниться в базе данных, задается структура данных, их тип, а также указывается то, как данные будут связаны между собой;
· обработка данных - данные можно обрабатывать различными способами: выбирать любые поля, фильтровать и сортировать данные, объединять данные и вычислять итоговые значения;
· управление данными - определяются правила доступа к данным, их изменение и добавление новых данных, задаются правила коллективного пользования данными.
Иерархическая модель данных
Первые иерархические модели данных появились в конце 50-х годов. Они представляли собой древовидную структуру, где данные были распределенные по уровням от главного к подчиненному и представляли собой неориентированный граф. Пример иерархической модели данных приведен на рис. 1.
Рис 1. Иерархическая модель данных
Модель характеризуется количеством уровней и узлов. Каждый уровень представляет собой один или несколько объектов (данных) и может иметь несколько узлов подчиненных уровней, причем связи между всеми объектам жестко закреплены и один потомок может иметь не более одного предка. Основные типы структур данных рассматриваемой модели – поле, запись, файл. Запись является основной структурной единицей обработки данных и единицей обмена между оперативной и внешней памятью. В модели на основе записей база данных состоит из записей фиксированного формата, которые могут быть разного типа. Каждый тип записи определяет фиксированное количество полей, каждое из которых имеет фиксированную длину.
Поле – это элементарная единица логической организации данных, которая соответствует отдельной, неделимой единице информации – реквизиту.
Запись – это совокупность полей, соответствующих логически связанным реквизитам. Структура записи определяется составом и последовательностью входящих в нее полей, каждое из которых содержит элементарное данное.
Файл – это множество одинаковых по структуре записей со значениями в отдельных полях, причем поля имеют единственное значение.
Типичным представителем (наиболее известным и распространенным) является СУБД IMS (Information Management System) компании IBM. Первая версия системы появилась в 1968 г.
2.2.2. Сетевая модель данных
Под сетевой моделью понимается модель данных, подобная иерархической, но допускающая свободную систему связей между узлами различных уровней. Она является расширением иерархической модели данных. Таким образом, сетевые модели допускают наличие двух и более «предков» (рис.2).
В отличие от иерархической модели, у потомка сетевой модели может быть более одного предка и один объект может быть одновременно главным и подчиненным. Таким образом, в данной модели отношения между данными такие, что каждая запись может быть подчинена записям более, чем из одного файла. В сетевых моделях можно по ключу иметь непосредственный доступ к любому объекту независимо от уровня, на котором он находится в модели.
К достоинству сетевой модели можно отнести эффективность реализации по степени затрат памяти и быстроты доступа. Недостатком является повышенная сложность схемы данных, построенной на её основе.
Рис. 2. Сетевая модель данных
Типичным представителем систем, основанных на сетевой модели данных, является СУБД IDMS (Integrated Database Management System), разработанная компанией Cullinet Software, Inc. и изначально ориентированная на использование мэйнфреймов (ЭВМ общего назначения) компании IBM. Архитектура системы основана на предложениях Data Base Task Group (DBTG) организации CODASYL (Conference on Data Systems Languages), которая отвечала за определение языка программирования COBOL. Отчет DBTG был опубликован в 1971 г., и вскоре после этого появилось несколько систем, поддерживающих архитектуру CODASYL, среди которых присутствовала и СУБД IDMS. В настоящее время IDMS принадлежит компании Computer Associates.
Нормализация базы данных
При проектировании баз данных наиболее важным является определение структур таблиц и связей между ними. Ошибки в структуре данных трудно, а чаще вообще невозможно исправить программным путем. Чем лучше структура данных, тем легче программировать БД. Теория проектирования БД содержит концепцию нормальных форм, предназначенных для оптимизации структуры БД. Нормальные формы - это линейная последовательность правил, применяемых к БД, причем, чем выше номер нормальной формы, тем совершеннее структура БД. Нормализация - это многоступенчатый процесс, при котором таблицы БД организуются, разъединяются и данные приводятся в порядок. Задача нормализации - устранить из БД некоторые нежелательные характеристики. В частности, ставится задача устранить некоторые виды избыточности данных и благодаря этому избежать аномалий при изменении данных. Аномалии изменения данных - это сложности при операциях вставки, изменения и удаления данных, возникающие из-за структуры БД. Хотя существует много уровней, обычно достаточно выполнить нормализацию до Третьей нормальной формы.
Рассмотрим пример нормализации БД управления доставкой заказов. Неупорядоченная БД «Продажи» состояла бы из одной таблицы (рис.7).
Рис.7. БД «Продажи»
В таблице каждая запись содержит сведения о нескольких заказах одного клиента. Поскольку столбец со сведениями о товаре содержит слишком много данных, получить упорядоченную информацию из этой таблицы сложно (например, составить отчет о суммарных закупках по различным видам товаров).
Первая нормальная форма
Первая нормальная форма предопределяет атомарность всех данных, содержащихся в столбцах. Слово "атом" происходит от латинского "atomis", что буквально означает "не подлежащий разделению". Первая нормальная форма задает существование в каждой позиции, определяемой строкой и столбцом, только одного значения, а не массива или списка значений. Преимущества этого требования очевидны: если в одном столбце хранятся списки значений, то не существует простого способа манипулировать этими значениями. Конечно, при этом увеличивается количество записей в таблице.
Выполним нормализацию БД " Продажи" до первой нормальной формы (рис.8).
Рис.8. Первая нормальная форма
3.3.2. Вторая нормальная форма
Ко Второй нормальной форме можно перейти от таблицы, которая уже соответствует первой нормальной форме. Дополнительно должно выполняться следующее условие: каждое не ключевое поле должно полностью зависеть от первичного ключа.
Выполним нормализацию БД " Продажи" до второй нормальной формы. Все сведения, не связанные с отдельными заказами, выделим в отдельную таблицу. В итоге получим вместо одной таблицы " Продажи" получим две - таблицу "Заказы" (рис.9) и таблицу "Товары" (рис.10).
Рис.9. Таблица "Заказы"
Рис.10. Таблица "Товары"
Таким образом, вид товара хранится только в одной таблице. Следует обратить внимание, что при нормализации информация не теряется.
3.3.3. Третья нормальная форма
Считается, что таблица соответствует Третьей нормальной форме, если она соответствует второй нормальной форме и все не ключевые столбцы взаимно независимы. Столбец, значения которого получаются вычислением на основе данных из других столбцов, представляет собой один из примеров зависимости.
Выполним нормализацию БД "Продажи" до третьей нормальной формы. Для этого следует удалить из таблицы "Заказы" столбец "Всего". Значения в этом столбце не зависят ни от одного ключа и могут быть вычислены по формуле ("Цена")*("Количество"). Таким образом, получена БД "Продажи" с оптимальной структурой, которая состоит из двух таблиц (рис.11).
Рис. 11. Нормализованная БД "Продажи"
3.2 Программная реализация базы данных
Программная реализация базы данных осуществляется посредством создания целевой СУБД на языке определения данных (DDL). Команды DDL-языка компилируются и используются для создания схем и пустых файлов базы данных. На этом же этапе определяются и все специфические пользовательские представления.
Прикладные программы реализуются с помощью языков третьего или четвертого поколения. Некоторые элементы этих прикладных программ будут представлять собой транзакции обработки базы данных, записываемые на языке манипулирования данными (DML) целевой СУБД и вызываемые из программ на базовом языке программирования - например, на Visual Basic, С++, Java. Кроме того, на этом этапе создаются другие компоненты проекта приложения - например, экраны меню, формы ввода данных и отчеты. Следует учитывать, что многие существующие СУБД имеют свои собственные инструменты разработки, позволяющие быстро создавать приложения с помощью непроцедурных языков запросов, разнообразных генераторов отчетов, генераторов форм, генераторов графических изображений и генераторов приложений.
На этом этапе также реализуются используемые приложением средства защиты базы данных и поддержки ее целостности. Одни из них описываются с помощью языка DDL, а другие, возможно, потребуется определить иными средствами - например, с помощью дополнительных утилит СУБД или посредством создания прикладных программ, реализующих требуемые функции.
3.2.1. Разработка приложений
Разработка приложений – это проектирование интерфейса пользователя и прикладных программ, предназначенных для работы с базой данных. В большинстве случаев проектирование приложений нельзя завершить до окончания проектирования базы данных. С другой стороны, база данных предназначена для поддержки приложений, а потому между фазами проектирования базы данных и проектирования приложений для этой базы данных должен постоянно происходить обмен информацией.
Необходимо убедиться, что все функциональные возможности, предусмотренные в спецификациях требований пользователей, обеспечиваются интерфейсом пользователя соответствующих приложений. Это относится как к проектированию прикладных программ доступа к информации в базе данных, так и к проектированию транзакций, т.е. проектированию методов доступа к базе данных.
Помимо проектирования способов, с помощью которых пользователь сможет получить доступ к необходимым ему функциональным возможностям, следует также разработать соответствующий пользовательский интерфейс приложений базы данных. Этот интерфейс должен предоставлять необходимую пользователю информацию самым удобным для него образом.
3.2.2 Тестирование базы данных
Тестирование - процесс выполнения прикладных программ с целью поиска ошибок. Прежде чем использовать новую систему на практике, ее следует тщательно проверить. Этого можно добиться путем разработки продуманного алгоритма тестирования с использованием реальных данных, который должен быть построен таким образом, чтобы весь процесс тестирования выполнялся строго последовательно и методически правильно. Задачей тестирования не является процесс демонстрации отсутствия ошибок, оно вряд ли сможет продемонстрировать отсутствие ошибок в программном обеспечении - скорее, наоборот, оно способно лишь показать их наличие. Если тестирование проведено успешно, то обязательно вскроются имеющиеся в прикладных программах и структурах базы данных ошибки. В качестве побочного результата тестирование может лишь показать, что база данных и прикладные программы работают в соответствии с их спецификациями и удовлетворяют при этом существующим требованиям, предъявляемым к производительности. Кроме того, сбор статистических данных на стадии тестирования позволяет установить показатели надежности и качества созданного программного обеспечения.
Как и при проектировании баз данных, пользователи новой системы должны быть вовлечены в процесс ее тестирования. В идеале, тестирование системы должно проводиться на отдельном комплекте оборудования, но зачастую это просто невозможно. При использовании реальных данных важно предварительно создать их резервные копии, на случай их повреждения в результате ошибок. По завершении тестирования процесс создания прикладной системы считается законченным, и она может быть передана в промышленную эксплуатацию.
3.3 Эксплуатация и сопровождение базы данных
Эксплуатация и сопровождение - поддержка нормального функционирования БД.
На предыдущих этапах приложение базы данных было полностью реализовано и протестировано. Теперь система входит в последний этап своего жизненного цикла, называемый эксплуатацией и сопровождением. Он включает выполнение таких действий, как:
· контроль производительности системы. Если производительность падает ниже приемлемого уровня, то может потребоваться дополнительная реорганизация базы данных;
· сопровождение и модернизация (в случае необходимости) приложений баз данных. Новые требования включаются в приложение базы данных при повторном выполнении предыдущих этапов жизненного цикла.
Как только база данных будет введена в эксплуатации, следует постоянно контролировать процесс ее функционирования - это позволит убедиться, что производительность и другие показатели соответствуют предъявляемым требованиям. Типичная СУБД обычно предоставляет различные утилиты администрирования базы данных, включая утилиты загрузки данных и контроля за функционированием системы. Подобные утилиты способны отслеживать работу системы и предоставлять информацию о различных показателях, таких как уровень использования базы данных, эффективность системы блокировок (включая сведения о количестве имевших место взаимных блокировок), а также выбираемые стратегии выполнения запросов. Администратор базы данных может использовать эту информацию для настройки системы с целью повышения ее производительности (например, за счет создания дополнительных индексов), ускорения выполнения запросов, изменения структур хранения, объединения или разбиения отдельных таблиц.
Процесс мониторинга должен поддерживаться на протяжении всего процесса эксплуатации приложений, что позволит в любой момент времени провести эффективную реорганизацию базы данных с целью удовлетворения изменяющихся требований. Подобные изменения предоставляют информацию о наиболее вероятном совершенствовании БД и ресурсах, которые могут потребоваться в будущем. Если в используемой СУБД нет некоторых нужных утилит, то администратору придется либо разработать их самостоятельно, либо приобрести требуемые дополнительные инструменты у сторонних разработчиков.
4. СУБД Microsoft Access
4.1.Назначение и общие сведения о СУБД Microsoft Access
Система Microsoft Access является системой управления БД, использует реляционную модель данных и входит в состав пакета прикладных программ Microsoft Office. Она предназначена для хранения, ввода, поиска и редактирования данных, а также выдачи их в удобном виде.
К областям применения Microsoft Access можно отнести следующие:
· в малом бизнесе (бухгалтерский учет, ввод заказов, ведение информации о клиентах, ведение информации о деловых контактах);
· в крупных корпорациях (приложения для рабочих групп, системы обработки информации);
· в качестве персональной СУБД (справочник по адресам, ведение инвестиционного портфеля, поваренная книга, каталоги книг, пластинок, видеофильмов и т. п.).
Access является одной из самых мощных, удобных и простых систем управления базами данных. Поскольку Access входит в состав Microsoft Office, она обладает многими чертами, характерными для приложений Office, и может обмениваться с ними информацией. Например, работая в Access, можно открывать и редактировать файлы, а также использовать буфер обмена для копирования данных из других приложений.
Средствами разработки объектов в Access являются «мастера» и «конструкторы». Это специальные программы, которые служат для создания и редактирования таблиц, запросов, различных типов форм и отчетов. Как правило «мастер» используется для создания, а «конструктор» - для редактирования объектов. Процесс редактирования предполагает изменение вида некоторого объекта с целью его улучшения. При редактировании формы можно изменить названия и порядок расположения полей, увеличить или уменьшить размер области ввода данных, и т.д. Можно использовать «конструктор» и для создания форм, но это очень трудоемкая работа. В Access включены специальные программные средства, помогающие производить анализ структуры данных, импортировать электронные таблицы и текстовые данные, повышать быстродействие приложений, создавать и настраивать приложения с использованием встроенных шаблонов. Чтобы полностью автоматизировать работу приложений, можно использовать макросы для связывания данных с формами и отчетами.
В Access реализовано управление реляционными базами данных. Система поддерживает первичные и внешние ключи. Обеспечивает целостность данных на уровне ядра, что не разрешает несовместимые операции обновления или удаления данных. Таблицы в Access снабжены средствами проверки допустимости данных, т.е. не разрешается некорректный ввод. Каждое поле таблицы имеет свой формат и стандартные описания, что облегчает ввод данных. Access поддерживает следующие типы полей, в том числе: вкладка, текстовый, числовой, счетчик, денежный, дата/время, MEMO, логический, гиперссылка, поля объектов OLE, вложение и вычисляемый. Если в полях не оказывается никаких значений, система обеспечивает полную поддержку пустых значений.
В Access можно использовать графические средства, как и в Microsoft Word, Excel, PowerPoint и других приложениях, позволяющие создавать различные виды графиков и диаграмм. Можно создавать гистограммы, двухмерные и трехмерные диаграммы. В формы и отчеты Access можно добавлять всевозможные объекты: рисунки, диаграммы, аудио- и видеоклипы. Связывая эти объекты с разработанной базой данных, можно создавать динамические формы и отчеты. Также в Access можно использовать макросы, позволяющие автоматизировать выполнение некоторых задач. Они позволяют открывать и закрывать формы и отчеты, создавать меню и диалоговые окна с целью автоматизации создания различных прикладных задач.
В Access можно получить контекстно-зависимую справку, для получения которой надо нажать
4.2. Объекты Microsoft Access
При запуске СУБД Access появляется окно для создания новой базы данных или для работы с ранее созданными БД, или уже имеющимися шаблонами (рис.12).
Рис. 12. Запуск Access
Шаблоны представляют собой пустые структуры баз данных, в которых определены типы полей, созданы основные объекты, осуществлена связь между таблицами и т.п.
При создании новой базы данных Access откроет пустую таблицу, содержащую одну строку и два столбца (рис 13).
Рис.13. Окно новой базы данных
В левой части окна (область переходов) показаны все созданные объекты БД, пока мы лишь видим, пустую таблицу, т.к. созданных объектов в новой базе данных больше нет (рис. 13). К основным объектам СУБД Access относятся следующие.
Таблицы . Таблицы являются основными объектами баз данных, так как в них хранятся все данные, и они определяют структуру базы данных. База данных может содержать тысячи таблиц, размеры которых ограничиваются только доступным пространством на жестком диске компьютера. Количество записей в таблицах определяется объемом жесткого диска, а количество полей не более 255.
Таблицы в Access могут быть созданы следующим образом:
· в режиме «конструктора»;
· в режиме ввода данных в таблицу.
Создать таблицу можно путем импорта данных, хранящихся в другом месте, или создания связи с ними. Это можно сделать, например, с данными, хранящимися в файле Excel, в списке Windows SharePoint Services, XML-файле, другой базе данных MS ACCESS. Список SharePoint позволяет предоставить доступ к данным пользователям, у которых не установлено приложение MS ACCESS. При импорте данных создается их копия в новой таблице текущей базы данных. Последующие изменения, вносимые в исходные данные, не будут влиять на импортированные данные, и наоборот. Если осуществляется связывание с данными, в текущей базе данных создается связанная таблица, обеспечивающая динамическое подключение к данным, хранящимся в другом месте. Изменения данных в связанной таблице отражаются в источнике, а изменения в источнике - в связанной таблице.
В режиме таблицы отображаются данные, которые хранятся в таблице, а в режиме «конструктора» отображается структура таблицы.
Если таблицы имеют общие поля, можно воспользоваться подчиненной таблицей, чтобы вставить в одну таблицу записи из другой. Такой подход позволяет одновременно просматривать данные из нескольких таблиц.
Запросы . Запросы - это специальные средства, предназначенные для поиска и анализа информации в таблицах базы данных, отвечающей определенным критериям. Найденные записи, называемые результатами запроса, можно просматривать, редактировать и анализировать различными способами. Кроме того, результаты запроса могут использоваться в качестве основы для создания других объектов Access. Существуют различные типы запросов, наиболее распространенными из которых являются запросы на выборку, параметрические и перекрестные запросы, запросы на удаление записи, изменение и другие. Реже используются запросы на действие и запросы SQL (Structured Query Language). Если нужного запроса нет, то его можно создать дополнительно.
Запросы формируются различными способами, например, с помощью «мастера», также можно создать запрос вручную в режиме «конструктора». Простейшим и наиболее часто используемым видом запросов является запрос на выборку. Эти запросы выбирают данные из одной или нескольких таблиц и формируют из них новую таблицу, записи в которой можно изменять. Запросы на выборку нужны для вычисления сумм, средних значений и нахождения других итоговых значений. Таким образом, запросы используют данные из основных таблиц и создают временные таблицы.
Формы . Формы используются для ввода и редактирования записей в таблицах базы данных. Формы можно отображать в трех режимах: в режиме, предназначенном для ввода данных, в режиме таблицы, где данные представлены в табличном формате, и в режимах «макета» и «конструктора», позволяющих вносить изменения и дополнения в формы.
Основными элементами формы являются надписи, в которых указан текст, непосредственно отображающийся в форме, и поля, содержащие значения полей таблицы. Хотя режим «конструктора» позволяет создать форму с нуля, обычно он используется для доработки и совершенствования форм, созданных с помощью «мастера». Помимо вышеперечисленных средств формы также можно создавать с помощью следующих инструментов:
· «форма»;
· «разделенная форма»;
· «несколько элементов»;
· «пустая форма».
Наиболее эффективно использовать формы для ввода данных в виде специальных бланков, так как форма может иметь вид бланка. Применение форм позволяет вводить данные в удобном для пользователя виде привычных документов. Формы ввода-вывода позволяют вводить данные в базу, просматривать их, изменять значения полей, добавлять и удалять записи. Форма может содержать кнопку, используемую для печати отчета, открытия других объектов или автоматического выполнения других задач.
Отчеты . Отчеты используются для отображения информации в таблицах в отформатированном виде, который наглядно представляется как на экране монитора, так и на бумаге. Отчет является эффективным средством для вывода данных на печать из базы данных в форме, требуемой для пользователя (в виде справок, экзаменационных ведомостей, таблиц и т.д.). Помимо данных, извлеченных из нескольких таблиц и запросов, отчеты могут включать элементы оформления, свойственные печатным документам, как, например, названия, заголовки и колонтитулы.
Отчет можно отобразить в четырех режимах: в режиме «конструктора», позволяющем изменить внешний вид отчета, в режиме просмотра образца, в котором можно отобразить все элементы готового отчета, но в сокращенном виде, в режиме «макета», позволяющем более наглядно отображать (по сравнению с режимом конструктора) и форматировать отчет, и в режиме предварительного просмотра, где отчет отображается в том виде, в каком будет напечатан.
Таблицы, запросы, формы и отчеты представляют собой объекты, которые наиболее широко используются при разработке баз данных Access.
Однако возможности базы данных можно существенно расширить, если воспользоваться страницами доступа, макросами и модулями.
Страницы. Чтобы предоставить пользователям Интернета доступ к информации, в базе данных можно создать специальные страницы доступа к данным. С помощью страниц доступа к данным можно просматривать, добавлять, изменять и обрабатывать данные, хранящиеся в базе данных. Страницы доступа к данным могут также содержать данные из других источников, например, из Excel. Для публикации информации из базы данных в Web Access включают «мастер», который обеспечивает создание страницы доступа.
Макросы. Макросы представляют собой небольшие программы из одной или более макрокоманд, выполняющих определенные операции, с помощью которых обеспечивается, например, открытие формы, печать отчетов, щелчок кнопки и т.п. Это особенно удобно, если предполагается передать базу данных неквалифицированным пользователям. Например, можно написать макросы, содержащие последовательность команд, выполняющих рутинные задачи, или связать такие действия, как открытие формы или печать отчета, с кнопками кнопочной формы.
Модули. Модуль - объект базы данных, который позволяет создавать библиотеки подпрограмм и функций, используемых во всем приложении. Используя коды модулей можно решать такие задачи, как обработка ошибок ввода, объявление и применение переменных, организация циклов и т.п.
Создание таблиц
При вводе данных в Access полям присваиваются имена: Поле1, Поле2 и так далее. Можно использовать предложенные имена или изменить их. Название полей в таблице можно задавать двумя способами. После выбора способа создания таблицы выполняется команда «Создать »и вызывается соответствующее окно. На рис.8. показано создание таблицы в режиме «конструктора». Создаются требуемые поля таблицы с заданным типом данных, который выбирается посредством кнопки выбора – «галочка», в нижней части окна находится раздел выбора свойств поля, которые предлагаются вначале по умолчанию.
Рис. 14. Создание таблицы в режиме конструктора
Свойства полей таблицы базы данных Access указаны в нижней половине таблицы (рис.14).
Можно создать таблицу в режиме «конструктора», меняя, добавляя или удаляя поля таблицы. Для введения нового поля в верхней части окна таблицы указывается имя поля и определяется его тип. Для переименования поля, надо изменить его имя в столбце «Имя поля».
При создании таблиц используются следующие основные типы данных (рис.15).
Аннотация
В данной курсовой работе описывается проектирование базы данных центральной городской больницы и ее реализация в Oracle Datebase. Была представлена предметная область, разработаны концептуальная, логическая и физическая модели данных. Средствами Oracle Datebase созданы необходимые таблицы, запросы, отчеты. Курсовая работа состоит из.
Введение 3
1.Предметная область 4
2.Концептуальная модель 5
3.Логическая модель базы данных 7
4.Модель физической организации данных 9
5.Реализация баз данных в Oracle 9
6.Создание таблиц 10
7.Создание запросов 16
8.Заключение 27
Список литературы 28
Введение
База данных – это единое, вместительное хранилище разнообразных данных и описаний их структур, которое после своего определения, осуществляемого отдельно и независимо от приложений, используется одновременно многими приложениями.
Кроме данных база данных может содержать средства, позволяющие каждому из пользователей оперировать только теми данными, которые входят в его компетенцию. В результате взаимодействия данных, содержащихся в базе, с методами, доступными конкретным пользователям, образуется информация, которую они потребляют и на основании которой в пределах собственной компетенции производят ввод и редактирование данных
Целью данной курсовой работы является разработка и реализация базы данных для центральной больницы, что бы обеспечить хранение, накопление и предоставление информации о деятельности больницы. Создаваемая база данных предназначена в основном для автоматизации деятельности основных подразделений больницы.
Предметная область
Предметной областьюназывается часть реальной системы, представляющая интерес для данного исследования. При проектировании автоматизированных информационных систем предметная область отображается моделями данных нескольких уровней. Число уровней зависти от сложности решаемых задач, но в любом случае включает концептуальный и логический уровни.
В данной курсовой работе предметной областью является работа центральной больницы, которая занимается лечением больных. Организационная структура больницы состоит из двух отделов: регистратуры и приёмного покоя. В регистратуре проводятся записи на приём, выдаются направления, распределяют пациентов по палатам, фиксируют номера страховых полюсов. Приёмный покой, в свою очередь, ведет учет поступления и выписки, диагнозы пациентов, историю болезни.
База данных предназначена для хранения данных о больных, их размещении, выписываемых препаратах и о лечащих врачах.
Концептуальная модель
Первая фаза процесса проектирования базы данных заключается в создании для анализируемой части предприятия концептуальной модели данных.
Концептуальная модель - это модель предметной области. Компонентами модели являются объекты и взаимосвязи. Концептуальная модель служит, средством общения между различными пользователями и поэтому разрабатывается без учета особенностей физического представления данных. При проектировании концептуальной модели все усилия разработчика должны быть направлены в основном на структуризацию данных и выявление взаимосвязей между ними без рассмотрения особенностей реализации и вопросов эффективности обработки. Проектирование концептуальной модели основано на основе анализа решаемых на этом предприятии задач по обработке данных. Концептуальная модель включает описания объектов и их взаимосвязей, представляющих интерес в рассматриваемой предметной области. Взаимосвязи между объектами являются частью концептуальной модели и должны отображаться в базе данных. Взаимосвязь может охватывать любое число объектов. С другой стороны, каждый объект может участвовать в любом числе связей. Наряду с этим существуют взаимосвязи между атрибутами объекта. Различают взаимосвязи типа: "один к одному", "один ко многим", "многие ко многим".
Самой популярной моделью концептуального проектирования является модель «сущность-связь» (ER-модель), она относится к семантическим моделям.
Основными элементами модели являются сущности, связи между ними и их свойства (атрибуты).
Сущность – это класс однотипных объектов, информация о которых должна быть учтена в модели.
Каждая сущность должна иметь наименование, выраженное существительным в единственном числе. Каждая сущность в модели изображается в виде прямоугольника с наименованием.
Атрибут – характеристика (параметр) не которой сущности.
Домен – множество значений (область определения атрибутов).
У сущностей выделяются ключевые атрибуты – ключ сущности – это один или более атрибутов, уникально определяющих данную сущность.
Набор сущностей для центральной больницы (в скобках указаны атрибуты сущностей, подчёркнуты ключевые атрибуты):
ПАЦИЕНТЫ (Код пациента , фамилия, имя, дата рождения, номер страхового полиса, код отделения);
ЛЕЧЕНИЕ (Код больного , диагноз, дата выписки, код врача, стоимость);
ОТДЕЛЕНИЯ(Код отделения , название отделения, количество палат);
ПОСТУПЛЕНИЯ (Код больного, дата поступления, код палаты);
ПАЛАТЫ (Код палаты , кол-во мест, код отделения);
ВРАЧИ (Код врача, фамилия, имя, дата рождения, номер личного дела, код отделения);
Диаграмма «сущность-связь» для районной больницы изображена на рисунке 1.
Логическая модель базы данных
Версия концептуальной модели, которая может быть обеспечена конкретной СУБД, называется логической моделью. Процесс построения логической модели базы данных должен опираться на определённую модель данных (реляционная, сетевая, иерархическая), которая определяется типом предполагаемой для реализации информационной системы СУБД. В нашем случае база данных создается в среде Oracle и будет представлять собой реляционную базу данных.
Реляционная модель характеризуется своей простотой структуры данных, удобным для пользователя табличным представлением и возможностью использования формального аппарата алгебры отношений и реляционного исчисления для манипулирования данными..
В реляционных моделях данных объекты и взаимосвязи между ними представляются с помощью таблиц. Каждая таблица представляет один объект и состоит из строк и столбцов. Таблица в реляционной модели называется отношением.
Атрибут (поле) – любой столбец в таблице.
Кортежи (записи) – строки таблицы.
Таблицы связаны между собой при помощи ключевых полей.
Ключ – это поле, позволяющее однозначно идентифицировать запись в таблице. Ключ может быть простым (состоит из одного поля) или составным (из нескольких полей).
В реляционных базах данных логическое проектирование приводит к разработке схемы данных, которая представлена на рисунке 2.
Рис.2.
4. Модель физической организации данных
Физическая модель данных описывает то, как данные хранятся в компьютере, представляя информацию о структуре записей, их упорядоченности и существующих путях доступа.
В физической модели описываются типы, идентификаторы и разрядность полей. Физическая модель данных отражает физическое размещение данных на машинных носителях, то есть какой файл, какие объекты, с какими атрибутами содержит и каковы типы этих атрибутов.
©2015-2019 сайт
Все права принадлежать их авторам. Данный сайт не претендует на авторства, а предоставляет бесплатное использование.
Дата создания страницы: 2016-04-26
ЛЕКЦИЯ
Логические модели данных.
Иерархические, сетевые, реляционные модели данных.
Принципы построения.
Преимущества и недостатки
В процессе развития теории систем баз данных термин «модель данных» имел разное содержание. Для более глубокого понимания существа отдельных понятий рассмотрим некоторые особенности использования этого понятия в контексте эволюции баз данных.
11.1. О понятии «модель данных»
Первоначально понятие модели данных употреблялось как синоним структуры данных в конкретной базе данных. Структурная трактовка полностью согласовывалась с математическим определением понятия модели как множества с заданными на нем отношениями. Но, следует отметить, что объектом моделирования в данном случае являются не данные вообще, а конкретная база данных. Разработки новых архитектурных подходов, основанных на идеях многоуровневой архитектуры СУБД, показали, что уже недостаточно рассматривать отображение представлений конкретной базы данных. Требовалось решение на метауровне, позволяющее оперировать множествами всевозможных допустимых представлений баз данных в рамках заданной СУБД или, что эквивалентно, инструментальными средствами, используемыми для их спецификации. В этой связи возникла потребность в термине, который обозначал бы инструмент, а не результат моделирования, и соответствовал бы, таким образом, множеству всевозможных баз данных некоторого класса. Т.е. инструмент моделирования баз данных должен включать не только средства структурирования данных, но и средства манипулирования данными. Поэтому модель данных в инструментальном смысле стала пониматься как алгебраическая система – множество всевозможных допустимых типов данных, а также определенных на них отношений и операций. Позднее в это понятие стали включать еще и ограничения целостности, которые могут налагаться на данные. В результате проблема отображения данных в многоуровневых СУБД и системах распределенных баз данных стала рассматриваться как проблема отображения моделей данных.
Важно подчеркнуть, что для разработчиков и пользователей СУБД точным определением реализованной в ней модели данных фактически являются языковые средства определения данных и манипулирования данными. Поэтому отождествлять такой язык со схемой базы данных (результатом моделирования) – конкретной спецификацией в этом языке – неправомерно.
Начиная с середины 70-х годов, под влиянием предложенной в тот период концепции абстрактных типов само понятие типа данных в языках программирования стало трансформироваться таким образом, что в него стали вкладывать не только структурные свойства, но и элементы поведения (изменения данных). В дальнейшем это послужило основой для формирования концепции объекта, на которой базируются современные объектные модели.
В связи с этим был предложен новый подход, при котором модель данных рассматривается как система типов. Такой подход обеспечивал естественные возможности интеграции баз данных и языков программирования, способствовал формированию направления, связанного с созданием так называемых систем программирования баз данных. Трактовке модели данных как системы типов соответствуют не только уже существующие широко используемые модели, но также объектные модели, завоевывающие все большее влияние.
Итак, модель данных – модель логического уровня проектирования БД. Ее можно рассматривать как сочетание трех компонентов (слайд 2 ):
1. Структурный компонент, т.е. набор правил, по которым может быть построена БД.
2. Управляющий компонент, определяющий типы допустимых операций с данными (сюда относятся операции обновления и извлечения данных, а также операции изменения структуры БД).
3. Поддержка набора (необязательная) ограничений целостности данных, гарантирующая корректность используемых данных.
С точки зрения структурного компонента выделяют модели на основе записей. В модели на основе записей структуру данных составляет совокупность нескольких типов записей фиксированного формата. Каждый тип записи определяет фиксированное количество полей, каждое из которых имеет фикси рованную длину.
Существуют три основных типа логических моделей данных на основе записей ( слайд 3 ):
- реляционная модель данных (relational data model );
- сетевая мо дель данных (network data model );
- иерархическая модель данных (hierarchical data model ).
Иерархическая и сетевая модели данных были созданы почти на десять лет раньше реляционной модели данных, потому их связь с концепциями традиционной обработки файлов более очевидна.
11.2. Реляционная модель данных
Реляционная модель данных основана на понятии математических отношений. В реляционной модели данные и связи представлены в виде таблиц, каждая из которых имеет несколько столбцов с уникальными именами. На слайде (слайд 4 ) показан пример реляционной схемы, содержащей сведения о кафедрах ВУЗа и кадровом составе. Например, из таблицы «Кадровый состав» видно, что сотрудник Иванов И.И. работает в должности заведующего кафедрой 22, которая, согласно данным из таблицы «Структура», расположена в корпусе А, в комнате 322. Здесь важно отметить, что между отношениями «Кадровый состав» и «Структура» существует следующая связь: сотрудник работает на кафедре. Однако между этими двумя отношениями нет явно заданной связи: ее существование можно заметить, только зная, что атрибут Каф в отношении «Кадровый состав» эквивалентен атрибуту Каф в отношении «Структура».
Необходимо отметить, что в реляционной модели данных единственное требова ние состоит в том, чтобы база данных с точки зрения пользователя выглядела как набор таблиц. Однако такое восприятие относится только к логической структуре базы данных, т.е. к внешнему и к концептуальному уровням архитек туры ANSI / SPARC . Оно не относится к физической структуре базы данных, ко торая может быть реализована с помощью разнообразных структур хранения.
На слайдах (слайды 5, 6 ) представлена реляционная модель данных для ПрО «сотрудники-проекты-детали-поставщики».
11.3. Сетевая модель данных
В сетевой модели данные представлены в виде коллекций записей, а связи в виде наборов. В отличие от реляционной модели, связи здесь явным образом моделируются наборами, которые реализуются с помощью указателей (слайд 5 ). Сетевую модель можно представить как граф с записями в виде узлов графа и наборами в виде его ребер. На слайде показан пример сетевой схемы для тех же наборов данных, которые показаны в реляционной модели.
Самой популярной сетевой СУБД является система IDMS / R фирмы Computer Associates .
На слайдах (слайды 8, 9 ) представлены варианты сетевой модели данных для ПрО «сотрудники-проекты-детали-поставщики».
11.4. Иерархическая модель данных
Иерархическая модель является ограниченным подтипом сетевой модели. В ней данные также представлены как коллекции записей, а связи – как наборы. Однако в иерархической модели узел может иметь только одного родителя. Иерархическая модель может быть представлена как древовидный граф с записями в виде узлов (которые также называются сегментами) и множествами в виде ребер (слайд 6 ). На слайде приведен пример иерархической схемы для тех же наборов данных, которые показаны в предыдущих моделях.
Самой распространенной иерархической СУБД является система IMS корпорации IBM , хотя она обладает также некоторыми другими неиерархическими чертами.
На слайдах (слайды 11, 12 ) представлена варианты иерархической модели данных для ПрО «сотрудники-проекты-детали-поставщики».
11.5. Преимущества и недостатки моделей
Основанные на записях (логические) модели данных используются для определения общей структуры базы данных и высокоуровневого описания ее реализации. Их основной недостаток заключается в том, что они не дают адекватных средств для явного указания ограничений, накладываемых на данные. В то же время в объектных моделях данных отсутствуют средства указания их логической структуры, но за счет предоставления пользователю возможности указать ограничения для данных они позволяют в большей мере представить семантическую суть хранимой информации.
Большинство современных коммерческих систем основано на реляционной модели, тогда как самые первые системы баз данных создавались на основе сетевой или иерархической модели. При использовании последних двух моделей от пользователя требуется знание физической организации базы данных, к которой он должен осуществлять доступ. При работе с реляционной моделью независимость от данных обеспечивается в значительно большей степени. Следовательно, если в реляционных системах для обработки информации в базе данных принят декларативный подход (т.е. они указывают, какие данные следует извлечь), то в сетевых и иерархических системах – навигационный подход (т.е. они указывают, как их следует извлечь).
Сетевые и иерархические структуры в основном ориентированы на то, чтобы связи между данными хранились вместе с самими данными. Такое объединение реализовалось, например, агрегированием данных (построением сложных понятийных структур и данных) или введением ссылочного аппарата, фиксирующего семантические связи, непосредственно в записи данных.
Табличная форма представления информации является наиболее распространенной и понятной. Кроме того, такие семантически более сложные формы, как деревья и сети, путем введения некоторой избыточности могут быть сведены к табличным. При этом связи между данными также будут представлены в форме двумерных таблиц.
Реляционный подход, в основе которого лежит принцип разделения данных и связей, обеспечивает с одной стороны независимость данных, а с другой – более простые способы реализации хранения и обновления.
Многомерные модели, коммерческие реализации которых появились в начале 90-х годов для поддержки технологий OLAP представляют собой некоторое расширение модели универсальных отношений новыми операционными возможностями, обеспечивающими, в частности, необходимые для OLAP функции агрегирования данных. Таким образом, многомерные модели представляют собой особую разновидность реляционной модели.
11.6. Документальные системы и интеграция моделей
Приведенные выше положения разрабатывались и действительно широко используются для баз данных хорошо структурированной информации. Однако уже сегодня одной из важнейших проблем становится обеспечение интеграции неоднородных информационных ресурсов, и в частности слабоструктурированных данных. Необходимость ее решения связывается со стремлением к полноценной интеграции систем баз данных в среду Web-технологий. При этом уже недостаточно простого обеспечения доступа к базе данных традиционным способом “из-под” HTML-форм. Нужна интеграция на модельном уровне. И в этом случае проблема семантической интероперабельности информационных ресурсов сводится к задаче разработки средств и технологий, предусматривающих явную спецификацию метаданных для ресурсов слабоструктурированных данных на основе традиционных технологий моделирования из области баз данных.
Именно на достижение этой цели направлены интенсивные разработки WWW -консорциумом языка XML и его инфраструктуры (фактически, новой модели данных для этой среды), объектной модели документов и других средств, которые, как можно ожидать, в близкое время станут основой технологий управления информационными ресурсами. Это направление связано с другой глобальной проблемой - организацией распределенных неоднородных информационных систем на основе построения репозиториев метаданных (этому понятию в классических работах по проектированию баз данных соответствует понятие словарь данных), обеспечивающих возможность семантического отождествления ресурсов и, таким образом, возможность их целенаправленного повторного использования.
- определение типов и моделей данных
- иерархическая и сетевая модели
- реляционная модель.
В языке высокого уровня поддерживаются достаточно развитые типы данных, включая простые, структурированные, ссылочные и абстрактные (объекты). Простые типы являются базовыми по отношению к ЭВМ и различаются как целый, вещественный, логический, литерный и т.д. Тип данных – это совокупность структуры данных, операций, накладываемых на данные, и ограничений целостности, то есть мероприятий, которые обеспечивают корректную работу операций с данным типом. Структурный тип предназначен для конструирования из конечного набора базовых типов сложных структур данных. Выделим три основные структурных типа: запись (структура), массив, файл, рекурсивная структура. Массив – совокупность данных одного типа. Операции работы с массивом: создание, задание изначальных значений элементов массива, выбор элементов по значению индексов (порядковому номеру) и избирательное обновление элементов. Ограничения целостностями – это то, что все элементы одного типа и индекс – целое число. Структура (тип записи) – совокупность элементов разного типа. Например, структура – сотрудник включает элементы табельный номер, ФИО, дата рождения. Структура не используется в чистом виде, а для конструирования более сложных типов, в частности файлов. Файл – это совокупность записей одинаковой структуры (массив структур). Файл хранится на жестком диске и предназначен для хранения данных. Функции с файлом: создать, установить указатель на начало файла, записать в конец файла новую запись, считать информацию по указателю и получить указатель на конец файла. Рекурсивный тип – образуется суперпозиция типов данных в целях получения более сложных структур, например, деревьев, поддерживается с помощью указателей.
Ссылочный тип – указатель – это адрес памяти. Всё дисковое пространство разделено на страницы (2, 4, 8 и т.д. килобайт), и адрес памяти – это номер страницы + относительный номер байта внутри страницы. Абстрактный тип (объект) – это интерпретируемый структурированный тип с функциями, определенными над его элементами. При этом определяются имена, типы элементов, функции (методы), а также правила (ограничения целостности) применения этих функций к описанным элементам. Для поддержания во внешней дисковой памяти более сложных структур данных на уровне СУБД поддерживаются модели данных, включая иерархическую, сетевую и реляционную. Модель данных – это совокупность структур данных и правил их порождения, операций над ними и ограничений целостности как перечень мероприятий, направленных на поддержание БД в актуальном состоянии. Целостность – это точность, корректность данных в базе в любой момент времени. Ограничение целостности – набор мероприятий, направленных на поддержание целостности базы и корректности выборки информации.
Иерархическая и сетевая модель данных.
На первых этапах внедрения БД (50–80 годы) широко использовались СУБД первого поколения на ЕС ЭВМ – иерархические и сетевые СУБД.
Иерархическая модель организует структуру в виде упорядоченного дерева, вершины (узлы) соответствуют сущностям и называются типами записей. Тип записи может состоять из нескольких элементов, а дуга, связывающая типы, называется «исходный-порожденный» и соответствует типу «один ко многим» (одному экземпляру исходной записи соответтствует ноль, один или несколько порожденных записей). Доступ к каждому узлу осуществляется по иерархическому пути – это последовательность типов записей от корня дерева. Верхняя вершина – корень, последняя – лист, много деревьев – лес. Расширением типа записи является таблица, а расширением связи – множество соединений между строками таблиц. Каждая строка таблицы – это экземпляр типа записи. Ограничением целостности является то, что в вершину всегда входит только одна дуга. Операции: включение данных (экземпляр порожденной записи не может существовать в отсутствии экземпляра исходной), которое осуществляется по иерархическому пути (указываются ключи записи); удаление данных (при удалении экземпляра исходной записи автоматически удаляются все экземпляры порожденных, так как экземпляры записей реализуются посредством указателей); извлечение данных осуществляется по иерархическому пути посредством указания ключей записей; обновление данных – изменение значений производится только над извлеченными записями. В экземпляре записи всегда есть ячейка с указателем на брата и на сына. Таким образом, связи в иерархической модели основаны на указателях. Для того, чтобы реализовать концептуальную модель предметной области нужно ввести 6 иерархических структуры: материал – деталь – поставка, склад – деталь – поставка, город – поставщик – поставка, материал – деталь – отпуск, склад – деталь – отпуск, клиент – отпуск.
Достоинством иерархической модели является простота и интуитивное восприятие информации. В настоящее время поисковые системы (над реляционными базами) основаны на построении навигационного иерархического интерфейса. Недостатком этой модели является искусственный с избыточностью подход реализации связей «многие ко многим» и процедурность операций манипулирования данными.
Представим для примера реализацию на иерархической модели базы данных «склад деталей».
Для реализации базы «склад деталей» на иерархической СУБД необходимо формирование как минимум четырех иерархических структур (лес). Так как отношение «поставщик–деталь», «клиент–деталь» являются «многие ко многим», поэтому необходима избыточность на уровне модели БД. Связь «многим ко многим» развязываются 2 иерархиями.
Сетевая модель.
Это ориентированный граф, в узлах которого расположены типы записей, граф произвольного вида и в вершину может входить несколько дуг. Идея сетевой модели предложена ассоциацией КОДАСИЛ. Характеристика модели КОДАСИЛ:
- элемент данных – базовая поименованная единица
- агрегат – совокупность данных: массив, структура
- запись – поименованная совокупность элементов и/или агрегатов данных
- набор – поименованная совокупность записей, образующих двухуровневую иерархическую структуру «исодный–порожденный». Каждый тип набора представляет собой отношение между двумя типами записей. Каждый экземпляр набора содержит один экземпляр записи «владелец» и ноль, один или несколько экземпляров «член набора».
Сеть – это совокупность иерархий.
Ограничением целостности является следующее: в конкретном экземпляре набора экземпляр «член набора» не может иметь более одного экземпляра записи «владелец». Таким образом сеть набирается совокупностью иерархий «один ко многим». Операции: извлечь – извлечь запись можно по ключу, от извлеченной записи возможен переход к подчиненным; включить – можно в ранее объявленный набор, а можно в т.н. сингулярный набор, у которого пока нет владельца; переключить – из одного набора в другой; удалить – удаляется не запись, а связи; модифицировать – изменить значение аргументов в выбранной записи. Достоинства – простота реализации связи «многие ко многим».
Сетевые СУБД – IDMS –> СЕТЬ и СЕТОР.
Сетевые модели хороши для реализации технических коммуникаций (описание электрических сетей, тепловых сетей) и применяются в инженерных расчетах. В настоящее время реализуются либо как собственные разработки, либо на ОО СУБД.
Пример сетевой модели базы «склад деталей».
Таким образом в БД хранятся экземпляры типов записей «город», «поставщик», «поставка», «деталь» и т.д., которые связаны в рамках определенных экземпляров наборов отношениями «один ко многим». Например, деталь 1 в типе набора «деталь – поставка» является владельцем экземпляров поставка 2 и поставка 6, а деталь 2 в этом типе набора является владельцем поставки 1, 2, 7. Деталь 1 и 2 находятся в разных связках, то есть в разных экземпляров набора.
К ранним видом СУБД относятся псевдореляционные. Они получили распространение на ПЭВМ, это системы dBase группы. К ним относятся Clipper, FoxPro, FoxBase. В этих системах каждая таблица (тип записи) хранится в отдельном файле с расширением dbf, например, отдельно файл «Город», файл «Поставщик» и т.д. Между файлами связи поддерживались на программном уровне в клиентском приложении. Для каждого файла создавались индексы для обеспечения быстрого доступа к записям файлов по ключу. Далее мы перейдем к реляционной модели, которая поддерживает ссылочную целостность между сущностями.
Реляционная модель данных.
Характеристика модели.
Предложил концепцию реляционной модели Эдвард Кодд, он предложил вложить в основу алгебру отношений. В основе реляционной модели лежит понятие теоретико-множественных отношений – это подмножество декартова произведения доменов, а домен – это множество значений, которые принимает атрибут (множество названий городов, фамилий сотрудников). Отношение (таблица) – подмножество декартова произведения одного или более доменов.
| Имя отношения | ||||
| А1 | А2 | А3 | А4 | – атрибуты |
| А11 | А12 | А13 | А14 | – кортежи выборки |
| А21 | А22 | А23 | А24 | |
| А31 | А32 | А33 | А34 | |
| … | … | … | … |
А11, А12 – это значения атрибутов.
Реляционная база данных – это множество связанных между собой отношений (таблиц), и при этом связи между таблицами задаются посредством внешних или вторичных ключей, то есть атрибутов таблиц, которые в каких-то других отношениях являются первичными. Список имен атрибутов называется схемой отношения. Каждое отношение имеет уникальное имя. Свойства отношений: нет одинаковых кортежей – все записи отличаются по первичному ключу; кортежи не упорядочены сверху вниз; атрибуты не упорядочены слева направо (в операциях реляционной алгебры строки и столбцы отношений могут просматриваться в любом порядке и последовательности безотносительно к их информационному содержанию смыслу); все значения – скалярные и все элементы столбца имеют одинаковую природу, так как построены на одном домене. Отношение с такими свойствами называется нормализованным. В отношении один или несколько атрибутов являются ключом, то есть однозначно характеризует кортеж. Свойства ключа: уникальная идентификация выборки, неизбыточность (удаление любого атрибута лишает его свойства уникальности). Наряду со смысловым ключом используется инкрементный (счетчик), состоящий из одного числового поля, который автоматически наращивается.
Правила отображения концептуальной модели предметной области в реляционную БД.
На рисунке 5 изображена концептуальная модель. Отобразим её в реляционную.
- отображение сущностей в реляционные отношения, которые нормализованы
- отображение ассоциаций связано с использованием ссылочной целостности между таблицами. Ассоциативное отношение 1:1, 1:М, М:1 реализуются посредством помещения внешнего вторичного ключа в сущность, из которой исходит стрелка ассоциации. Этот ключ соответствует первичному ключу, на который указывает стрелка. Связи «многие ко многим» требует ведения перекрестной таблицы, в которую включается в качестве вторичных ключей первичные ключи связываемых сущностей.
- отображение агрегации осуществляется с помощью ассоциаций, при этом заводится отдельная таблица «часть» с вторичным ключом, связывающим её с таблицей владельцев (целое)
- отображение обобщения чаще всего осуществляется посредством отображения каждого подтипа в отдельную таблицу с включением в неё вторичного ключа, соответствующего первичному ключу таблицы супертипа. Пример: «клиент» (код клиента ) для подтипов «организация» (ОГРН , код клиента), «ИП» (ИНН , код клиента).
Целостность реляционной модели.
Целостность объектов (отношений) – в базе не допускается, чтобы какой-либо атрибут из первичного ключа принимал неопределенные значения.
Ссылочная целостность – БД не должна содержать несогласованных значений внешних ключей (FK). Если отношение R2 имеет среди своих атрибутов какой-то внешний ключ, который соответствует первичному ключу (PK) отношения R1, то каждое значение FK должно быть равно значению РК. Пример: все коды материалов таблицы «деталь» должны присутствовать как первичные ключи в таблице материалов.
