Клиент-серверная модель доступа к БД
“Клиент-сервер” – это модель взаимодействия компьютеров и программ в сети. Некоторые компьютеры в сети владеют и распоряжаются информационно-вычислительными ресурсами, такими, как процессоры, файловая система, почтовая служба, служба печати, база данных. Другие компьютеры имеют возможность обращаться к этим ресурсам. Компьютер, управляющий тем или иным ресурсом, принято называть сервером ресурса, а компьютер, желающий им воспользоваться – клиентом. Конкретный сервер определяется видом ресурса, которым он владеет. Так, если ресурсом является база данных, то речь идет о сервере баз данных; если ресурс – файловая система, то говорят о файловом сервере, или файл-сервере, и т. д. В сети один и тот же компьютер может выполнять роль как клиента, так и сервера.
Этот же принцип распространяется и на взаимодействие программ. Если одна из них выполняет некоторые функции, предоставляя другим соответствующий набор услуг, то такая программа выступает в качестве сервера. Программы, которые пользуются этими услугами, принято называть клиентами.
Первоначально СУБД имели централизованную архитектуру. В ней СУБД функционировала на центральном компьютере (большая ЭВМ или мини-компьютер). Там же располагалась база данных. К центральному компьютеру были подключены терминалы, выступавшие в качестве рабочих мест пользователей. Все процессы, связанные с обработкой данных, а именно: поддержка ввода пользователя, формирование, оптимизация и выполнение запросов, обмен с устройствами внешней памяти и т. д., выполнялись на центральном компьютере, что предъявляло жесткие требования к его производительности.
Инфологическое проектирование БД
Инфологическая модель (информационно-логическая модель) — ориентированная на человека и не зависимая от типа СУБД модель предметной области, определяющая совокупности информационных объектов, их атрибутов и отношений между объектами, динамику изменений предметной области, а также характер информационных потребностей пользователей. Инфологическая модель предметной области может быть описана моделью "сущность—связь" (моделью Чена), в основе которой лежит деление реального мира на отдельные различимые сущности, находящиеся в определенных связях друг с другом, причем обе категории — сущность и связь полагаются первичными, неопределенными понятиями.
§ обеспечение наиболее естественных для человека способов сбора и представления той информации, которую предполагается хранить в создаваемой базе данных. Поэтому инфологическую модель данных пытаются строить по аналогии с естественным языком (последний не может быть использован в чистом виде из-за сложности компьютерной обработки текстов и неоднозначности любого естественного языка). Основными конструктивными элементами инфологических моделей являются сущности, связи между ними и их свойства (атрибуты).
Требования, предъявляемые к инфологической модели
§ Адекватное, отображение предметной области
§ Недопущение неоднозначной трактовки модели
§ Четкое определение моделируемой предметной области (конечность модели)
§ Легкая расширяемость, обеспечивающая ввод новых данных без изменения ранее определенных, то же относят и к удалению данных
§ Возможность композиции и декомпозиции модели в связи с большой размерностью реальных инфологических моделей
§ Легкое восприятие различными категориями пользователей; желательно, чтобы инфологическую модель строил (или хотя бы участвовал в ее создании) специалист, работающий в данной предметной области, а не только проектировщик систем машинной обработки данных
§ Применимость языка спецификаций модели как при ручном, так и при автоматизированном проектировании информационных систем
Метод сущность-связь
одель сущность-связь (ER-модель) (англ. entity-relationship model, ERM) — модель данных, позволяющая описывать концептуальные схемы предметной области.
ER-модель используется при высокоуровневом (концептуальном) проектировании баз данных. С её помощью можно выделить ключевые сущности и обозначить связи, которые могут устанавливаться между этими сущностями.
Во время проектирования баз данных происходит преобразование ER-модели в конкретную схему базы данных на основе выбранной модели данных (реляционной,объектной, сетевой или др.).
ER-модель представляет собой формальную конструкцию, которая сама по себе не предписывает никаких графических средств её визуализации. В качестве стандартной графической нотации, с помощью которой можно визуализировать ER-модель, была предложена диаграмма сущность-связь (ER-диаграмма)(англ. entity-relationship diagram, ERD).
Понятия ER-модель и ER-диаграмма часто ошибочно не различают, хотя для визуализации ER-моделей предложены и другие графические нотации (см. ниже)
Типы сущностей и связей
между участниками. Например, утверждение "покупатели покупают продукты" указывает, что существует связь между сущностью "покупатели" и сущностью "продукты".
Число участников определяет размерность связи. У большей части отношений - два участника, хотя на практике их может быть и больше, например, в утверждении: "сотрудники продают товары покупателям" видна тройная связь.
Иногда сущность оказывается связана сама с собой. Обычно подобные связи характерны для иерархических структур, когда сотрудник может подчиняться менеджеру и одновременно являться менеджером для других сотрудников.
Существует несколько типов связей между сущностями: "один к одному", "один ко многим" и "многие ко многим".
Связь "один к одному" встречается редко. Например, у нас есть таблица с информацией о всех сотрудниках и таблица с информацией о всех торговых агентах, которые являются сотрудниками нашего предприятия. Записи в таких таблицах могут быть связаны отношением "один к одному".
Связь "один ко многим" - наиболее распространенный тип связей. Например, один торговый агент может выписывать много счетов и т.п.
Очень часто используется и связь "многие ко многим". Например, один покупатель может покупать товары нескольких видов, и при этом товар одного вида может "покупаться" разными покупателями. Обычно в СУБД возможности явно определить отношение "многие-ко-многим" нельзя, но это часто делается обходным способом.
Участие каждой сущности в связи может быть полным или частичным. Пример - наша связь "сотрудник - торговый агент". Со стороны торгового агента эта связь полная, потому что торговый агент не может не быть сотрудником предприятия. Со стороны сотрудника эта связь - частичная, поскольку сотрудник вполне может не быть торговым агентом.
Модели данных
Модель данных — это абстрактное, самодостаточное, логическое определение объектов, операторов и прочих элементов, в совокупности составляющих абстрактную машину доступа к данным, с которой взаимодействует пользователь. Эти объекты позволяют моделировать структуру данных, а операторы — поведение данных[1].
Каждая БД и СУБД строится на основе некоторой явной или неявной модели данных. Все СУБД, построенные на одной и той же модели данных, относят к одному типу. Например, основой реляционных СУБД является реляционная модель данных, сетевых СУБД — сетевая модель данных, иерархических СУБД — иерархическая модель данных и т.д.
Состав модели данных
Примеры:
· Иерархические
· Сетевые
· Реляционные
· Объектно-ориентированные
· Объектно-реляционные
Понятие схемы и подсхемы
Современная технология баз данных основана на концепции многоуровневой архитектуры СУБД. Эти идеи впервые были сформулированы в отчёте рабочей группы по базам данных Комитета по планированию стандартов Американского национального института стандартов (ANSI/X3/SPARC). Этот отчёт был опубликован в 1975 г. В нём была предложена обобщенная трёхуровневая модель архитектуры СУБД, включающая концептуальный, внешний и внутренний уровни (рис. 1.7).
Рис.1.7 Уровни представления данных
Концептуальный уровень архитектуры ANSI/SPARC служит для под-держки единого взгляда на базу данных, общего для всех её приложений и независимого от них и от среды хранения [6]. Концептуальный уровень представляет собой формализованную информационно-логическую модель ПО. Описание этого представления называется концептуальной схемой или схемой БД.
| Схема базы данных – это описание базы данных в терминах конкретной модели данных. |
Внутренний уровень архитектуры поддерживает представление данных в среде хранения и пути доступа к ним [6]. На этом архитектурном уровне БД представлена в полностью "материализованном" виде, тогда как на других уровнях идёт работа на уровне отдельных экземпляров или множества экземпляров данных. Описание БД на внутреннем уровне называется внутренней схемой или схемой хранения.
Внешний уровень архитектуры БД предназначен для групп пользователей. Описание представления данных для группы пользователей называется внешней схемой. Наличие внешнего уровня позволяет поддерживать разное представление одних и тех же данных для различных групп пользователей или задач [6].
Подсхема базы данных – это описание структуры данных прикладного программиста.
Каждый из этих уровней может считаться управляемым, если он обладает внешним интерфейсом, который обеспечивает возможности определения данных. В этом случае становится возможными формирование и системная поддержка независимого взгляда на БД для какой-либо группы персонала или пользователей, взаимодействующих с БД через интерфейс данного уровня.