Начнем обсуждение.
Прошу относиться к моим ответам не как к придиркам с целью продвинуть мои идеи.
Ведь это самое начало проекта, просто макет, будем вместе его улучшать.

Мне кажется, что в предложенная shandrik-ом система таблиц не очень удачна - слишком громоздка, что-ли?
t_manufacturer - влияние производителя инструмента на вид конкретного дипа много меньше, чем уровня засветки на месте наблюдения и скорости ветра. Зачем тогда усложнять себе жизнь? Мы ведь не инструментами собираемся меряться, а впечатлениями от дипов.

...

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

Кроме главного назначения проекта - быстрого доступа к описанию нужного объекта, можно будет получить очень интересную статистическую информаци. Простым запросом можно увидеть распределение по наблюдателей по странам и городам. Нагляднейший пример - я случайно наткнулся на сайт "Астрономия в Новосибирске" Маслова Михаила. Написал ему письмо. И что вы думаете - живет он в 15-20 минутах ходьбы от моего дома и мы теперь вместе наблюдаем. "Это же урбанизация, какая-то!.." (с) Ахиджакова.
Можно сделать выборку по инструменам/изготовителям и, с учетом скилла наблюдателя, сделать вывод об их пригодности для своих нужд в свете дальнейшей покупки. Вообще тут такой простор для статистики - аж дух захватывает.

t_Eyepieces и t_eyepieces_type - если предполагается ресурс по обзорам окуляров и проч. "железа" то этих таблиц мало (нужна еще таблица отзывов на каждую запись в t_Eyepieces), если по дипам, то достаточно указать использованное увеличение при наблюдении

Окуляр окуляру рознь, я полагаю, это не надо объяснять. Как минимум, еще поле нужно, т.к. Аш и Хи Персея в 40-градусный Плессл НПЗ и 68-градусный Паноптик того же фокусного расстояния - чуть ли ни разные объекты.

t_filters и t_filters_type - соображения аналогичное вышеприведенному, помноженное на редкость применения фильтров (достаточно одного опционального поля в таблице наблюдений)

А много ли, скажем, Телевьюшных окуляров было у местного населения год назад? А сейчас? Растем, ребята, обзаводимся хорошими аксессуарами. Думаю, фильтры скоро будут гораздо более распространенными. Эффект от них велик, и будущие наблюдатели смогут выбрать, что именно им нужно. Вот если бы мы не отказывались зарисовывать увиденное...

t_telescopes, t_telescope_type, t_mount и t_mount_type - много данных которые неважны для понимания условий наблюдения но мало для полноценного review. Достаточно одной таблицы, где хранится знач. апертуры, ссылка на владельца и опионально относительное отв., производитель (строка), схема (строка), описание особенностей (текст), линк на подробное описание или даже таблица линков со ссылкой на t_telescopes.

Насчет t_mount я уже говорил, что не уверен в ее нужности, но вот конкретный инструмент указать, мне кажется, стоит. Вот как только быть с самодельными телескопами?  
Изготовитель должен быть в отдельной таблице - как Вы себе представляете заполнение базы в противном случае. Появятся записи с "МИД", "MID", "MEAD", "MEADE". Нет, все должно выбираться из справочников, которые можно сделать за пару дней.

t_observer - таблица чрезмерно усложнена (см. данные по участнику этой конференции)

Возможно, но см. выше. Иногда эти данные могу пригодится.

(t_country не содержит ничего, кроме своего названия, t_city еще и координаты независимо от того, где наблюдает observer),
...
t_observ_place - полезная таблица хотя и чрезмерно детализированная, достаточно, наименования, высоты над уровнем моря, описания и опциональных координат

Ой! Я не туда широту и долготу вставил
Я же хотел не в t_city, а в t_observ_place - им там место.

t_object - должна быть дополнена таблицей ссылок на внешние данные, каждая запись которой ссылается на соотв. запись в t_object

Не понял, поясните, пожалуйста.

t_object_type, t_object_subtype - избыточны, достаточно соотв. строкового поля в t_object

Я - за атомарность! Зачем дублировать текстовые поля в обной таблице, если можно разнести?

t_search_map - просто пара ключей - ссылка на t_object и линк на интернет-ресурс с опциональным описанием

Тоже не понял.

t_observ_session - обычная календарная дата обязательно, юлианская дата - опционально, дополнить ссылкой на инструмент

