2014 dxdy logo

Научный форум dxdy

Математика, Физика, Computer Science, Machine Learning, LaTeX, Механика и Техника, Химия,
Биология и Медицина, Экономика и Финансовая Математика, Гуманитарные науки




Начать новую тему Ответить на тему
 
 физическая модель БД и ее адекватность
Сообщение01.09.2013, 16:23 


21/08/12
15
Здравствуйте, уважаемые форумчане.

Хочу задать вопрос по физической модели БД.

Описание предметной области:
Есть установка. Она датирует органические образцы ( определяет возраст образца). Сам образец отражен в табл Sample.
Проект к которому он принадлежит в Project. У проекта есть заказчик - Customer.
Для проекта и заказчика созданы словари - страна , регион , город (Сountry, Region, Town).
При анализе, от образца (Sample) отделяют кусочек и сотрудник (Employee) его датирует
(то есть у образца Sample может быть несколько значений возраста- Age), что отражено в Sample analysis.
В организации мало сотрудников, поэтому нет необходимости создавать отделы и т.п. Имён и контактов достаточно.

Хотелось бы узнать адекватна ли модель и правильно ли я понял, что словари (country, region, town) нужны для того , чтобы при наполнении базы пользователь не совершил ошибку
и не написал Архнгльск, вместо Архангельск?

Заранее спасибо.

Изображение

 Профиль  
                  
 
 Re: физическая модель БД и ее адекватность
Сообщение01.09.2013, 16:59 
Заблокирован
Аватара пользователя


07/08/06

3474
Чтобы понять, насколько адекватна модель, не хватает описания задачи. Например, у Вашего проекта есть город, где он, видимо, выполняется. Этот город может отличаться от города, где находится заказчик. Этого в описании нет. Может ли проект переехать в другой город? Тогда что, просто поправить реквизиты в БД? Если нужны отчёты за прошлые периоды, такая правка может быть некорректной. И почему-то связь с городом идёт по почтовому индексу, а ведь на один город может приходиться несколько отделений связи (и разных индексов).

 Профиль  
                  
 
 Re: физическая модель БД и ее адекватность
Сообщение01.09.2013, 20:39 


21/08/12
15
Спасибо за ответ.

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

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

ГОРОД ИНДЕКС
Псков - 180001
Псков - 180002
Псков - 180003
...
...
и каждый город будет определяться однозначно.

Видимо, правильнее использовать ID, как в Region и Country?

 Профиль  
                  
 
 Re: физическая модель БД и ее адекватность
Сообщение01.09.2013, 20:44 
Заблокирован
Аватара пользователя


07/08/06

3474
supercranberry в сообщении #759658 писал(а):
Видимо, правильнее использовать ID, как в Region и Country?

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

-- Вс сен 01, 2013 21:46:13 --

supercranberry в сообщении #759658 писал(а):
С почтовыми индексами я имел ввиду, что для каждого населенного пункта есть набор почтовых индексов, присущих только ему.
Тогда можно для каждого города:

Тогда Вам в справочник один и тот же город много раз придётся вбивать. Не страшно, в принципе, но как-то не очень гладко.

 Профиль  
                  
 
 Re: физическая модель БД и ее адекватность
Сообщение01.09.2013, 20:57 


21/08/12
15
Еще раз обдумаю, спасибо.

 Профиль  
                  
 
 Re: физическая модель БД и ее адекватность
Сообщение01.09.2013, 21:28 
Аватара пользователя


28/01/12
467
Не понял заморочек с post code.
Учетная запись Customer - содержит улицу, значит предполагается вести переписку, ну и как же без post code?
А то, что в словаре Town, город например Псков, несколько раз ну и что?
Огранизуйте запрос по уникальному имени города и все дела.

PS. Зная почтовый индекс - однозначно определяется город.
Зная только город - всегда можно найти индекс ( например для города Псков, возвратный индекс Псков - 180000 - Главпочтамт).

