Реферат: Отчет по производственной практике (СУБД)

СУБД

Разработка базы данных

    План

  Введение…………………………………………………….2

   Глава 1.  Теоретические аспекты СУБД

    1. Основныепонятия……………………………………….3

    2. Функциональныевозможности СУБД…………………7

    3. Архитектурасистем управления………………………..9

    4. ТипыСУБД………………………………………………13

   Глава 2. Разработкабазы данных………………………….15

  Заключение………………………………………………….17

   Введение.

   Развитие средстввычислительной техники обеспечило для создания и широкого

   использованиясистем обработки данных разнообразного назначения.

   Разрабатываютсяинформационные системы для обслуживания различных систем

   деятельности,систем управления хозяйственными и техническими объектами,

   модельные комплексыдля научных исследований, системы автоматизации

   проектирования ипроизводства, всевозможные тренажеры и обучающие системы.

   Одной из важныхпредпосылок создания таких систем стала возможность

   оснащения их«памятью» для накопления, хранения и систематизация больших

   объемов данных.Другой существенной предпосылкой нужно признать разработку

   подходов, а такжесоздание программных и технических средств

   конструированиясистем, предназначенных для коллективного пользования. В

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

   управления такогорода совместно используемыми ресурсами данных, которые

   стали называтьсябазами данных. Исследования и разработки, связанные с

   проектированием,созданием и эксплуатации баз данных, а также необходимых

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

   управления данными.

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

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

   интерфейсах всейсовокупности ее пользователей. По существу, система

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

   данных.

   В настоящее времяразработаны и используются на персональных компьютерах

   около двадцатисистем управления базами данных. Они представляют

   пользователюудобные средства интерактивного взаимодействия с БД и имеют

   развитый языкпрограммирования.

  