Разумеется, пользователь будет видеть (и вводить) календарную дату. Встроенная функция будет конвертить дату в нужный формат. Очень удобно, что за ночь наблюдения целая часть юлианской дате не меняется.
А насчет инстрмента - их может быть и не один, т.ч. инструменту место в t_observ.

t_observ - JD - можно отбросить, дипы довольно малоизменчивы - достаточно даты в t_observ_session и, возможно, дополнения к описанию в виде засечки момента времени, если это потребуется

Да нет, они очень изменчивы в зависимости от высоты их и Луны над горизонтом, которые есть функции времени. Другое дело, что мало кто будет прикидовать эту высоту и можно было бы обойтись просто описание факта (булевым полем) Луна под или над горизонтом. Тогда это поле можно убрать, оставив в t_observ_session.

Комментарии:

t_eyepieces и t_eyepieces_type, t_filters и t_filters_type, t_telescopes и t_telescopes_type, t_mount и t_mount_type  руки чешутся объединить. Не надо структуру приводить к 5 НФ  

Что такое 5 НФ?
Обилие справочников не будет мешать, наоборот поможет стандартизировать базу.

Честно говоря, не совсем понятно зачем использовать t_object_type и t_object_subtype - типичные "слабые сущности", гораздо проще и понятнее использовать отдельные поля в t_object типа:
type - тип объекта (GALXY,OPNCL,GLOCL,PLNNB,BRTNB,DRKNB и пр.)

Я категорически против дублирования текстовых полей - только ссылки. ЕЩЕ РАЗ ПОВТОРЯЮ - ЭТО НЕ НАПРЯЖЕТ, НЕ УСЛОЖНИТ БАЗУ, а сделает ее структурированней.

class - класс объекта в соответствии с общепринятой классификацией

Ой, а что под классом подразумевается?

Советую почитать
http://oralib.h1.ru/ora1/oraclepr_04.htm

Спасибо за ссылку! Как раз сейчас с Ораклом разбираюсь.

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

Здрассте. А я про что? Я же говорю - распределившись, делаем справочники за пару дней. Сайты известны, нужные параметры доступны. В чем проблема-то? Я за субботнее дежурство могу сделать базу окуляров и телескопов. Дежурства на это не жалко. С фильтрами и монтировками (так нужны они или нет?) пусть более знающие разбираются.

Цитировать

Я категорически против дублирования текстовых полей - только ссылки. ЕЩЕ РАЗ ПОВТОРЯЮ - ЭТО НЕ НАПРЯЖЕТ, НЕ УСЛОЖНИТ БАЗУ, а сделает ее структурированней.

А где дублирование-то? Каждому объекту однозначно соответствует его тип. А все отношения 1:1 в теории БД обычно сводятся к одной таблице.
Еще раз повторю, совсем не обязательно хранить все списки в виде отдельных таблиц, тем более, если размерность этих списков заранее известна.

Про известную размерность списков, похоже, правильное замечание.
Но меня раздражает запись "ШарСкопл", когда можно поставить красивую и приятную глазам субэдэшника единицу или двойку Единообразие, доведенное до безобразия и есть порядок!

>Что такое 5 НФ?

5-ая нормальная форма. То есть высшая (почти) степень нормализации таблиц базы данных. Очень хороша для реализации быстрых транзакция типа Insert/Update, но существенно тормозит при запросах типа Select/Delete. Обычно строгая нормализация вредит проектам типа Datamarts/Datawarehouse. В нашем случае мне такое обилие справвочных таблиц так-же кажется излишним. Однако, если есть амбиции замахнуться на большее, чем просто базы данных отечественных наблюдений дипов. Скажем - создать базу обзоров инструментов, окуляров, проч. аксессуаров. Я не думаю, что это целесообразно - она по количеству записей не сможет конкурировать с Excelsis и просто будет непредставительной.

>Обилие справочников не будет мешать, наоборот поможет стандартизировать базу.

Зачем? Оттого, что кто-то ошибется в название и напишет в описании своего инструмента Mid вместо Meade, как это повлияет на главное - описание дипа?

>Я категорически против дублирования текстовых полей - только ссылки. ЕЩЕ РАЗ ПОВТОРЯЮ - ЭТО НЕ НАПРЯЖЕТ, НЕ УСЛОЖНИТ БАЗУ, а сделает ее структурированней.

