Технология и модели распределенных баз данных

 

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

«Клиент-сервер» («Client-server architecture» или «Client-server model») - это модель взаимодействия компьютеров в сети. Обычно компьютеры не являются равноправными. Каждый из них играет свою определенную роль. Некоторые компьютеры в сети владеют и распоряжаются информационно-вычислительными ресурсами, такими как процессоры, файловая система, почтовая служба, служба печати, база данных. Другие имеют возможность обращаться к этим службам, пользуясь услугами первых.

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

Серверная сторона функционирует на специализированном комплексе, включающем в себя мощные аппаратные средства, требуемый набор стандартного программного обеспечения, систему управления базами данных и собственно структуры данных.

Под клиентом понимается программа, использующая ресурсы, а под сервером (по английски - слуга) программа, обслуживающая запросы клиентов на получение ресурсов определенного вида, в соответствии с рисунком 3.

 

 

Рисунок 3 - Клиент – серверное приложение

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

Конкретный сервер определяется видом ресурса, который к нему подчинен. Если ресурсом являются базы данных, то соответственно - сервер баз данных, назначение которого - обслуживать запросы клиентов, связанные с обработкой данных. В настоящее время фактическим стандартом для многопользовательских СУБД, стала архитектура «клиент-сервер» [22].

Если проектируемая информационная система (ИС) будет построена по технологии «клиент-сервер», то это значит, что прикладные программы, реализованные с ее помощью, будут иметь распределенный характер. То есть часть функций прикладной программы будет реализована в программе-клиенте, другая - в программе-сервере, притом, что для их взаимодействия будет определен некоторый протокол.

Понятие архитектуры «клиент-сервер» в системах управления предприятием связано с делением любой прикладной программы на четыре основных компонента или слоя. Первая слой - это функции ввода и отображения данных. Второй слой объединяет чисто прикладных функций, характерных для данной предметной области. К третьему слою относятся фундаментальные функции хранения и управления информационными ресурсами (базами данных, файловыми системами). И четвертый слой - служебный, играющий роль связок между слоями первых трех компонентов.

В соответствии с этим являются следующие логические компоненты:

- компонент представления (визуализации) данных;

- компонент прикладной логики;

- компонент управления базой данных и доступ к информационным ресурсам;

- протокол взаимодействия

Преимущества технологии «клиент-сервер» следующие [23]:

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

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

Позволяет объединить различные клиенты. Использовать ресурсы одного сервера часто могут клиенты с разными аппаратными платформами, операционными системами и т.п.

Еще одной ситуацией, когда клиент-сервер - единственный способ построения системы, является наличие в автоматизированной системе удаленных пользователей, с которыми необходимо обмениваться информации в реальном масштабе времени. Под реальным масштабом времени понимаются секунды-минуты. Обмен данными на электронных носителях в таком случае не применим, а архитектура файл-сервер потребует очень высоких скоростей обмена, а это может быть либо принципиально невозможно, либо очень дорого. Отдельные примеры богатых организаций, которые строили файл-серверные системы в масштабах города являются исключениями, подтверждающими правило [24].

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

Разница в построении технологии «клиент-сервер» определяются четырьмя факторами. Во-первых, тем, в какие виды программного обеспечения интегрирован каждый из этих компонентов. Во-вторых, тем, какие механизмы программного обеспечения используются для реализации функций всех четырех групп. В-третьих - как логические компоненты распределяются между компьютерами в сети. В-четвертых, какие механизмы используются для связи компонентов между собой.

В зависимости от того, как распределены логические компоненты приложения между клиентами и серверами, различают четыре модели архитектуры «клиент-сервер» [24]:

- модель " файл-сервер" (File Server - FS);

- модель " сервер транзакций" (Remote Data Access - RDA);

- модель " сервер базы данных" (DataBase Server - DBS);

- модель " сервер приложений" (Application Server - AS);

FS-модель является базовой для локальных сетей персональных компьютеров.

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

К технологическим недостаткам данной модели относят высокий сетевой трафик (передача множества файлов, необходимых приложению), узкий спектр операций манипулирования данными (" данные - это файлы" ), отсутствие адекватных средств безопасности доступа к данным (защита только на уровне файловой системы) и т.д. Все перечисленные недостатки - следствие внутренне присущих FS-модели ограничений, определяемых ее характером.

RDA-модель значимо отличается от FS-модели характером компонента доступа к информационным ресурсам. Это, как правило, SQL-сервер. В RDA-модели коды компонента представления и прикладного компонента совмещены и выполняются на компьютере-клиенте. Клиент делает запросы к информационным ресурсам по сети удаленному компьютеру.

К недостаткам RDA-модели относятся:

- взаимодействие клиента и сервера посредством SQL-запросов существенно загружает сеть;

- удовлетворительное администрирование приложений в RDA-модели практически невозможно из-за совмещения в одной программе различных по своей природе функций.

Основу DBS-модели составляет механизм хранимых процедур - средство программирования SQL-сервера. Процедуры хранятся в словаре базы данных, разделяются между несколькими клиентами и выполняются на том же компьютере, где функционирует SQL-сервер. Язык, на котором разрабатываются хранимые процедуры (SQL/PTL), является процедурным расширением языка запросов SQL и уникален для каждой конкретной СУБД.

В DBS-модели компонент представления выполняется на компьютере-клиенте, в то время как прикладной компонент оформлен как набор хранимых процедур и функционирует на компьютере-сервере БД. К достоинствам DBS-модели можно отнести:

- возможность централизованного администрирования прикладных функций, и снижение трафика (вместо SQL-запросов по сети направляются вызовы хранимых процедур);

- возможность разделения процедуры между несколькими приложениями, экономия ресурсов компьютера за счет использования единожды созданного плана выполнения процедуры.

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

При создании базы данных необходимо было создать 8 таблиц: Data, TehnSvPrise1, TehnSvPrise2,  TehnSvPrise3, TehnSvSotel, TehnSvSotrud, TehnSvTelephon, TehnSvAbonent. Поля, необходимые для создание полноценной базы данных, показаны в приложении.

База данных предназначена для хранения данных по учету оплаты и использования трафика абонентами телекоммуникационной компании.

Основные задачи базы данных по расчету с абонентами:

- предоставление информации о наличие задолжностей у абонентов;

- учет оплаты;.

- полное редактирование всех записей в базе данных;

- вывод на печать отчетов;

- проектирование отчетов по расчетам с абонентами;.

- расширенный поиск абонентов, сотрудников и другой необходимой информации.

- отключение и подключение задолжников.

Основные объектами являются:

1 Лицевой счет абонента телефонной связи (Имя, Фамилия, Отчество, Адрес, Телефон, Дата оплаты, Услуги связи, Сумма долга и Оплата).

2 Лицевой счет абонента сотовой связи (Имя, Фамилия, Отчество, Адрес, Телефон, Дата регистрации, Вид связи, Состояние связи и Состояние счета). 3. Лицевой счет абонента Интернет связи (Имя, Фамилия, Отчество, Адрес, Телефон, Факс, Электронная почта, Дата оплаты, Услуги связи, Сумма долга и Оплата). Данная таблица содержит абонентов Интернет связи.

4 Сотрудники (Имя, Фамилия, Отчество, Отдел, Адрес, Должность, Домашний телефон, Рабочий телефон, Дата рождения, Табельный номер). Данная таблица позволяет получить полную информацию о сотрудниках ТКС.

5 Прайс-лист: услуги телефонной связи, услуги сотовой связи, услуги Интернет связи (Вид услуги, Стоимость). Данная таблица содержит записи о услугах ТКС и их стоимости.

6 Срок отключения (Контрольная дата). Данная таблица содержит контрольную дату выплаты задолжностей.

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

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

Сущность – любой различимый объект (объект, который мы можем отличить от другого), информацию о котором необходимо хранить в базе данных. Необходимо различать такие понятия, как тип сущности и экземпляр сущности. Понятие тип сущности относится к набору однородных личностей, предметов, событий или идей, выступающих как целое. Экземпляр сущности относится к конкретной вещи в наборе. Атрибут – поименованная характеристика сущности. Его наименование должно быть уникальным для конкретного типа сущности, но может быть одинаковым для различного типа сущностей.

Абсолютное различие между типами сущностей и атрибутами отсутствует. Атрибут является таковым только в связи с типом сущности. В другом контексте атрибут может выступать как самостоятельная сущность. Ключ – минимальный набор атрибутов, по значениям которых можно однозначно найти требуемый экземпляр сущности. Минимальность означает, что исключение из набора любого атрибута не позволяет идентифицировать сущность по оставшимся. Связь – ассоциирование двух или более сущностей. Если бы назначением базы данных было только хранение отдельных, не связанных между собой данных, то ее структура могла бы быть очень простой.

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

Главная задача дипломной работы заключается в необходимости автоматизации оперативного учета предприятия, а так же возможность предоставления оперативной информации о деятельности предприятия за определенный период

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

Для таблицы Абоненты телефонной связи (TehnSvTelephon):

Codе – счетчик тип данных.

Name –текстовой тип данных.

TehnSvSername –текстовой тип данных.

TehnSvOldname –текстовой тип данных.

TehnSvAdress –текстовой тип данных.

TehnSvTelReg – текстовой тип данных.

