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

К современным базам данных, а, следовательно, и к СУБД, на которых они строятся, предъявляются следующие основные требования:

· Высокое быстродействие (малое время отклика на запрос). Время отклика - промежуток времени от момента запроса к БД до фактического получения данных.

· Простота обновления данных.

· Независимость данных - возможность изменения логической и физической структуры БД без изменения представлений пользователей.

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

· Безопасность данных - защита данных от преднамеренного или непреднамеренного нарушения секретности, искажения или разрушения.

· Стандартизация построения и эксплуатации БД (фактически СУБД).

· Адекватность отображения данных соответствующей предметной области.

· Простой интерфейс пользователя.

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

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

· отсутствие неточно введенных данных или двух одинаковых записей об одном и том же факте;

· защиту от ошибок при обновлении БД;

· невозможность удаления (или каскадное удаление) связанных данных разных таблиц;

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

· сохранность данных при сбоях техники (восстановление данных).

Целостность обеспечивается триггерами целостности - специальными приложениями-программами, работающими при определенных условиях. Защита данных от несанкционированного доступа предполагает ограничение доступа к конфиденциальным данным и может достигаться:

· введением системы паролей;

· получением разрешений от администратора базы данных (АБД);

· запретом от АБД на доступ к данным;

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

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

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

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

14.СИСТЕМНЫЙ АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ.ИНФОРМАЦИОННО-ЛОГИЧЕСКОЕ ПРОЕКТИРОВАНИЕ.

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

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

· Концептуальное моделирование - создание модели "сущность-связь" на основе перечня объектов, полученного на предыдущем этапе.

· Реляционное моделирование - преобразование модели "сущность-связь" в соответствии с требованиями реляционной модели

· Генерация схемы базы данных.

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

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

15.ИЗБЫТОЧНОСТЬ ДАННЫХ И АНОМАЛИИ ОБНОВЛЕНИЯ В БД.ФУНКЦИОНАЛЬНЫЕ ЗАВИСИМОСТИ МЕЖДУ АТРИБУТАМИ.

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

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

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

Т.е., если в отношении R, содержащем атрибуты А и В, атрибут В функционально зависит от атрибута А, то каждое отдельное значение атрибута А связано только с одним значением атрибута В.

16.НОРМАЛИЗАЦИЯ ОТНОШЕНИЙ.ПРЕОБРАЗОВАНИЕ ЕR-МОДЕЛИ В СХЕМУ РЕЛЯЦИОННОЙ БД.

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

Отношение — конечное множество кортежей (таблица).

Есть 2 формы отношений:

Первая форма отношений и Вторая форма отношений (да да это именно так и я не придурок! Хотя….)

Модель сущность-связь (Entity/RelationshipModel), сокращенно – «ER-модель»

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

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

17.ФИЗИЧЕСКОЕ ПРОЕКТИРОВАНИЕ.ОСОБЕННОСТИ, ВЛИЯЮЩИЕ НА ОРГАНИЗАЦИЮ ВНЕШНЕЙ ПАМЯТИ. ТЕХНОЛОГИИ ХРАНЕНИЯ ДАННЫХ.

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

18.СУБД:ОСНОВНЫЕ ФУНКЦИИ,ТИПЫ. СВОЙСТВА И СРАВНИТЕЛЬНАЯ ХАРАКТЕРИСТИКА СУБД.

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

Основные функции СУБД:

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

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

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

· Журнализация

· Поддержка языков БД

Свойства СУБД:

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

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

· Большинство СУБД могут работать на компьютерах с разной архитектурой и под разными операционными системами.

· Многопользовательские СУБД имеют достаточно развитые средства администрирования БД.

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

Сравнительная характеристика СУБД.

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

Можно сравнить допустим СУБД Oracle и СУБД Microsoft SQL Server. У каждой есть свои плюсы и минусы.

19.МОДЕЛЬ «КЛИЕНТ-СЕРВЕР» В ТЕХНОЛОГИИ БД. СХЕМА.ОСНОВНЫЕ ФУНКЦИИ КЛИЕНТА,ПОНЯТИЕ СЕРВЕРА И КЛИЕНТА.

МОДЕЛЬ «КЛИЕНТ-СЕРВЕР» - это разделение труда между компьютерами. Компьютеры, предоставляющие услуги, которые используют другие компьютеры, называются серверами. Компьютер, который пользуется услугами другого компьютера, называется клиентом.

СХЕМА РАБОТЫ МОДЕЛИ.

20.МОДЕЛЬ ФАЙЛОВОГО СЕРВЕРА. СХЕМА,ОСНОВНЫЕ Ф-ЦИИ КЛИЕНТА. СПОСОБ ОРГАНИЗАЦИИ ОБМЕНА ДАННЫМИ МЕЖДУ КЛИЕНТОМ И СЕРВЕРОМ,ПРЕИМУЩЕСТВА,НЕДОСТАТКИ.

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