Зачем ей в нашем случае быть "структурированней"? Какая от этого польза? (На всякий случай замечу, что участвовал в разработке многих баз данных, в том числе и для таких заказчиков, как Simens.)
Что касается "НЕ НАПРЯЖЕТ" - то это не так, именно напряжет, во-первых, программиста (а каким ресурсом мы здесь располагаем, пока не известно), но отчасти и пользователя. Тут и прописывание реляционной целостности с которой у MySQL не все просто, и усложнение форм on-line ввода, и требование предварительного импорта более свежих справочников на клиента для удаленного заполнения. Пополнение этих справочников...

>Без фотографий обойтись можно, но карты-то будут очень полезны.

Присоединяюсь - опциональные ссылки на графику по объекту (и карты, и фотографии) должны быть предусмотрены. Если их вынести в отдельную таблицу, то они ни как не будут усложнять таблицу t_object.

>Простым запросом можно увидеть распределение по наблюдателей по странам и городам.

Запрос только упростится, если название города/страны ввести как текстовые поля в t_observer.

>Вообще тут такой простор для статистики - аж дух захватывает.

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

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

Это все так, только 90% наблюдений дипов (в том числе и у НИХ) производится без использования фильтров. А в случае использования вполне достаточно, как мне кажется, упомянуть в описании, эффект применения, скажем, UHC от Lumicon. То есть фильтр добавляет такие-то детали, а без фильтра лучше видны такие-то. Другими словами, фильтр это не атрибут наблюдения, а один из нескольких приемов наблюдения, типа покачивания трубы, бокового зрения, игры увеличениями. Эти приемы не исключают, а взаимодополняют друг друга, в одном визуальном наблюдении они могут быть использованы в комплексе - это не фотография.

>>t_object - должна быть дополнена таблицей ссылок на внешние данные, каждая запись которой ссылается на соотв. запись в t_object

>Не понял, поясните, пожалуйста.

t_object не должна содержать ссылку на графику, должна быть таблица t_object_external_link с полями t_object_ref (ссылка на запись в t_object), link (полная интернет ссылка на графические или текстовые материалы). Можно добавить поле с указанием типа ссылки (поисковая карта, фотография, рисунок, описание). Ссылка может быть как внешней, так и на графический материал хранящийся в базе данных.

Аналогично можно поступить с t_search_map.

Мне надо подумать над Вашими доводами, Ernest. Они мне кажутся правильными.
Беру денек-другой тайм-аута.

Прилагаю свой вариант. На авторство Шандрика не претендую, я всего лишь удалил из его структуры лишнее на мой взгляд.

По поводу Access. Я его тоже не люблю, на работе используем SQL Server, но в данном случае речь идет только о локальной БД и движке, а сам клиент может быть на дельфях, которые я очень уважаю и имею огромный опыт (8 лет, огромный проект - система контроля и управлением доступа, обслуживающая многие наши АЭС и другие важные объекты). Так что какую-то часть клиента я реализовал бы (как это принято говорить, на высоком профессиональном уровне), жаль времени в обрез мало, но что успею - сделаю, так что Шандрик обращайтесь.

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

Иначе мне кажется игра свечь не стоит - узкопрофильная база сама по себе неинтересна.

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

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

Ну ладно, как с базой разберемся и будет готов бланк, заведу новую тему в наблюдениях.

Леня! Хватит делать что попало! (с)  

Объясни мне, зачем нужен t_telescope_type? Почему нельзя в t_telescope указать, например:

"ТАЛ 100Р", 100, 1000, "Рефрактор ахромат", "НПЗ" или
"Супер Доб", 1000, 5000, "Рефлектор Ньютона","сам сделал"...

Для t_observ_place предлагаю оставить

id
city (ближайший, если место наблюдения - дер. Гадюкино)
country
longitude (может и не надо)
latitude
max_mag (опытным путем установленная максимально доступная зв. величина в зените в самые лучшие ночи)
description (вот туда можно запихать все, что угодно)

В t_object  спорное поле "созвездие по-русски", лучше отдельный справочник сделать, кому надо посмотрит, а то явно 3Мб избыточности вылезает  

t_search_map - пока не ясно