I. Теоретические аспекты СУБД.

   1. Основные понятия БД.

   Всякая прикладнаяпрограмма является отображением какой — то части

   реального мира ипоэтому содержит его формализованное описание в виде

   данных.  Крупные массивы данных размещают, какправило, отдельно от

   исполняемогопрограммы, и организуют в виде Базы данных. Начиная с 60-х

   годов для работы сданными, стали использовать особые программные

   комплексы,называемые системами управления базами данных (СУБД). Системы

   управления базамиданных отвечают за:

     * физическоеразмещение данных и их описаний;

     * поиск данных;

     * поддержание базданных в актуальном состоянии;

     * защиту данныхот некорректных обновлений и несанкционированного

       доступа;

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

   (прикладныхпрограмм).

   Модели данных.

   Хранимые в базеданных имеют определенную логическую структуру, то есть,

   представленынекоторой моделью, поддерживаемой СУБД. К числу важнейших

   относятся следующиемодели данных:

     * иерархическая;

     * сетевая;

     * реляционная;

     * объектно — ориентированная;

   В иерархическоймодели данные представляются в виде древовидной

   (иерархической)структуры. Она удобна для работы с иерархически

   упорядоченнойинформацией и громоздка для информации со сложными

   логическимисвязями.

   Сетевая модельозначает представление данных в виде произвольного графа.

   Достоинствомсетевой и иерархической моделей данных является возможность

   их эффективнойреализации показателей затрат памяти и оперативности.

   Недостатком сетевоймодели данных является высокая сложность и жесткость

   схемы БД,построенной на ее основе.

   Реляционная модельданных (РМД) название получила от английского термина

   Relation — отношение. Модель данных описываетнекоторый набор родовых

   понятий ипризнаков, которыми должны обладать все конкретные СУБД и

   управляемые ими БД,если они основываются на этой модели.

  Объектно-ориентировочная модель данных — это когда в базе хранятся не

   только данные, но иметоды их обработки в виде программного кода. Это

   перспективноенаправление, пока также не получившее активного

   распространенияиз-за сложности создания и применения подобных СУБД.

   База данных — этосовокупность записей различного типа, содержащая

   перекрестныессылки.

   Файл — этосовокупность записей одного типа, в котором перекрестные ссылки

   отсутствуют.

   Более того, вопределении нет упоминания о компьютерной архитектуре. Дело

   в том, что, хотя вбольшинстве случаев БД действительно представляет собой

   один или (чаще)несколько файлов, физическая их организация существенно

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

   так и все вместе.И, наоборот, для хранения одной таблицы иногда

   используютсянесколько файлов. Для поддержки перекрестных ссылок и

   быстрого поискаобычно выделяются дополнительные специальные файлы.

   Поэтому при работес базами данных обычно применяются понятия более

   высокого логическогоуровня: запись и таблица, без углубления в

   подробности ихфизической структуры.

   Таким образом, самапо себе база данных — это только набор таблиц с

   перекрестнымиссылками. Чтобы универсальным способом извлекать из нее

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

   программы,называются СУБД.

   По характеруиспользования СУБД делят на персональные (СУБДП) и

  многопользовательские (СУБДМ).

   К персональным СУБДотносятся VISUAL FOXPRO, ACCESS и др. К

  многопользовательским СУБД относятся, например, СУБД ORACLE и INFORMIX.

  Многопользовательские СУБД включают в себя сервер БД и клиентскую часть,

   работают внеоднородной вычислительной среде допускаются разные типы ЭВМ и

   различныеоперационные системы. Поэтому на базе СУБДМ можно создать

   информационнуюсистему, функционирующую по технологии клиент-сервер.

   Универсальностьмногопользовательских СУБД отражается соответственно на

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

   СУБДП представляетсобой совокупность языковых и программных средств,

   предназначенных длясоздания, ведения и использования БД.

   Персональные СУБДобеспечивают возможность создания персональных БД и

   недорогихприложений, работающих с ними, и при необходимости создания

   приложений,работающих с сервером БД.

   Для обработкикоманд пользователя или операторов программ в СУБДП

   используютсяинтерпретаторы команд (операторов) и компиляторы. С помощью

   компиляторов в рядеСУБДП можно получать исполняемые автономно приложения -ехе- программы.

   Обеспечениецелостности БД-необходимое условие успешного функционирования

   БД. ЦелостностьБД-свойство БД, означающее, что база данных содержит

   полную инепротиворечивую информацию, Для обеспечения целостности БД

   накладываютограничения целостности в виде некоторых условий, которым

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

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

   сведения о которыххранятся в БД, или отсутствие повторяющихся записей в

   таблицахреляционных БД.

   Обеспечениебезопасности достигается СУБД шифрованием прикладных программ,

   данных, защитыпаролем, поддержкой уровней доступа к базе данных, к

   отдельной таблице.

   Расширениевозможностей пользователя СУБДП достигается за счет подключения

   системраспространения Си или Ассемблера.

   Поддержкафункционирования в сети обеспечивается:

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

       данным, т.е.средствами блокировки файлов (таблиц), записей, полей,

       которые вразной степени реализованы в разных СУБДП;

     * средствамимеханизма транзакций, обеспечивающими целостность БД при

      функционировании в сети.

   Теперь рассмотримфункции СУБД немного подробнее:

   Определение данных.

   СУБД должнадопускать определения данных (внешние схемы, концептуальную

   схему, внутреннююсхему, а также все связанные отображения) в исходной

   форме ипреобразовывать эти определения в форму соответствующих объектов.

   Иначе говоря, СУБДдолжна включать в себя компонент языкового процессора

   для различныхязыков определений данных. СУБД должно также «понимать»

   синтаксис языкаопределений данных.

   Обработка данных.

   СУБД должна уметьобрабатывать запросы пользователя на выборку, изменение

   или удалениесуществующих данных в базе данных или на добавление новых

   данных в базуданных. Другими словами, СУБД должна включать в себя

   компонентпроцессора языка обработки данных.

   Запросы языка обработки данныхбывают «планируемые» и «не планируемые».

    1. Планируемыйзапрос-это запрос, необходимость которого предусмотрена

       заранее.Администратор базы данных, возможно, должен настроить

       физическийпроект БД таким образом, чтобы гарантировать достаточное

       быстродействиедля таких запросов.

    2. Не планируемыйзапрос-это, наоборот, специальный запрос, необходимость

       которого небыла предусмотрена заранее. Физический проект БД может

       подходить, аможет и не подходить для рассматриваемого специального

       запроса. Вобщем, получение возможной наибольшей производительности

       для непланируемых запросов представляет собой одну из проблем СУБД.

       (Подробнее этапроблема будет обсуждаться в следующих частях книги.)

   Безопасность и целостностьданных.

   СУБД должнаконтролировать пользовательские запросы и пресекать попытки

   нарушения правилбезопасности и целостности, определенные АБД.

   Восстановлениеданных и дублирование.

   СУБД или другойсвязанный с ней программный компонент, обычно называемый

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

   восстановлениемданных и дублированием. Подробности использования этих

   функций системыприводятся далее в этой книге.

   Словарь данных.

   СУБД должнаобеспечить функцию словаря данных. Сам словарь данных можно по

   праву считать БД(но не пользовательской, а системой). Словарь «содержит

   данные о данных»(иногда называемые метаданными), т.е. определения других

   объектов системы, ане просто «сырые данные». В частности, исходная и

   объектная формыразличных схем (внешних, концептуальных и т.д.) и

   отображений будутсохранены в словаре. Расширенный словарь будет включать

   также перекрестныессылки, показывающие, например, какие из программ какую

   часть БДиспользуют, какие отчеты требуются тем или иным пользователям,

   какие терминалыподключены к системе и т.д. Словарь может быть (а на самом

   деле даже долженбыть) интегрирован в определяемую им БД, а значит, должен

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

   к словарю, как и кдругой БД, например, для того узнать, какие программы

   и/или пользователибудут затронуты при предполагаемом внесении изменения в

   систему.(Дальнейшее обсуждение этого вопроса приводится в следующих

   главах книги.)

   Производительность.

   Очевидно, что СУБДдолжна выполнять все указанные функции с максимально

   возможнойэффективностью.

   Подводя итогсказанному, можно сделать вывод, что в целом назначением СУБД

   являетсяпредоставление пользовательского интерфейса с БД.

   Пользовательскийинтерфейс может быть определен как граница в системе,

   ниже которой всеневидимо для пользователя. Следовательно, по определению

   пользовательскийинтерфейс находится на внешнем уровне. Тем не менее,

   иногда встречаютсяслучаи, когда внешнее представление вряд ли значительно

   отличается ототносящейся, по мере в современных коммерческих продуктах.

   В заключении вкратцесопоставим описанную СУБД с системой файлами (или с

   управлениемфайлами). В своей основе система управления файлами является

   компонентом общейсистемы, которая управляет хранимыми файлами; проще

   говоря, она «ближек диску», чем СУБД. Таким образом, пользователь системы

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

   выполнять простыеоперации выборки и обновления хранимых записей в таких

   файлах. Однако, вотличие от СУБД, системы управления файлами имеют

   некоторыенедостатки.

2. Функциональные возможности СУБД.

   Управляющимкомпонентом многих СУБД является ядро, выполняющее следующие

   функции:

     * управлениеданными во внешней памяти;

     * управлениебуферами оперативной памяти (рабочими областями, в которые

       осуществляетсяподкачка данных из базы для повышения скорости работы);

     * управлениетранзакциями.

    1. Непосредственноеуправление данными во внешней памяти.

   Эта функциявключает обеспечение необходимых структур внешней памяти, как

   для храненияданных, непосредственно входящие в базу данных так и для

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

   случаях (обычно дляэтого используется индекс).

   В некоторыхреализациях СУБД активно используется возможность существующих

   файловых систем. Вдругих работа производится вплоть до уровня устройств

   внешней памяти. Ноподчеркнем, что в развитых СУБД пользователь в любом

   случае не обязанзнать использование СУБД файловую систему и если

   использует, то, какорганизованные файлы. В частности СУБД поддерживает

   собственную системуи наименование объектов баз данных.

    2. Управление буторамиоперативной памяти.

   СУБД обычноработает с БД, по крайней мере, этот размер обычно существует,

   больше доступенобъему оперативной памяти. Что если при обращении к любому

   элементу данныхбудет производиться объем с внешней памятью, то вся

   система будетработать со скоростью устройства внешней памяти.

   Практическимединственным способом реально увеличение этой скорости

   являетсябуферизация данных в оперативной памяти. При этом даже если

   операционнаясистема производит общесистемную буферизацию. Этого не

   достаточно для целиСУБД, которая располагает гораздо больше информации о

   полезностибуферизации, т.е. той или иной части БД. Поэтому в развитых

   СУБД поддерживаетсясобственный набор буферов оперативной памяти,

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

   направления СУБД,которые ориентированно, но постоянно присутствуют в

   оперативной памятиБД. Это направление основывается на предположение, что

   на столько велик,что позволит, не беспокоится о буферизации. (Пака эта

   работа находится встадии развития).

    3. Управление транзакциями.

   Транзакция — этопоследовательность операций над БД, рассматриваемая СУБД

   как единое целое.При выполнении транзакция может быть либо успешно

   завершена, и СУБДзафиксирует произведенные изменения во внешней памяти,

   либо, например, присбое в аппаратной части ПК, ни одного из изменений не

   отразится в БД.Понятие транзакция необходимо для поддержания логической

   целостности БД.Таким образом, поддержание механизма транзакции является

   обязательнымусловием даже однопользовательских СУБД. (Если такая система

   заслуживает СУБД).Но понятие транзакция гораздо более важно много

   пользователь СУБД,то свойство, то каждая транзакция начинается при

   целостном состоянииБД и оставляет это состояние целостное после своего

   завершения, делает оченьудобным, использование понятие транзакция как

   единицы активностипользователя по отношению БД. При соответствующем

   управленииуправляющимися транзакциями со стороны СУБД каждым

   использованиемможет в принципе ощущать себя единственным пользователем

   СУБД. Управлениетранзакции многопользовательской СУБД связаны важные

   понятиясериализация транзакции и сериального плана выполнения смеси

   транзакции. Подстерилизацией выполнении параллельно сериализация понимают

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

   транзакцииэквивалентен эффекту их некоторого последовательного

   управления.Сериальный план выполнения смеси транзакции это такой план,

   который приводит ксериализация транзакции. Что если удается добиться

   действительногосериального выполнения смеси транзакции, то для каждого

   пользователя поинициативе, которой образованна транзакция присутствие

   других транзакцийбудет незаметно (если не считать некоторого замедления

   работы по сравнениюс одно пользованием режимом). Существует несколько

   базовых алгоритмовсериализация транзакции. Централизованных СУБД наиболее

   распространеныалгоритмы, основанные на синхронизации захвата объектов БД.

   При использованиилюбого алгоритма возможная ситуация конфликта между

   двумя или болеетранзакциями по доступу объекта БД. В этом случае для

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

   транзакции. Этоодин из случаев, когда пользователь многопользовательской

   СУБД может реально(и достаточно неприятно) ощутить присутствие в системе

   транзакции другихпользователей.

