Оптимизация структуры базы данных

1) Нормализация таблиц.

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

В теории нормализация таблиц проводится до ЗНФ или БКНФ, что формирует несколько относительно мелких таблиц. Однако при обращений к одной, пусть большой таблице затрачивается меньше времени, чем при обращении к нескольким меньшим таблицам.

Например, в БД Klinika существует 5 таблиц: ВРАЧ, СПЕЦИАЛЬНОСТЬ, ПАЦИЕНТ, ПРОЦЕДУРА, НАЗНАЧЕНИЕ. Для того, чтобы выбрать назначения врачей определенной специальности, необходимо установить следующую связь:

Пациент

З

Специальность

Врач

Назначение

апрос

н

Процедура

а выбор

Если же привести структуру к виду, где таблица ВРАЧ будет частично нормализована:

Пациент

Процедура

З

Врач + Специальность

Назначение

апрос

на выбор

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

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

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

2) Зависимость структуры данных от методов доступа к ним.

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

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

Например: пусть в БД существуют 2 таблицы: Расход и Товар. При формировании заявки на покупку общая сумма значений поля количество_расхода в таблице Расход должно быть меньше количества_товара в таблице Товар. Но при одновременной работе 2 операторов может возникнуть ситуация, когда одна транзакция, выполняя изменения, блокирует выполнение другой транзакции. И поэтому когда вторая транзакция будет модифицировать БД, данные могут быть изменены некорректно (например, отрицательные значения).

Поэтому в целях оптимальной работы нескольких пользователей следует в структуру таблицы Товар ввести поле STATUS tinyint. С возможными значениями 0 или 1. Тогда при выполнении первой транзакции изменения записи таблицы STATUS будет выполняться оператор

UPDATE ТОВАР SET STATUS=l WHERE TOVAR=:TOV,

где TOV - первичный ключ изменяемой записи.

После окончания работы транзакции значение поля STATUS изменяется на 0.

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