Модель файлового сервера В FS-модели все основные компоненты размещаются на клиентской установке. При обращении к данным ядро СУБД, в свою очередь, обращается с запросами на ввод-вывод данных за сервисом к файловой системе. С помощью функций операционной системы в оперативную память клиентской установки полностью или частично на время сеанса работы копируется файл базы данных. Таким образом, сервер в данном случае выполняет чисто пассивную функцию. Достоинством данной модели являются ее простота, отсутствие высоких требований к производительности сервера (главное - требуемый объем дискового пространства). Следует также отметить, что программные компоненты СУБД в данном случае не распределены, т. е. никакая часть СУБД на сервере не инсталлируется и не размещается. С другой стороны также очевидны и недостатки такой модели. Это, прежде всего, высокий сетевой трафик, достигающий пиковых значений особенно в момент массового вхождения в систему пользователей, например в начале рабочего дня - razgovorodele.ru. Однако более существенным с точки зрения работы с общей базой данных является отсутствие специальных механизмов безопасности файла (файлов) базы данных со стороны СУБД. Иначе говоря, разделение данных между пользователями (параллельная работа с одним файлом данных) осуществляется только средствами файловой системы ОС для одновременной работы нескольких прикладных программ с одним файлом. Несмотря на очевидные недостатки, модель файлового сервера является естественным средством расширения возможностей персональных (настольных) СУБД в направлении поддержки многопользовательского режима и, очевидно, в этом плане еще будет сохранять свое значение.

21.МОДЕЛЬ СЕРВЕРА БАЗ ДАННЫХ. СХЕМА,ОСНОВНЫЕ Ф-ЦИИ КЛИЕНТА. СПОСОБ ОРГАНИЗАЦИИ ОБМЕНА ДАННЫМИ МЕЖДУ КЛИЕНТОМ И СЕРВЕРОМ,ПРЕИМУЩЕСТВА,НЕДОСТАТКИ.

Модель сервера баз данных (DBS) -реализована в некоторых реляционных СУБД (Informix, Ingres, Sybase, Oracle), (рис.5.3).

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

Клиент Вызов Сервер

Компонент Прикладной Компонент доступа к

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

Рис.5.3.Модель сервера баз данных

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

Достоинства DBS-модели:

· возможность централизованного администрирования прикладных функций;

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

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

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

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

22.АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ ПРОЕКТИРОВАНИЯ БД. ОСНОВНЫЕ ВОЗМОЖНОСТИ CASE-СРЕДСТВ. КЛАССИФИКАЦИЯ CASE-СРЕДСТВ.

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

САПР - это не системы автоматического проектирования. Понятие “автоматический” подразумевает самостоятельную работу системы без участия человека. В САПР часть функций выполняет человек, а автоматическими являются только отдельные проектные операции и процедуры. Слово “автоматизированный”, по сравнению со словом “автоматический”, подчёркивает участие человека в процессе.

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

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

CASE средства (Computer - Aided Software Engineering) – это инструмент, который позволяет автоматизировать процесс разработки информационной системы и программного обеспечения.

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

В функции CASE входят средства анализа, проектирования и программирования программных средств, проектирования интерфейсов, документирования и производства структурированного кода на каком-либо языке программирования.^[4]

CASE-инструменты классифицируются по типам и категориям.

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

· средства анализа — предназначены для построения и анализа модели предметной области;

· средства проектирования баз данных;

· средства разработки приложений;

· средства реинжиниринга процессов;

· средства планирования и управления проектом;

· средства тестирования;

· средства документирования.

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

Типичными CASE-инструментами являются:

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

· инструменты моделирования данных;

· инструменты анализа и проектирования;

· инструменты преобразования моделей;

· инструменты редактирования программного кода;

· инструменты рефакторинга кода;

· генераторы кода;

· инструменты для построения UML-диаграмм.

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

23.ОБЕСПЕЧЕНИЕ ФУНКЦИОНИРОВАНИЯ БД. ТРАНЗАКЦИИ: ПОНЯТИЯ, МОДЕЛИ ЗАВЕРШЕНИЯ, СВОЙСТВА. УПРАВЛЕНИЯ ТРАНЗАКЦИЯМИ.

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

Транза́кция (англ. transaction) — группа последовательных операций с базой данных, которая представляет собой логическую единицу работы с данными. Транзакция может быть выполнена либо целиком и успешно, соблюдая целостность данных и независимо от параллельно идущих других транзакций, либо не выполнена вообще, и тогда она не должна произвести никакого эффекта. Транзакции обрабатываются транзакционными системами, в процессе работы которых создаётся история транзакций.

