Архитектура Аудит Военная наука Иностранные языки Медицина Металлургия Метрология
Образование Политология Производство Психология Стандартизация Технологии


Клиент-серверная архитектура



При такой архитектура на сервере хранится БД и работает программа СУБД, которая обрабатывает запросы пользователей и возвращает им наборы данных. Программы пользователей не работают напрямую с БД как набором физических файлов, а обращаются к СУБД, которая выполняет операции. Т.к. большая часть работы происходит на сервере, то нагрузка с клиентских компьютеров снимается. СУБД автоматически следит за целостностью и сохранностью БД, контролирует доступ к информации с помощью службы паролей. Клиент-серверные СУБД допускают блокировку на уровне записи или даже отдельного поля. Следовательно, с таблицей может одновременно работать любое количество пользователей, а доступ к функции изменения конкретной записи или одного из ее полей обеспечен только одному из них.

Основной недостаток клиент-серверной архитектуры – не высокая надёжность. Если сервер выходит из строя, то вся работа останавливается.

 

Распределенная архитектура

В сети работает несколько серверов, таблицы БД распределены между ними для повышения эффективности (так же между серверами может распределяться нагрузка). На каждом сервере работает своя копия СУБД. В такой архитектуре используются специальные программы – серверы приложений. Они позволяют оптимизировать обработку запросов большого числа пользователей и равномерно распределить нагрузку между компьютерами в сети. Для выполнения сложных вычислений используются программы, автоматически запускаемые на более мощных серверах.

Недостаток такой архитектуры – сложный дорогостоящий процесс ее создания и сопровождения, высокие требования к серверным компьютерам.

 

Интернет-архитектура

Доступ к БД и СУБД осуществляется из браузера по стандартному протоколу. Это предъявляет минимальные требования к клиентскому оборудованию. Благодаря стандартизации всех протоколов и интерфейсов взаимодействия в интернете такие системы легко создавать и внедрять, не требуется разрабатывать специальные клиентские программы или придумывать спецификации обмена данным между сервером и клиентским компьютером. Достаточно использовать готовые браузеры и программные решения.

 

 

№ 30 Реляционные БД. Первичные ключи и индексы

Пример

Пусть некоторое предприятие выполняет заказы своих покупателей

Номер заказа Покупатель Дата заказа Количество
Афина 15.12.07
Мазда-центр 10.09.08
Рога и Копыта 19.09.08
Мазда-центр 25.09.08

Заказчики

Покупатель Адрес Телефон
Афина Владимирова 10
Мазда-центр Карбышева 12
Рога и Копыта Скопытная 6а

Связь между таблицами по полю Покупатель

Связанные отношениями таблицы взаимодействую по принципу главная (master) – подчиненная (detail). В нашем примере таблица «заказы» - главная, а таблица «заказчики» - подчиненная. Главную таблицу часто называю родительской, а подчиненную – дочерней. Одна и та же таблица может быть главное по отношению к одной таблице БД и дочерней по отношению к другой.

Первичные ключи и индексы

В каждой таблице БД может существовать первичный ключ – поле или набор полей, однозначно идентифицирующий запись. Значение первичного ключа в таблице БД должно быть уникальными, т.е. в таблице не должно быть двух или более записей с одинаковым значением первичного ключа. Первичные ключи облегчают установление связи между таблицами. Например, в таблице заказов первичный ключ правильно будет построить по номеру заказов, т.к. каждому заказу всегда назначается уникальный номер.

Индексы отличаются от первичных ключей тем, что не требуют непременной уникальности значений входящих в их состав полей, они устанавливаются по полям, которые часто используются при поиске и сортировке данных: индексы помогут системе значительно быстрее найти нужные данные или отсортировать их в нужной последовательности.

 

№31 Избыточность данных

Одна из первых проблем, с которой сталкивается проектировщик программы – это избыточность данных. В приведенном выше примере одна и та же компания может встретиться сразу в нескольких записях, т.к. покупатель в различное время может сделать несколько заказов. Выход состоит в следующем: в целях экономии внешней памяти в таблицу заказов помещают числовую ссылку на наименование компании, а сами наименования компаний хранятся в таблице «заказчики», где наименования компаний, адрес, телефон и другая информация записаны только 1 раз. Это выглядит следующим образом:

 

Пусть некоторое предприятие выполняет заказы своих покупателей

zakaz

Номер заказа Nom_zak Покупатель Kod_pok Дата заказа Date_zak Количество kol
15.12.07
10.09.08
19.09.08
25.09.08

zakazchiki

Код покупателя id_pok Покупатель pok Адрес adr Телефон phone
Афина Владимирова 10
Мазда-центр Карбышева 12
Рога и Копыта Скопытная 6а

 

Проблемы избыточности данных в реляционных БД обусловлено существованием трех типов отношений между различными множествами объектов: один к одном, один ко многим, многие ко многим.

Отношение 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; Просмотров: 660; Нарушение авторского права страницы


lektsia.com 2007 - 2024 год. Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав! (0.014 с.)
Главная | Случайная страница | Обратная связь