PPS. Справочники "Город-Почтовый индекс" по РФ (да и по СНГ) - собственно уже готовые можно использовать (ничего не надо вбивать).

 Профиль  
                  
 
 Re: физическая модель БД и ее адекватность
Сообщение01.09.2013, 22:11 
Заблокирован
Аватара пользователя


07/08/06

3474
А зачем индекс в справочник-то пихать? Их там довольно много: вот, даже все улицы прописаны.

 Профиль  
                  
 
 Re: физическая модель БД и ее адекватность
Сообщение01.09.2013, 22:30 
Аватара пользователя


28/01/12
467
Можно и улицы, но в таком случае возможно неоправдано большой по размеру будет таблица (если использовать готовые справочники).
В принципе, всё зависит от цели справочника.
Я высказался только по предложенной структуре Town,
в ней почтовый идекс и есть то самое - ID, о котором ТС и вспоминал.

 Профиль  
                  
 
 Re: физическая модель БД и ее адекватность
Сообщение01.09.2013, 22:43 
Заблокирован
Аватара пользователя


07/08/06

3474
Индекс можно и простым полем завести. Кстати, можно тогда в справочнике городов иметь индекс Главпочтамта, первые 3 цифры которого использовать для проверки набираемого вручную значения - в случае чего, далеко посылка не уйдёт.

В общем, как всегда, вариантов много.
(Хотя дублирование в справочнике мне всё равно не нравится).

 Профиль  
                  
 
 Re: физическая модель БД и ее адекватность
Сообщение01.09.2013, 23:59 
Аватара пользователя


28/01/12
467
Ну вообще-то я и имел ввиду post code - 6 знаковое (char) поле = Primary key,
ни какое не long или automatic number/counter.
Просто для ТС это и будет тоже самое, что ID.

 Профиль  
                  
 
 Re: физическая модель БД и ее адекватность
Сообщение02.09.2013, 08:01 
Заблокирован
Аватара пользователя


07/08/06

3474
Я это понял. Я "post code" ("индекс") предлагал простым полем сделать, без связи со справочником, а проверку делать программно после ручного ввода - как Вы и намекали, видимо, в случае с Главпочтамтом:
NT2000 в сообщении #759685 писал(а):
PS. Зная почтовый индекс - однозначно определяется город.

.

-- Пн сен 02, 2013 09:08:01 --

AlexDem в сообщении #759722 писал(а):
индекс Главпочтамта, первые 3 цифры которого использовать для проверки набираемого вручную значения

Хотя это не пойдёт, сейчас посмотрел для Москвы - там уйма разных индексов.

 Профиль  
                  
 
 Re: физическая модель БД и ее адекватность
Сообщение02.09.2013, 10:10 
Аватара пользователя


28/01/12
467
AlexDem в сообщении #759782 писал(а):
Хотя это не пойдёт, сейчас посмотрел для Москвы - там уйма разных индексов.

Что не пройдёт? Почему не пройдёт?

Повторю еще раз: Почтовый индекс однозначно определяет город.
Например :
123103 - Москва, МГУ тер
107076 - Москва, Матросский Б. пер
129594 - Москва, Марьиной Рощи 6-й проезд
и т.д.

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

PS. А вот обратная операция - только по названию города вписать в учетную карточку Customer почтовый индекс, это да, несколько сложнее.
Вот тут и надо делать некоторые натяжки и выборка по уникальным именам городов и есть такой определенной натяжкой.
В 99% процентах даёт положительный эффект.

 Профиль  
                  
 
 Re: физическая модель БД и ее адекватность
Сообщение02.09.2013, 13:24 
Заблокирован
Аватара пользователя


07/08/06

3474
NT2000, да я просто считаю, что индексу не особо нужен справочник для проверки, так же как и улице, например. Поэтому это я так - попытался предложить простое решение, но оно не прошло. Ваши предложения я ни в коем разе не оспариваю, поэтому повторять для меня ещё раз не нужно :wink:

 Профиль  
                  
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 13 ] 

Модераторы: Karan, Toucan, PAV, maxal, Супермодераторы



Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group