TehnSvFaseCount – тип данных текстовой.

DataReg – тип данных текстовой.

UslugiTehnSv – тип данных числовой.

SummaDolga – тип данных числовой.

Oplata – тип данных текстовой.

Для таблиц Услуги телефонной связи, Услуги сотовой связи, Услуги Интернет связи (TehnSvPrise1, TehnSvPrise2, TehnSvPrise3):

Codе – тип данных счетчик.

TehnSvWive– тип данных текстовой.

Many– тип данных числовой.

Для таблицы Абоненты сотовой связи (TehnSvSotel):

Codе – тип данных счетчик.

Name – тип данных текстовой.

TehnSvSername – тип данных текстовой.

TehnSvOldname – тип данных текстовой.

TehnSvAdress – тип данных текстовой.

TehnSvTelReg – тип данных текстовой.

TehnSvFaseCount – тип данных текстовой.

TehnSvDataReg – тип данных текстовой.

WiveSv – тип данных текстовой.

GPRS – тип данных текстовой.

SostSv – тип данных текстовой.

Для таблицы Абоненты Интернет связи (TehnSvAbonent):

Codе – тип данных счетчик.

Name – тип данных текстовой.

TehnSvSername – тип данных текстовой.

TehnSvOldname – тип данных текстовой.

Adress – тип данных текстовой.

TehnSvTelReg – тип данных текстовой.

TehnSvFaks – тип данных текстовой.

TehnSvElPost – тип данных текстовой.

TehnSvFaseCount – тип данных текстовой.

DataReg – тип данных текстовой.

UslugiTehnSv – тип данных числовой.

SummaDolga – тип данных числовой.

Oplata – тип данных текстовой.

Для таблицы Сотрудники (TehnSvSotrud):

Codе – тип данных счетчик.

Name – тип данных текстовой.

TehnSvSername – тип данных текстовой.

TehnSvOldname – тип данных текстовой.

Adress – тип данных текстовой.

TehnSvOtdel– текстовой тип данных.

TehnSvDolg– текстовой тип данных.

Berthday – текстовой тип данных.

TehnSvHomeTel – текстовой тип данных.

DjobTel –текстовой тип данных.

Otdel - текстовой тип данных.

Для таблицы Контрольная дата (Data):

Codе – счетчик тип данных.

Data– текстовой тип данных.

Для работы непосредственно с базой данных использовались модули:  

DataSours - невизуальный компонент представляет собой источник данных, который обеспечивает связь между набором данных и компонентами отображения и редактирования данных. Все наборы данных должны быть связаны с компонентом источника данных, если требуется редактирование данных. Основное свойство источника данных – DataSet. Оно указывает на компонент набора данных (Table, Query и др), с которыми связан источник. Свойство State дает информацию о текущем состоянии набора данных: находится ли он в состоянии редактирования, вставки данных и так далее. Основное назначение DataSource состоит в том, чтобы облегчить внесение изменений в приложения. Все визуальные компоненты данных на форме связаны с DataSource, который, в свою очередь, связан с набором данных.

ADOTable - может использоваться в приложениях ADO вместо компонента Table приложений BDE, выполняющего аналогичные функции. Он вступает в контакт с указанной таблицей базы данных. Он вступает в контакт с указанной таблицей базы данных. Имя таблицы задается свойством TableName. Какой именно вариант доступа: прямой или посредством оператора SELECT будет использоваться, определяется свойством TableDirect. По умолчанию TableDirect = false, что означает автоматическое создание компонентом ADOTable соответствующего оператора SELECT. Следует также сказать, что при работе с некоторыми типами баз данных компонент ADOTable дает сбои из-за несоответствия неявно генерируемых им запросов SQL синтаксису базы данных. В этом плане надежнее компоненты ADOQuery и ADODataSet.

Соединение с базой данных осуществляется методом Open или установкой в true свойства Active. При этом если связь с базой данных осуществляется через компонент ADOConnection, надо учитывать указанную в описании этого компонента взаимосвязь свойства Active компонента ADOTable и свойства Connected компонента ADOConnection.

ADOQuery - компонент представляет собой запрос к базе данных. Это может быть как запрос, в результате которого возвращаются данные из базы (например, SELECT), так и запрос, не формирующий результирующего набора данных (например, INSERT). Компонент аналогичен компоненту Query из BDE.

Рассматривая различные существующие базы для подключения таблиц, были выбраны базы Access, потому что они поддерживаются большинством систем и отличаются высокой надёжностью. Это является очень удобным для пользователя. Таким образом, создание базы данных, обладающей такими свойствами, задача достаточно актуальная и полезная.

 

⇐ Предыдущая12345678Следующая ⇒

Поделиться: