Классификация СУБД

    По способу доступа к БД:

        ·        
Файл-серверные

    В файл-серверных СУБД файлы данных
располагаются централизованно на файл-сервере. СУБД располагается на каждом
клиентском компьютере (рабочей станции). Доступ СУБД к данным осуществляется
через локальную сеть. Синхронизация чтений и обновлений осуществляется посредством
файловых блокировок. Преимуществом этой архитектуры является низкая нагрузка на
процессор файлового сервера. Недостатки: потенциально высокая загрузка
локальной сети; затруднённость или невозможность централизованного управления;
затруднённость или невозможность обеспечения таких важных характеристик как
высокая надёжность, высокая доступность и высокая безопасность. Применяются
чаще всего в локальных приложениях, которые используют функции управления БД; в
системах с низкой интенсивностью обработки данных и низкими пиковыми нагрузками
на БД.
На данный момент файл-серверная
технология считается устаревшей.
Примеры:
Microsoft Access, Paradox, dBase, FoxPro, Visual FoxPro.

        ·        
Клиент-серверные

    Клиент-серверная СУБД располагается
на сервере вместе с БД и осуществляет доступ к БД непосредственно, в
монопольном режиме. Все клиентские запросы на обработку данных обрабатываются
клиент-серверной СУБД централизованно. Недостаток клиент-серверных СУБД состоит
в повышенных требованиях к серверу. Достоинства: потенциально более низкая
загрузка локальной сети; удобство централизованного управления; удобство
обеспечения таких важных характеристик как высокая надёжность, высокая
доступность и высокая безопасность.
Примеры:
Oracle, Firebird, Interbase, IBM DB2, Informix, MS SQL Server, Sybase Adaptive
Server Enterprise, PostgreSQL, MySQL, Caché, ЛИНТЕР.

·        
Встраиваемые

    Встраиваемая СУБД — СУБД, которая
может поставляться как составная часть некоторого программного продукта, не
требуя процедуры самостоятельной установки. Встраиваемая СУБД предназначена для
локального хранения данных своего приложения и не рассчитана на коллективное
использование в сети. Физически встраиваемая СУБД чаще всего реализована в виде
подключаемой библиотеки. Доступ к данным со стороны приложения может
происходить через SQL
либо через специальные программные интерфейсы.
Примеры:
OpenEdge, SQLite, BerkeleyDB, Firebird Embedded, Microsoft SQL Server Compact,
ЛИНТЕР.

По степени распределённости:    

    ·        
Локальные СУБД (все части локальной СУБД
размещаются на одном компьютере)
    ·        
Распределённые СУБД (части СУБД могут
размещаться на двух и более компьютерах).

По модели данных, примеры:

    ·        
Иерархические
    ·        
Сетевые
    ·        
Реляционные
    ·        
Объектно-ориентированные
    ·        
Объектно-реляционные

ЧТО ТАКОЕ ПРАВИЛЬНАЯ БАЗА ДАННЫХ?

    Стоит запомнить  два общих принципа построения “правильной
базы данных”. Во-первых, нужно постараться обеспечить целостность (правильность)
и непротиворечивость данных в БД: физическую сохранность данных, предотвращение
неверного использования данных (например, ввода недопустимых значений),
контроль операций вставки, обновления и удаления данных, защиту от несанкционированного
доступа и т.д. Во-вторых, надо поддерживать минимальную избыточность данных.
Любой элемент данных должен храниться в базе в единственном экземпляре, чтобы
не дублировались операции, производимые над ним.
     За хранение
данных в базе, их обработку и взаимодействие с прикладными программами отвечает
отдельный класс программ – системы управления базами данных (например Op Base, MS Access, FoxPro, MS SQL Server,
Oracle и другие). Они отличаются друг от друга функциональностью, производительностью,
стоимостью и т.п., но, в принципе, все предназначены для решения вышеуказанных
задач. Чтобы заставить СУБД правильно выполнять свои функции и сопровождать
базу данных, необходимо организовать работу так, чтобы соблюдались оба
принципа. Иначе придется в основном бороться с самой СУБД.
    При построении “правильной базы данных”
многое зависит от ее структуры, то есть схемы. Из каких таблиц и атрибутов
должна состоять схема базы данных? Какие атрибуты выбрать в качестве ключевых?
Надо ли связывать эти таблицы между собой? Подобные вопросы могут возникнуть у
кого угодно, и чтобы ответить на них, требуется научиться моделировать схему
базы данных. Для этого были придуманы специальные диаграммы
“сущность-связь” (ER-диаграммы), которые позволяют легко и наглядно
проектировать структуру баз данных без привязки к конкретным СУБД. Методика,
согласно которой используются ER-диаграммы, оказалась настолько успешной и
полезной на практике, что легла в основу целого класса программных продуктов,
так называемых CASE-средств проектирования информационных систем. Наиболее
распространенная программа этого класса – Erwin
    Главная проблема, которую требуется решить при
создании базы данных – создать для нее такую структуру, которая бы обеспечивала
минимальное дублирование информации и упрощала процедуры обработки и обновления
данных, представленных набором таблиц. Для решения этой проблемы был предложен
универсальный способ. Этот способ сформулирован в виде специальных требований к
организации данных в ходе проектирования, которые получили названия нормальных
форм (НФ). Первые три нормальные формы оказались самыми живучими и распространились
больше других.
     Согласно
требованиям первой нормальной формы, все атрибуты таблицы должны быть простыми,
то есть состоять из одного неделимого элемента данных. Например, если сделать в
базе данных атрибут “Адрес”, то в него можно будет заносить значения
данных типа “г. Москва, 3-я улица Строителей, д. 25, кв. 12”. Но определить,
из какого города человек с таким адресом и существует ли такой же адрес в
другом городе будет очень сложно, потому что придется писать целую процедуру обработки
текстовой записи, чтобы вычленить город.
     Вторая
нормальная форма требует соблюдения условий первой НФ, а также дополнительно
каждый не ключевой атрибут должен однозначно зависеть только от первичного ключа.
Имеются в виду функциональные зависимости из реальной предметной области. Здесь
возникают проблемы с выявлением зависимостей, если первичный ключ является
составным, то есть состоит из нескольких атрибутов.

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