Объектно‑ориентированная модель.

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

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

Объектно‑ориентированную модель можно представить в виде дерева объ­ек­тов‑классов. У каждого объекта имеется набор свойств. Свойство типа “класс” есть экземпляр соот­вет­ствующего класса, который яв­ляет­ся потомком объекта, в котором он определен как свойство.

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

Примеры СУБД: POET (POET Software), Jasmine (Computer Asso­ciates), Versant (Versant Technologies), O2 (Ardent Software), ODB‑Jupiter (НПЦ “Интеллект Плюс”), Iris, Orion, Postgres.

6. Механизмы транзакций и блокировок. Триггеры, хранимые процедуры: определение и назначение.

Транзакция - это логическая единица обработки базы данных, пере­во­дящая базу данных из одного его целостного состояния в другое.

Например, перевод денег со счета А на счет В.

Тран­зак­ция может состоять из группы операторов SQL, которая начинается с команды Begin Tran [<имя транзакции>] (начать тран­закцию) и закан­чи­вается оператором Commit Tran [<имя тран­зак­ции>] (завершить транзакцию: зафиксировать в базе все изме­не­ния, произ­ве­ден­ные после начала тран­зак­ции). Commit Tran имеет 2 фазы: предварительная и окончательная. При ава­рий­ном завершении транзакции (например, отклю­чи­ли элек­тро­питание) база останется в рабочем сос­тоянии на момент начала тран­закции. Если внутри транзакции указать оператор Rollback Tran [<имя транзакции или точки сохранения>], то все изменения отменяются, и база восста­нав­ли­ва­ется на момент начала тран­­закции (откат назад) или точки сохранения. Точка сохранения (аналог поименованной транзакции) задается в виде Save Transaction [<имя точ­ки>]. Все транзакции сох­раняются в журнале тран­зак­ции, который ис­поль­­зу­ется для вос­ста­нов­ле­ния базы данных из архивной копии.

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

Блокировка – команда, блокирующая ресурсы, обычно на время корректировки ресурсов.

По умолчанию каждая команда SQL является транзакцией.

Основным средством реализации алгоритмов обработки данных яв­ля­ются хранимые процедуры, которые выполняются на сервере. При на­пи­са­нии этих процедур используются команды языка запросов SQL. Хранимая процедура хранится и выполняется СУБД на сервере базы данных.

Хранимая процедура создается/изменяется командой SQL:

Create/Alter Procedure

Триггеры

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

7. Нормализация отношений с примерами (1НФ, 2НФ, 3НФ).

Метод нормализации отношения (таблицы) ‑ это процесс постепен­но­го улуч­ше­ния от­но­шения (таблицы) путем последовательного перевода отношения (таблицы) из ненор­мализо­ван­ной формы в первую, во вторую, в третью (иногда в четвертую и пятую) нормальные формы.

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

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

Пример ненормализованной таблицы

ИЗДЕЛИЯ (Код изделия, список деталей). Может встретиться из­делие, которое содержит список из нескольких деталей.

Виды зависимостей между атрибутами

Атрибут (группа атрибутов) В функционально зави­сит от атрибута (группы атрибутов) A, если каждому значению A соответ­ст­­­вует одно зна­че­ние B. Такая зависимость изображается в виде A-->B (Табельный но­­мер -->Фамилия сотрудника).

Если существует функциональная зависимость вида A-->B и B-->A, то имеет место функциональная взаимозависимость, кото­рая изобра­жа­ет­ся в виде A<-->B (Табельный номер <-->Номер паспорта сотрудника).

Частичная функциональная зависимость ‑ это зависи­мо­сть не­клю­чевого атрибута от части составного ключа, а не от всего ключа.

Полной функциональной зависимостью называется зависимость неключевого атрибута от всего ключа.

Атрибут C транзитивно зависит от атрибута А, если выполняются условия A-->B и B-->C, но обратная зависимость отсутствует.

Многозначные зависимости вида 1:M, M:1, M:M между атрибутами

A и B изображаются в виде A-->>B, A<<--B и A<<-- >>B соответственно.

Первая нормальная форма (1НФ)

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

Пример. Преобразуем таблицу “ИЗДЕЛИЯ” из предыдущего при­мера в таблицу вида: ИЗДЕЛИЯ (код изделия, деталь). Тогда, за счет дублирования кода изделия, в каждой строке в колонке “Деталь” будет стоять только одно значение ‑ наименование кода детали. Новая таб­лица будет в первой нормальной форме.

Покажем процесс нормализации на следующей исходной таблице:

ВЫПУСК ИЗДЕЛИЙ (Код подразделения (KP), наименование подразделе­ния (NP), код изделия (KI), наименование изделия (NI), код типа изделия (KTI), наименование типа изделия (NTI), дата выпуска (DVI), количество (KVI), себестоимость изделия (SI)). Ключевые атрибуты пер­вич­ного клю­ча подчеркнуты. Эта таблица находится в первой нормальной форме.

