![]() |
Архитектура Аудит Военная наука Иностранные языки Медицина Металлургия Метрология Образование Политология Производство Психология Стандартизация Технологии |
Клиент-серверная архитектура
При такой архитектура на сервере хранится БД и работает программа СУБД, которая обрабатывает запросы пользователей и возвращает им наборы данных. Программы пользователей не работают напрямую с БД как набором физических файлов, а обращаются к СУБД, которая выполняет операции. Т.к. большая часть работы происходит на сервере, то нагрузка с клиентских компьютеров снимается. СУБД автоматически следит за целостностью и сохранностью БД, контролирует доступ к информации с помощью службы паролей. Клиент-серверные СУБД допускают блокировку на уровне записи или даже отдельного поля. Следовательно, с таблицей может одновременно работать любое количество пользователей, а доступ к функции изменения конкретной записи или одного из ее полей обеспечен только одному из них. Основной недостаток клиент-серверной архитектуры – не высокая надёжность. Если сервер выходит из строя, то вся работа останавливается.
Распределенная архитектура В сети работает несколько серверов, таблицы БД распределены между ними для повышения эффективности (так же между серверами может распределяться нагрузка). На каждом сервере работает своя копия СУБД. В такой архитектуре используются специальные программы – серверы приложений. Они позволяют оптимизировать обработку запросов большого числа пользователей и равномерно распределить нагрузку между компьютерами в сети. Для выполнения сложных вычислений используются программы, автоматически запускаемые на более мощных серверах. Недостаток такой архитектуры – сложный дорогостоящий процесс ее создания и сопровождения, высокие требования к серверным компьютерам.
Интернет-архитектура Доступ к БД и СУБД осуществляется из браузера по стандартному протоколу. Это предъявляет минимальные требования к клиентскому оборудованию. Благодаря стандартизации всех протоколов и интерфейсов взаимодействия в интернете такие системы легко создавать и внедрять, не требуется разрабатывать специальные клиентские программы или придумывать спецификации обмена данным между сервером и клиентским компьютером. Достаточно использовать готовые браузеры и программные решения.
№ 30 Реляционные БД. Первичные ключи и индексы Пример Пусть некоторое предприятие выполняет заказы своих покупателей
Заказчики
Связь между таблицами по полю Покупатель Связанные отношениями таблицы взаимодействую по принципу главная (master) – подчиненная (detail). В нашем примере таблица «заказы» - главная, а таблица «заказчики» - подчиненная. Главную таблицу часто называю родительской, а подчиненную – дочерней. Одна и та же таблица может быть главное по отношению к одной таблице БД и дочерней по отношению к другой. Первичные ключи и индексы В каждой таблице БД может существовать первичный ключ – поле или набор полей, однозначно идентифицирующий запись. Значение первичного ключа в таблице БД должно быть уникальными, т.е. в таблице не должно быть двух или более записей с одинаковым значением первичного ключа. Первичные ключи облегчают установление связи между таблицами. Например, в таблице заказов первичный ключ правильно будет построить по номеру заказов, т.к. каждому заказу всегда назначается уникальный номер. Индексы отличаются от первичных ключей тем, что не требуют непременной уникальности значений входящих в их состав полей, они устанавливаются по полям, которые часто используются при поиске и сортировке данных: индексы помогут системе значительно быстрее найти нужные данные или отсортировать их в нужной последовательности.
№31 Избыточность данных Одна из первых проблем, с которой сталкивается проектировщик программы – это избыточность данных. В приведенном выше примере одна и та же компания может встретиться сразу в нескольких записях, т.к. покупатель в различное время может сделать несколько заказов. Выход состоит в следующем: в целях экономии внешней памяти в таблицу заказов помещают числовую ссылку на наименование компании, а сами наименования компаний хранятся в таблице «заказчики», где наименования компаний, адрес, телефон и другая информация записаны только 1 раз. Это выглядит следующим образом:
Пусть некоторое предприятие выполняет заказы своих покупателей zakaz
zakazchiki
Проблемы избыточности данных в реляционных БД обусловлено существованием трех типов отношений между различными множествами объектов: один к одном, один ко многим, многие ко многим. Отношение 1 к 1 означает, что между множествами существует взаимно-однозначное соответствие. Например такое отношение можно наблюдать между множеством авто и мужеством номерных знаков. Отношение 1к1 не вызывает избыточности, поэтому связанные таким отношение множества целесообразно объединять в одну таблицу.
Отношение многие ко многим самое сложное и распространённое. Рассмотри его на примере компаний и товаров. С одной стороны компании может производить несколько видов товаров, с другой стороны один вид товара может производиться несколькими конкурирующими компаниями. В задачах с отношениями многие ко многим избыточность данных проявляется наиболее остро. Она решается организацией 3ей таблицы кодирующей связи между записями информационных таблиц. Например, первая таблица содержит информацию о товарах, 2-я - компания, 3я связывает коды компаний с кодами товаров
№32 Архитектура БД Delphi. Драйверы БД. Существует множество форматов БД, их разнообразие связано с необходимостью оптимизации скорости доступа и объема данных для различных типов используемых приложений. Программная поддержка наиболее популярных форматов БД реализована в Delphi системным программным средством, который называется BDE (Borland Database Engine) Механизм BDE реализован в виде набора библиотек, которые обеспечивают для программы, написанной на паскале, простой и удобный доступ к БД независимо от их архитектуры. При использовании механизма BDE, разработчик может не задумываться о том, как его программа будет работать с БД на физическом уровне: локальный, в файл-серверный или в клиент-серверной архитектуре. Так при переходе к использованию СУБД разный производителей программисту не потребуется менять исходный код своей программы, достаточно внести изменения только в настройки BDE Драйверы БД Механизм BDE представляет собой программную прослойку (middleware) между клиентской программой и БД (или СУБД). Запрос из приложения передается внутри механизма BDE, который использует специализированные системные программы (драйверы) для непосредственной работы с СУБД. Такие драйверы выпускаются для каждой СУБД, механизм BDE настраивается на их использование с помощью специального редактора вызываемого из утилиты SQL Explorer ( она открывается командой Database -> Explore). Поставку BDE входит 2 набора драйверов. Первый набор предназначен для файл-северных СУБД- dBase, Paradox, FoxPro, Access и данный в текстовом формате. Такие драйверы представляют собой весьма сложную программу, выполняющую множества функций СУБД. Второй набор ориентирован на клиент-серверный СУБД (Interbase, IBM DB2, Informix, Oracle, Sybase, Microsoft SQL Server). Этот набор называется SQL LINKS такие драйверы передаюо только запросы и команды из BDE СУБД и получают обратно результаты их выполнения. Всю работу по обработке данных выполняют СУБД. Давно разработан и существует стандартный протокол ODBC (Open Database Connectivity Interface, Открытый интерфейс взаимодействия с БД), напоминающий независимую работу BDE. Драйверы ODBC выпущены для всех без исключения СУБД, и разработчик может использовать в BDE драйверы ODBC.
|
Последнее изменение этой страницы: 2017-04-13; Просмотров: 703; Нарушение авторского права страницы