4. Архитектура СУБД.

   Три уровня архитектуры.

   АрхитектураANSI/SPARC включает три уровня: внутренний, концептуальный и

   внешний. В общихчертах они представляют собой следующее:

     * Внутреннийуровень-это уровень, наиболее близкий к физическому

       хранению, т.е.связанный со способами сохранения информации на

       физическихустройствах хранения.

     * Внешний уровеньнаиболее близок к пользователям, т.е. он связан со

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

     * 0x08 graphic

       0x08 graphic

       0x08 graphic

       0x08 graphic

       0x08 graphic

       0x08 graphic

       0x08 graphic

       0x08 graphic

       0x08 graphic

       0x08 graphic

       0x08 graphic

       0x08 graphic

       0x08 graphic

       0x08 graphic

       0x08 graphic

       0x08 graphic

       0x08 graphic

       0x08 graphic

       0x08 graphic

       0x08 graphic

       0x08 graphic

       0x08 graphic

       0x08 graphic

       Концептуальныйуровень-это «промежуточный» уровень между двумя

       первыми.

         Внешнийуровень (индивидуальные представления пользователей).

        Концептуальныйуровень (обобщенное представление пользователей).

                     Внутренний уровень (представление в памяти).

   Если внешнийуровень с индивидуальными представлениями пользователей, то

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

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

   которых состоит изболее или менее абстрактного представления определенной

   части БД, и можетбыть только одно концептуальное представление, состоящее

   из абстрактногопредставления БД в целом.

   Внешний уровень-этоиндивидуальный уровень пользователя. Пользователь

   может бытьприкладным программистом или конечным пользователем с любым

   уровнемпрофессиональной подготовки. Особое место среди пользователей

   занимаетадминистратор БД. (В отличие от остальных пользователей его

   интересует такжеконцептуальный и внутренний уровень.)

   У каждого пользователя естьсвой язык общения.

     * Для прикладногопрограммиста это либо один из распространенных языков

      программирования, такой как C, COBOL или PL/1, либо специальный язык

       рассматриваемойсистемы. Такие оригинальные языки называют

       (неформально!)языками четвертого поколения на том основании, что

       машинный код,язык ассемблера и такие языки, как COBOL, можно считать

       языками трехпервых «поколений», а оригинальные языки модернизированы

       по сравнению сязыками третьего поколения так же, как языки третьего

       поколенияулучшены по сравнению с языком ассемблера.

     * Для конечногопользователя это или специальный язык запросов, или язык

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

       созданныйспециально с учетом требований и поддерживаемый некоторым

       оперативнымприложением.

   Хотя с точки зренияархитектуры удобно различать подъязык данных и

   включающий егобазовый язык, на практике они могут быть неразличимыми

   настолько,насколько это имеет отношение к пользователю. Безусловно,

   сточки зренияпользователя, предпочтительнее, чтобы они неразличимы или

   трудно различимым,их называют сильно связанными. Если они ясно и легко

   различаются,говорят, что они слабо связаны. Большинство систем на

   сегодняшний деньподдерживает лишь слабую связь. Система с сильной связью

   могли быпредоставить пользователю более унифицированный набор

   возможностей, но,очевидно, требуют больше усилий со стороны системных

   проектировщиков иразработчиков (которые, вероятно, рассчитывают на

   статус-кво); однакоесть основания предполагать, что на протяжении

   следующихнескольких лет будет происходить постепенное продвижение к более

   сильно связаннымсистемам.

   Язык обработкиданных состоит из таких выполняемых операторов PL/1,

   которые передаютинформацию в и из БД; опять же, возможно, включая, новые

   специальныеоператоры.

   В общем, внешнеепредставление состоит из множества экземпляров каждого

   типа внешнейзаписи, которые, в свою очередь, отнюдь не обязательно должны

   совпадать сранимыми записями. Находящийся в распоряжении пользователя

   подъязык данныхопределен в терминах внешних записей; например, операция

   выборки языкаобработки данных будет проводить выборку из экземпляров

   внешних, а нехранимых записей.

   Концептуальный уровень.

   Концептуальноепредставление — это представление всей информации БД в

   несколько болееабстрактной форме (как и случае внешнего представления) по

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

   представлениесущественно отличается от способа представления данных

   какому-либоотдельному пользователю. Вообще говоря, концептуальное

   представление — этопредставление данных такими, какие «они есть на самом

   деле», а не такими,какими вынужден их видеть пользователь в рамках,

   например,определенного языка или используемого аппаратного обеспечения.

   Концептуальное представлениесостоит из множества экземпляров каждого типа

   концептуальнойзаписи. Например, оно может состоять из набора экземпляров

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

   содержащихинформацию о деталях и т.д. Концептуальная запись вовсе не

   обязательно должнасовпадать с внешней записью, с одной стороны, и с

   хранимой записью- сдругой.

   Концептуальноепредставление определяется с помощью концептуальной схемы,

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

   Концептуальнаясхема использует другой язык определения данных -

   концептуальный.

   Концептуальноепредставление — это представление всего содержимого базы

   данных, аконцептуальная схема — это определение такого представления.

   Однако было быошибкой полагать, что концептуальная схема — это не более

   чем наборопределений, больше напоминающих простые отношения записей в

   программе на языкеCOBOL (или каком-либо другом).

   Теперь перейдем кболее детальному исследованию трех уровней архитектуры.

   Внутренний уровень.

   Третьим уровнемархитектуры является внутренний уровень. Внутреннее

   представление — этопредставление нижнего уровня всей БД; оно состоит из

   многих экземпляровкаждого типа внутренней записи. Термин «внутренняя

   запись» принадлежиттерминологии ANSI/SPARC и означает конструкцию,

   называемую хранимойзаписью. Внутреннее представление так же, как внешнее

   и концептуальное,не связано с физическим уровнем, так как в нем не

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

   и дорожки. Другимисловами, внутреннее представление предполагает

   бесконечноелинейное адресное пространство; подробности того, как адресное

   пространствоотображено на физическое устройство хранения, очень зависят

   от системы иумышленно не включены в общую архитектуру.

   Внутреннеепредставление описывается с помощью внутренней схемы, которая

   определяет нетолько различные типы хранимых записей, но также

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

   последовательностьхранимых записей и т.д. Внутренняя схема пишется с

   использованием ещеодного языка определения данных — внутреннего.

   В заключенииотметим, что в некоторых исключительных ситуациях прикладные

   программы, вчастности те, которые называют утилитами могут выполнять

   операциинепосредственно на внутреннем, а не на внешнем уровне. Конечно,

   такой практикойпользоваться не рекомендуется; она определяет риск с точки

   зрения безопасности(правила безопасности игнорируются ) и целостности

   (правилацелостности тоже игнорируется), к тому же программа будет

   зависеть отзагруженных данных; но иногда это может быть единственным

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

   быстродействия — так же, как пользователю языка высокого уровня иногда по

   тем же причинамнеобходимо прибегнуть к языку ассемблера.

   Приложения,использующие базы данных, обычно принято относить к одной из

   программныхархитектур, имеющих свои плюсы и минусы.

   Локальная архитектура.

   И программа, и базаданных расположены на одном компьютере. В такой

   архитектуреработает большинство настольных приложений.

   Файл — серверная архитектура.

   База данныхрасположена на мощном выделенном компьютере (сервере), а

   персональныекомпьютеры подключены к нему по локальной сети. На этих

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

   по сети.Преимущество такой архитектуры заключается в возможности

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

   Недостаток такогоподхода — большие объемы информации, передаваемой по

   сети. Вся обработкавыполняется на клиентских местах, где фактически

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

   возможного числапользователей и большим задержкам при работе с базой. Эти

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

   доступ невозможный.Пока программа на одном из клиентских мест не закончит

   работу с таблицей(например, не выполнит модификацию записей), другие

   программы не могутобращаться к этой таблице. Это называется блокировкой

   на уровне таблицы иисключает возникновение путаницы в ее содержимом.

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

   В такой архитектурена сервере не только хранится БД, но и работает

   программа СУБД,обрабатывающая запросы пользователей и возвращающая им

   наборы записей. Приэтом программы пользователей уже не работают,

   например, с БД какнабором физических фалов, а обращаются к СУБД, которая

   выполняет операции.Нагрузка с клиентских мест при этом снимается, так как

   большая частьработы происходит на сервере. СУБД автоматически следит за

   целостностью исохранностью БД, а также контролирует доступ к информации с

   помощью службыпаролей. Клиент — серверные СУБД допускают блоки на уровне

   записи и дажеотдельного поля. Это означает, что с таблицей может работать

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

   или одного из ееполей обеспечен только одному из них.

   Основной недостатокэтой архитектуры не очень высокая надежность. Если

   сервер выходит изстрой, вся работа останавливается.

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

   В сети работаетнесколько серверов, и таблицы баз данных распределены

   между ними длядостижения повышенной эффективности. На каждом сервере

   функционирует своякопия СУБД. Кроме того, в подобной архитектуре обычно

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

   позволяютоптимизировать обработку запросов большого числа пользователей и

   равномернораспределить нагрузку между компьютерами в сети.

   Недостатокраспределенной архитектуры заключается в довольно сложном и

   дорогостоящемпроцессе ее создания и сопровождения (администрирования), а

   также а высокихтребованиях к сервером компьютерам.

   Интернет — архитектура.

   Доступ к базеданных и СУБД (распространенных на одном компьютере или в

   сети)осуществляется из броузера по стандартному протоколу. Это

   предъявляетминимальные требования к клиентскому оборудованию. Такие

   программы называют«тонкими клиентами», потому что они способны работать

   даже на ПК спроцессором 80386. Благодаря стандартизации всех протоколов и

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

   серверу черезИнтернет в локальной сети (в таком случае говорят о

   технологияхинтранет). В этом случае не требуется разрабатывать

   специальныеклиентские программы или придумывать собственные спецификации

   обмена даннымимежду сервером и клиентскими местами. Достаточно

   использоватьготовые броузера и программные решения.

4. Типы СУБД.

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

   предназначенную длясоздания на ЭВМ общей базы данных для множества

   приложений,поддержания ее ак

еще рефераты
Еще работы по программированию, базе данных