Рассмотрим аномалии (недостатки) первой нормальной формы.

1.      Избыточное дублирование данных. Все наименования будут дублироваться в каждой строке нашей таблицы.

2.      Аномалия включения. Пока изделие не будет выпущено, инфор­ма­ция о нем (проектируемом или ранее снятом с производства) бу­дет отсутствовать в базе.

3.      Аномалия удаления. Если изделие не выпускается в отчетный пе­ри­од, то инфор­ма­ция об изделии исчезнет из базы.

4.      Аномалия корректировки. Если меняется, например, название из­де­лия, то нужно откорректировать наименование не в одной строке, а во всех строках таб­ли­цы, где оно встречается.

Для устранения этих недостатков продолжим процесс нормализации.

Вторая нормальная форма (2НФ)

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

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

Атрибут “Наименование под­раз­де­ления” зависит только от атрибута “Код подразделения” и не зависит от атрибутов “Код изделия” и “Дата вы­пус­ка”. Поэтому его следует удалить из таблицы. Чтобы не потерять ин­формацию о подразделении создадим но­вую таблицу “ПОДРАЗДЕЛЕ­НИЯ” и в нее включим удаляемый атрибут “Наиме­но­ва­ние подразделения” вместе с ключевым атрибутом “Код подразделения” (иначе потеряется связь с таб­лицей “ВЫПУСК ИЗДЕЛИЙ”) и получим таб­лицу вида:

ПОДРАЗДЕЛЕНИЯ (Код подразделения, наименование под­раз­де­ления).

Атрибут “Наименование изделия” зависит только от атрибута “Код изделия” и не зависит от остальных ключевых атрибутов. Аналогично пре­ды­дущему случаю, удалим его из таблицы в новую таб­­лицу:

ИЗДЕЛИЯ (Код изделия, наименование изделия).

Атрибут “Код типа изделия” зависит только от атрибута “Код из­де­лия” и не зависит от атрибутов “Код подразделения” и “Дата выпус­ка”. Ана­логично предыдущему случаю удалим его из таблицы, добавим в таб­­­лицу “ИЗДЕЛИЯ” и получим таблицу:

ИЗДЕЛИЯ (Код изделия, наименование изделия, код типа изделия).

Атрибут “Наименование типа изделия” зависит только от атрибута “Код из­де­лия”. Ана­логично предыдущему случаю удалим его из таблицы и добавим в таб­­­лицу “ИЗДЕЛИЯ” и получим таблицу:

ИЗДЕЛИЯ (Код изделия, наименование изделия, код типа изделия, наиме­но­вание типа изделия).

Атрибуты “Количество” и “Себестоимость изделия” зависят от все­го ключа, поэтому оставим их в исходной таблице.

Таким образом, получим три таблицы:

ВЫПУСК ИЗДЕЛИЙ (Код подразделения, код изделия, дата выпуска, коли­чество, себестоимость изделия).

ПОДРАЗДЕЛЕНИЯ (Код подразделения, наименование под­раз­де­ления).

ИЗДЕЛИЯ (Код изделия, наименование изделия, код типа изделия, наиме­но­вание типа изделия).

Очевидно, что все они находятся во второй нормальной форме.

 

Третья нормальная форма (3НФ)

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

Очевидно, что первые две таблицы удовлетворяют определению треть­ей нормальной формы. Рассмотрим таблицу “ИЗДЕЛИЯ”.

Атрибут “Наиме­но­вание типа изделия” функционально зависит от неключевого атрибута “Код типа изделия”, поэтому его следует удалить (по определению третьей нормальной формы) из таблицы в новую:

ТИПЫ ИЗДЕЛИЙ (Код типа изделия, наиме­но­вание типа изделия).

В результате получим модель базы данных из че­ты­рех таблиц в третьей нормальной форме (рис. 1.5.2.1):

ВЫПУСК ИЗДЕЛИЙ (Код подразделения, код изделия, дата выпуска, коли­чество, себестоимость изделия).

ПОДРАЗДЕЛЕНИЯ (Код подразделения, наименование под­раз­де­ления).

ИЗДЕЛИЯ (Код изделия, наименование изделия, код типа изделия).

ТИПЫ ИЗДЕЛИЙ (Код типа изделия, наиме­но­вание типа изделия).

 

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

История развития баз данных и СУБД.

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

Первый этап развития СУБДсвязан с организацией баз данных на больших машинах типаIBM360/370, ЕС-ЭВМ и мини-ЭВМ типаPDP11 (фирмыDigitalEquipmentCorporation–DEC), разных моделяхHP(фирмыHewlettPackard). Базы данных хранились во внешней памяти центральной ЭВМ, пользователями этих баз данных были задачи, запускаемые в основном в пакетном режиме.

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

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

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

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

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