Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
Введение в базы данных. Основные понятия и определения.
1.1. Данные
Похоже, всякая попытка дать четкое определение термина «данные» не лишена тавтологичностн. Рассмотрим несколько таких определении:
Данные — это факты, характеризующие свойства объектов и явлений из некоторой предметной области. Но что такое факты, как не разнообразные данные?
Данные — это информация, предназначенная к обработке. А информация- в свою очередь — это знания о фактических данных.
Данные — это сведения, полученные путем измерения, наблюдения и т.п. Не вдаваясь в дальнейшие семантические изыскания, примем за основу: данные — это информация, факты н сведения. Теперь разберемся, что представляют собой данные с практической точки зрения.
Посмотрим по сторонам: предположим, что мы видим три книжных полки. В первой — художественные произведения, во второй — техническая литература, в третьей спит кошка. Что можно сказать об увиденном, где здесь данные? Жанр, наименование, и имена авторов книг, местоположение каждой книги (на первой или второй полке, или вообще вне полок), обшей их количество. Стоимость каждой книги, количество страниц. Материал, из которого изготовлена каждая полка, ее габариты. Порода, возраст, вес. имя кошки. Марка ее любимого корма, способность к ловле мышей. На какой из полок предпочитает отдыхать. Данные можно найти везде, они вокруг нас, но не все они представляют интерес с точки зрения их сбора, хранения и обработки. Итак множество данных описывает свойства каких-либо объектов, принадлежащих выбранной предметной области и взаимоотношения между этими объектами. Для каждого объекта можно определить список его свойств, которые являются существенными. Например, объект «налогоплательщик» с точки зрения налоговых служб может обладать следующими свойствами: имя, дата рождения, доход за предыдущий год и т.п. Конкретный человек, к которому эти данные относятся, имеет гораздо больше свойств — цвет глаз, размер обуви, любимый вид спорта и т.д.. но вряд ли они представляют интерес для решения задачи сбора налогов. Тому же самому человеку с точки зрения, например, стоматолога соответствует совершенно иной перечень свойств. Каждое свойство конкретного объекта имеет некоторое значение (цвет глаз — голубой, вес — 78кг. доход — неизвестен). Набор значений свойств формирует некоторую абстракцию, упрощение этого объекта — мы манипулируем не самим объектом, а ограниченным набором представлений о нем.
1.2. Базы данных
База данных (БД) — совокупность данных, организованных по определенным правилам, предусматривающим общие принципы описания, хранения и манипулирования данными.
Данные, относящиеся к некоторой предметной области, объединяются и структурируются таким образом, чтобы над ними можно было выполнять необходимые операции: обновлять, добавлять новые данные, удалять ненужные, извлекать данные, отвечающие условиям поиска. Простейший пример базы данных— записная книжка с номерами телефонов. Данные упорядочены по первым буквам имен абонентов, что позволяет быстро найти нужный телефон. При необходимости можно добавить информацию о новом абоненте, вычеркнуть или изменить записанную ранее. Другой пример — база данных торговой организации. БД содержит сведения о клиентах и товарах. Объект «клиент» вступает во взаимоотношение с объектом «товар», оформляя заказ. Данные должны быть организованы так, чтобы допускать их обновление, добавление сведений о новых клиентах, поступивших товарах, оформление заказов, а также извлечение данных для формирования различных отчетов — поступившие товары, заказы за последний месяц и т.п.
Банк данных — база данных и система управления ею.
1.3. Модели представления данных
Модель — способ структурирования данных, описания взаимосвязей между данными.
Очевидные требования к модели:
• Модель должна быть достаточно универсальной, позволяя работать с данными различной структуры и сложности.
• Модель должна допускать автоматическую обработку данных, т.е. должна быть реализуема программными средствами.
• Модель должна быть наглядной, «прозрачной». Поскольку задача описания структуры данных средствами выбранной модели возлагается на разработчика (человека), чем сложнее модель — тем труднее избежать ошибок при проектировании.
Ниже перечислены основные разновидности моделей представления данных, используемых или использовавшихся в прошлом.
Иерархическая модель.
Модель (как видно из названия) представляет данные в виде иерархии (рис. 1.1). Модель ориентирована на описание объектов, находящихся между собой в отношении подчинения. Например, структура кадров некоторой организации. Организация состоит из отделов, каждый отдел имеет руководителя и сотрудников. Другой пример: объект «колесо» является составной частью объекта «автомобиль». Между автомобилем и колесом имеется связь, смысл которой можно озвучить следующим образом: объект «автомобиль» включает в себя несколько объектов «колесо».
Рис. 1.1. Иерархическая модель
Сетевая модель. Сетевая модель (рис. 1.2) представляет собой развитие иерархической. Модель позволяет описывать более сложные виды взаимоотношений между данными. Однако расширение возможностей достигается за счет большей сложности реализации самой модели и трудности манипулирования данными.
Рис. 1.2. Сетевая модель
Реляционная модель. В реляционной модели (рис. 1.3) данные представляются в виде таблиц, состоящих из строк и столбцов. Каждая строка таблицы — информация об одном конкретном объекте, столбцы содержат свойства этого объекта. Взаимоотношения между объектами задаются с помощью связей между столбцами таблиц. Реляционная модель на сегодняшний день наиболее распространена. Она достаточно универсальна и проста в проектировании.
Рис. 1.3. Реляционная модель
Объектная модель. В этой модели данные представляются в форме объектов. Объект имеет набор свойств, называемых атрибутами, и может включать в себя также процедуры для обработки данных, которые называют методами. Объекты, имеющие одинаковые наборы атрибутов и различающиеся только их значениями, образуют некоторый класс объектов. Например, класс «клиент» может иметь следующие атрибуты: «фамилия», «имя», «отчество», «номер кредитной карты». Для каждого объекта из этого класса определены конкретные значения перечисленных атрибутов. Говорят, что объект явтяется экземпляром класса. На основе существующего класса могут создаваться новые, наследующие свойства исходного. При этом исходный класс именуется родителем нового класса. Производный класс называют потомком исходного. При этом объекты — экземпляры класса-потомка принадлежат также и родительскому классу, поскольку обладают всеми его атрибутами. Пример: на основе класса «клиент» может быть определен класс «постоянный клиент». Новый класс наследует атрибуты родительского и при этом добавляется новый атрибут — «процент скидки». Все постоянные клиенты продолжают оставаться клиентами в прежнем понимании, но о них имеется еще и дополнительная информация. В настоящее время не существует единого подхода к реализации объектных баз данных. Объектный подход — набор общих принципов, которые могут применяться при проектировании различных приложений.
Гибридные модели. В некоторых приложениях предпринимаются попытки смешения различных моделей представления данных. Пример такого смешения
— объектно-реляционная модель. В ней использовано некоторое сходство между реляционной и объектной идеологией. Строки таблиц реляционной модели соответствуют объектам объектной модели, столбцы таблиц — атрибутам объектов. Таблицы в целом являются аналогом классов. Отсюда вытекает возможность введения наследования при определении таблиц — таблица-потомок содержит те же столбцы, что и родительская, и, кроме того — дополнительные, определенные при наследовании. По идее создателей, объектно-реляционная модель должна унаследовать от реляционной легкость описания и манипулирования данными, а от объектной — возможность определения более сложных взаимоотношений между объектами.
1.4. Реляционные базы данных
Базы данных, хранение информации в которых основано на реляционной модели, называют реляционными базами данных. Как было сказано ранее, реляционная модель предполагает организацию данных в виде таблиц. Строки таблиц называют записями, столбцы — полями.
Рис, 1.4. Таблицы е реляционной модели
В примере (рис. 1.4) показано, как могут быть представлены данные и связи между ними в БД некоторой торговой организации. Таблица «Клиент» содержит данные о каждом клиенте — фамилию, имя и отчество. В таблице «Товар» хранятся сведения об имеющихся товарах. Когда клиент вступает во взаимоотношения с некоторым товаром (делает заказ), этот факт фиксируется в таблице «Заказ». Для того чтобы можно было сослаться на отдельную запись (строку) в некоторой таблице, каждая запись этой таблицы должна содержать уникальный идентификатор. В данном примере роль таких идентификаторов выполняют поля «Id _кл», «Id_TOB» и «Ы_зак». Поле таблицы, значения которого гарантированно уникальны для каждой записи этой таблицы, называют ключевым полем или ключом. Ключ не обязательно должен быть числовым. Иногда уникальным идентификатором может сложить не одно поле, а комбинация полей. При этом сочетание значений этих полей должно быть уникальным. Такие поля образуют составной ключ таблицы.
Вернемся к примеру. Обратим внимание, что поля «Клиент» и «Товар» содержат значения, совпадающие со значениями ключей таблиц «Клиент» и «Товар)» (совпадение имен полей и названий таблиц не является обязательным). Каждая запись таблицы «Заказ» содержит информацию о заказе клиентом некоторого товара — дату заказа и количество единиц товара. В заказе также содержатся идентификаторы клиента и заказа, что позволяет однозначно определить — кем и на какой товар сделан заказ. Так, клиент Иванов заказал один шкаф, а позднее — двенадцать стульев. Клиент Николаев заказал только один шкаф, а Петров пока не заказал ничего.
Для изображения таблиц и связей между ними обычно применяется более компактная форма, в которой указываются имена полей, без данных. На рис. 1.5 приведена структура рассмотренной ранее базы данных.
Рис. 1.5. Изображение таблиц и связей
Стрелки указывают «направление», в котором используются ключевые поля. Значения из поля «Id _кл» помешаются в поле «Клиент», а значения из поля «Id_тов» - в поле «Товар». Очевидно, что одному клиенту может соответствовать несколько заказов, но каждому заказу соответствует только одни клиент. С товарами — аналогичная ситуация. Один товар может входить в несколько заказов, но в каждый заказ входит только один товар.
Вероятно, оформление заказов было бы более удобным, если бы в одном заказе можно было указывать сразу несколько товаров. Для этого структуру данных следует изменить.
На рис. 1.6 приведена новая структура БД. Таблица «Заказ» содержит для каждого заказа его уникальный идентификатор, идентификатор клиента, сделавшего этот заказ и дату. Перечень и количество товаров, входящих в заказ, хранится в таблице «Состав заказа». Одной записи в таблице «Заказ» может соответствовать несколько записей в таблице «Состав заказа».
Рис. 1.6. Преобразованная структура БД
1.5. Системы управления базами данных
Система управления базами данных (СУБД) — комплекс программ и языковых средств, предназначенных для создания, ведения и использования баз данных. В англоязычной терминологии СУБД именуется DBMS (Database Management System).
Ведение базы данных — действия по добавлению, удалению и изменению хранимых данных.
Как видно из рис. 1.7. СУБД играет роль посредника между клиентом (человеком или программой) и данными.
Рис. 1.7. Роль СУБД
Главные задачи, которые решает СУБД:
• Хранение данных.
• Поддержание целостности данных.
• Предоставление инструментария для манипулирования данными.
Задача хранения подразумевает размещение данных на некотором носителе информации (например, диске), должен быть определен формат данных, обеспечивающие не только статичное хранение, но и эффективное манипулирование данными.
СУБД должна контролировать любые изменения в данных и гарантировать, что при любых действиях по манипулированию данными не возникнет противоречии в структуре или в самих данных (при условии, что такие противоречия не были заложены разработчиком). СУБД должна обеспечивать интерфейс (функции, программы) для доступа к манипулированию данными.
Виды СУБД:
• Локальная СУБД.
• Система «клиент-сервер».
Различие заключается в степени «удаленности» данных и СУБД от потребителя этих данных — клиента (человека или программы).
СУБД, организованная по технологии «клиент-сервер» (рис. 1.8). предоставляет средства, позволяющие работать с данными клиентам, имеющим различное местоположение и использующим различное программное обеспечение. При этом клиентское программное обеспечение не отвечает за хранение данных и поддержание их целостности, оно лишь отправляет запросы к СУБД и получает на них ответы. СУБД является сервером, хранящим данные, который обеспечивает некоторый интерфейс и при этом не отвечает за то, как эти данные могут быть использованы клиентами (внешними приложениями).
Рис. 1.8 Архитектура «клиент-сервер»
Локальные СУБД (рис. 1.9) интегрированы с конечным приложением — потребителем данных (программой автоматической обработки или интерфейсом пользователя). Соответственно, если с одними и теми же данными работает несколько приложений, каждое приложение должно включать в себя собственную СУБД.
Рис. 1.9. Локальная СУБД
Многие локальные СУБД изнутри организованы по технологии «клиент-сервер», но с точки зрения пользователя представляют собой единое приложение. В этом случае разделение скорее
логическое — одни процедуры внутри программы отвечают только за доступ к данным и их целостность, другие выполняют только обработку н взаимодействие с пользователем, обращаясь к данным не напрямую, а лишь с помощью процедур первой группы.
Ниже перечислены некоторые из известных СУБД, относящиеся к первому и второму виду.
Серверные СУБД: Локальные СУБД:
Oracle Microsoft Access
Microsoft SQL FoxPro
MySQL Clarion
mSQL Clipper
PosrgreSQL
Cache