Понятие транзакции имеет непосредственную связь с понятием целостности БД. Очень часто БД может обладать такими ограничениями целостности, которые просто невозможно не нарушить, выполняя только один оператор изменения БД.

Совокупность команд SQL, результаты действия которых еще не стали постоянными, называется транзакцией или логической единицей работы. В упрощенном представлении, транзакции содержат либо команды DML, выполняющие единое согласованное изменение данных, либо одну команду DDL или DCL.

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

Плоские, или традиционные, транзакции, характеризуются четырьмя классическими свойствами: атомарности, согласованности, изолированности, долговечности (прочности) — ACID (Atomicity, Consistency, Isolation, Durability).

24. ОБЕСПЕЧЕНИЕ ФУНКЦИОНИРОВАНИЕ БД. ЖУРНАЛИЗАЦИЯ:ОТКАТ ТРАНЗАКЦИИ, ВОССТАНОВЛЕНИЕ ДАННЫХ В РЕЗУЛЬТАТЕ СБОЯ.

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

ОТКАТ ТРАНЗАКЦИИ (rollback, transaction rollback). Действия, выполняемые СУБД при обработке транзакций в том случае, когда успешного завершения транзакции не произошло. О. т. заключается в том, что отменяются результаты всех операций транзакции, а данные возвращаются в то исходное состояние, которое они имели до начала выполнения транзакции. О. т. может быть вызван различными причинами: 1) О. т. может быть выполнен по инициативе самой транзакции, например, если в процессе ее выполнения обнаруживается, что завершение транзакции приведет к нарушению целостности данных; 2) О. т. может быть вызван машинным сбоем в процессе выполнения транзакции; 3) О. т. может быть выполнен по инициативе СУБД для выхода из тупиковой ситуации. Ср. завершение транзакции

Восстановление базы данных — функция СУБД, которая в случае логических и физических сбоев приводит базу данных в актуальное и консистентное состояние.

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

В случае физического отказа, если ни журнал изменений, ни сама база данных не повреждены, то выполняется процесс прогонки (rollforward). Журнал сканируется в прямом направлении, начиная от предыдущей контрольной точки. Все записи извлекаются из журнала вплоть до конца журнала. Извлеченная из журнала информация вносится в блоки данных внешней памяти, у которых отметка номера изменений меньше, чем записанная в журнале. Если в процессе прогонки снова возникает сбой, то сканирование журнала вновь начнётся сначала, но восстановление фактически продолжится с той точки, где оно прервалось.

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

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

25. ОБЕСПЕЧЕНИЕ ФУНКЦИОНИРОВАНИЕ БД. ПРОБЛЕМЫ МНОГОПОЛЬЗОВАТЕЛЬСКИХ СИСТЕМ. КОНФЛИКТЫ МЕЖДУ ТРАНЗАКЦИЯМИ.

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

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

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

ПРОБЛЕМЫ МС:

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

2.Проблема несогласованных данных;

3.Проблема несовместного анализа.

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

W-W (Запись - Запись). Первая транзакция изменила значение и не закончилась. Вторая транзакция пытается изменить это значение. Результат - потеря обновления.

R-W (Чтение - Запись). Первая транзакция считала значение и не закончилась. Вторая транзакция пытается изменить это значение. Результат - несовместимый анализ данных (неповторяемое считывание).

W-R (Запись - Чтение). Первая транзакция изменила значение и не закончилась. Вторая транзакция пытается считать это значение. Результат - чтение "грязных" данных. Конфликты типа R-R (Чтение - Чтение) отсутствуют, т.к. данные при чтении не изменяются.

26. ОБЕСПЕЧЕНИЕ ФУНКЦИОНИРОВАНИЕ БД.ТРИГГЕРЫ:ПОНЯТИЕ,ПРАВИЛО СОЗДАНИЕ.ХРАНИМЫЕ ПРОЦЕДУРЫ:ПОНЯТИЕ,ВИДЫ,ПРЕИМУЩЕСТВА ИСПОЛЬЗОВАНИЯ.

Три́ггер (англ. trigger) — это хранимая процедура особого типа, которую пользователь не вызывает непосредственно, а исполнение которой обусловлено действием по модификации данных: добавлением INSERT, удалением DELETE строки в заданной таблице, или изменением UPDATE данных в определённом столбце заданной таблицы.

Храни́мая процеду́ра — объект базы данных, представляющий собой набор SQL-инструкций, который компилируется один раз и хранится на сервере.

По числу строк, возвращаемых в качестве результата, можно выделить следующие виды хранимых процедур:
1. возвращающие одну строку;
2. возвращающие несколько строк.