t_observ_session - необходимость выглядит сомнительной. Дату, луну и погоду можно спокойно запихать в t_observ (придумать кодификаторы), а также lm - limited magnitude (либо в зените, либо в точке местоположения наблюдаемого объекта, есть разница!).



 
 

Это не опечатка - АЭС - не АЗС?
Обратимся, конечно.

Ну что же вы меня с грязь-ю то сравниваете! АЭС, а про другие объекты я вам даже говорить боюсь - государственная тайна.

Не дождетесь!

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

t_Eyepieces   - это что? справочник по окулярам или список всех окуляров в наличности и наблюдателей? Если справочник окуляров (то есть 5 мм Meade 4000 серии будет присутствовать как одна запись), то нужна еще одна таблица связывающая владельца с окуляром - там можно разместить отзыв, да и при выборе окуляра с которым шло наблюдение не будет вываливаться комбо-бокс на несколько сотен позиций. Добавить поле описания (ну типа есть резиновый наглазник, исполнение для гидирования с сеткой и т.п.), а так-же, раз пошла такая пьянка, поля с размером посадки, весом, габаритами.

t_Eyepieces.id_eyepieces   integer   - рекомендую заменить ключи string и забивать чем-то более менее понятным типа 5meade4000 (5 мм Meade 4000 серии) - это не сильно скажется на задержке запросов, но облегчит работу с дампами данных и ручной работой по коррекции базы etc.
     
t_telescopes - аналогичное t_Eyepieces замечание, если это справочник моделей, то нужна таблица связи наблюдателя с телескопом, если таблица экземпляров, то нужно поле развернутого описания и foreign key на наблюдателей. Добавить текстовое поле описания.

t_telescopes.id_telescope   integer   - заменить на string см. выше
t_telescopes.id_type_telescope   integer   - заменить на string см. выше
     
t_telescope_type - добавить описание (ну там кома не исправлена, хроматизм положения огранияивает качество на оси и т.п.)
     
t_observer - может быть добавить ICQ
t_observer.id_observer   заменить на строку (nick, может совпадать со Звездочетовским), см. выше
t_observer.Sex   boolean   - можно выбросить, во всяком случае должен принимать три значения - не указан/муж/жен
t_observer.www_observer - поскольку далеко не у всех есть, а у некоторых сайтов несколько, то лучше ввести отдельную таблицу t_observer_external_links где можно по каждому наблюдателю добавить линков на любимый сайт, на домашнюю станичку, фотографию в кругу семьи, в обнимку с телескопом и т.д.
     
t_observ_place - полезная таблица. Должно быть название, высота над уровнем моря, тип площадки (центр города, окраина, поселок-дача, равнина вдали от города, горы...), тип засветки (городская со всех сторон, сильная локальная, слабая от населенных пунктов за горизонтом...), оценка качества, описание и опционально - координаты. Должна так-же быть таблица связи наблюдателя и места наблюдения, а так-же t_place_external_links со ссылками на фотографии и более развернутое описание

t_observ_place.id_observ_place   заменить на string (или если угодно краткое название), см. выше
     
t_object.id_object - перевести в string типа NGC1234 или M21, см выше
m_name,   ngcic_name, another_name - думаю лучше заменить на пару полей - имя каталога (NGC, M, IC, PK...) и ID (13, 1223, 8953, 12-3-5) - оба текстовые, можно дополнить еще и парой ссылок на альтернативный каталог (почти все из Месье входят в NGC)
t_object.Size1, Size2 - хранить в минутах или даже секундах
t_object.interesting - впечатление по 10 бальной шкале, ОК
t_object.photo - выбросить в отдельную таблицу внешних ссылок t_object_external_link: три обязательных поля - ссылка на объект, гиперссылка, тип ссылки (поисковая карта, фотография, рисунок, описание...) и опционально - описание
     
t_search_map -  можно отбросить, если будет t_object_external_link

t_observ_session - нет поля длительности наблюдений, тектового описания и ссылки на основной инструмент

t_observ_session.JD_observ - не удобна при ручной работе и расшифровке дампамов базы данных, думаю стоит заменить на календарную дату начала наблюдений
     
t_observ.id_observ integer - просто порядковый номер наблюдения в сессии (часть составного ключа)
t_observ.id_telescope - опционально (см. телескоп сессии)
t_observ.observ_object_descript_lyric - скорее уместно в таблице наблюдательных сессий