Кратко введу в курс дела... :)
Есть событие – цунами. Таблица TsunamiTable описывает различные цунами. Есть данные о разрушениях от цунами, они хранятся в таблице DamageTable; данные о высотах цунами, они хранятся в HeightTable; данные об экономических потерях, они хранятся в LossTable, фото данные, они хранятся в PhotoTable, текстовые описания, они хранятся в TextTable. Причем между ними реализуется связь “многие к одному”, то есть могут быть различные данные для одного конкретного цунами. Существуют также публикации (в журналах, газетах и тд и тп) – таблица BiblioTable, и международные агентства – таблица AgencyTable, которые предоставляют какую то стандартную информацию о произошедшем цунами. Различные агентства (AgencyTable) могут предоставлять различную информацию о конкретном цунами, что и реализовано с помощью переходной таблицы AddInfoTable. Аналогично в различных публикациях (BiblioTable) могут упоминаться различные цунами, что и реализовано с помощью переходной таблицы BiblioLinksTable. ID_Add, ID_Loss, ID_Dam – ссылки на наиболее достоверную информацию о цунами в таблицах AddInfoTable, LossTable, DamageTable. В таблицах есть различные поля (i_Pi, FAT, I, m и тд и тп) и ссылки на публикации в которых упоминаются эти данные (Ri_Pi, RFAT, RI, Rm и тд и тп). То есть RI является как бы внешним ключом к BiblioTable.ID. Причем как видно из схемы – связи для ссылок в виде внешних ключей не реализованы.
Поставлена задача об оптимизации структуры базы данных. Как на ваш взгляд есть ли какие-то серьезные недостатки проектирования у текущей структуры?

2 gardenman: Запросы всякие разные - сортировка, поиск , удаление и вставка и тд и тп.

2 Shtock : Высоты это показания датчиков которые находятся в различных реионах и тд и тп.
Но про текстовое описание верно подметили :)
Место вводить не надо так как оно есть в таблице цунами TsunamiTable.
Сорри упущение - ссылка на цунами в различных таблицах это MainID.

2 softwarer : Насчет имен все верно - предыдущий разработчик в этом ошибся :)

2 4321 :
Еще может какие нить критические замечания?
Справочники по Area и Region - эт стопудово верно! :)

Если еще есть вопросы то задавайте ! С радостью отвечу.
Спасибо всем за текущие замечания

Хорошо, распишу все явно и подробно на русском языке, как я сам понимаю.
Цунами характеризуется (Год, месяц, день, час, секунда, числовые параметры(интенсивности и тд), + ссылка на публикацию, ссылка на наиболее достоверные экономические потери, стандартную информацию, и параметры разрушений).
Высоты цунами характеризуются (название региона(страны), название области(остров или страна) , показания датчиков, координаты положения датчиков + ссылки на публикации, упоминающие данные показания).
Публикация характеризуется текстовыми полями такими как Авторы(просто перечисление), Ключевые слова и тд
Стандартная информация (тоже какие то числовые параметры) характеризуется тем из какого Агенства она взята, и ссылки на публикации, упоминающие эти параметры.
Таблица связей публикаций характеризуется публикациями и цунами.
То есть в каких публикациях какие цунами упоминаются. типа связь "многие к многим".
Ну а остальные это да - текстовые файлы с описаниями, фото файлы с картинками с места происшествия.

2 ModelR : Сорри - что то не пойму про обьединение фалов. В таблицах TextTable, PhotoTable хранятся имена на текстовые файлы и фото файлы соответственно. Причем картинок может быть очень много для конкретного цунами. А вот текстовое описание в 1 файле.

А про регионы и области - что можете посоветовать? Так как да там появляется некая избыточность - сам смотрел в базе данных там в основном везде повторяется Japan, Japan ...

Вот действительно непонятно с ссылками на публикации, вроде и связь на публикации о конкретном цунами реализована через промежуточную таблицу BiblioLinksTable. Но еще должны быть связи между отдельными параметрами (Ri, Rm) и публикациями. Ну вроде эта связь реализована в коде - но не как в виде внешнего ключа.
А чтобы ее реализовать нужно создать промежуточные таблицы для каждой таблицы, содержащей ссылки на публикации - так что ли?
И вот еще непонятно с ссылками на наиболее достоверную инофрмацию... Как же там быть?

ПС Надеюсь добавочная информация просветлит вас :) Если, что опять непонятно, то пишите - дополню

2 gardenman : База данных уже написана. Вот для чего только она написана не могу понять - говорят, что надо найти оптимум между удобной системой хранения данных и быстродействием. Пока задача найти удобный способ хранения данных. То есть подкорректировать текущую структуру.

Насчет ссылок подумал и вот, что надумал - не лучше ли будет создать дополнительный столбец Ссылка в таблицах и Значение Ссылки. Так вроде можно сэкономить на памяти в таблицах. Каково ваше мнение?

Хорошо давайте будем решать вопросы с простых вещей и в понятных обозначениях :

Цунами это
BASE RELATION TSUNAMI (TSU_ID#, ... DAMAGE_ID#)
PRIMARY KEY (TSU_ID#)
FOREIGN KEY (DAMAGE_ID#) REFERENCES DAMAGE

Разрушения это
BASE RELATION DAMAGE (DAMAGE_ID#, ... TSU_ID#)
PRIMARY KEY (DAMAGE_ID#)
FOREIGN KEY (TSU_ID#) REFERENCES TSUNAMI

Получилась нехорошая циклическая связь! Как этого избежать? Можно добавить просто поля DAMAGE к TSUNAMI и считать, что как раз эти поля и есть наиболее достоверные характеристики разрушения для данного цунами - это будет верным?

2 ModelR :
Поймите правильно - есть различные Разрушения соответствующие одному Цунами . Но среди этих Разрушений выделяется одно - наиболее достоверное для данного Цунами , причем это достоверное не может соответствовать другому Цунами . Вот спрашивается как это корректно сделать? Один вариант я предложил - вот только верен ли он на ваш взгляд? :)