Покритикуйте, посоветуйте.

← →
AntiUser © (2007-02-27 19:00) [0]

Принимаю любые замечания, наставления, критику, советы, как что, можно было бы, а может быть и нет, сделать лучше.
Проект БД: http://antiuser.pisem.net/temp/table1.gif

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

В общем, слушаю. (правда, отойду пока, но я вернусь =))
Зарание, спасибо.

← →
oldman © (2007-02-27 19:07) [1]

Замечание №1: Мне не понравился зелененький цвет.
Замечание №2: А можно хоть какое-то объяснение, что это за нафиг...

← →
Empleado © (2007-02-27 19:14) [2]

> AntiUser © (27.02.07 19:00)

Один employee может иметь несколько паспортов? (см. passport_pn)

Если "нет", то passport_pn убрать, а emp_id добавить в passport;
если "да" (в том числе для статистики предыдущих, например), то надо, чтобы было понятно - какой passport действителен в настоящее время и на какой passport надо делать упор (загран, внутренний, иностранный (при многогражданстве)).

дальше - завтра, труба зовет!
bye

← →
Empleado © (2007-02-27 19:18) [3]

>Empleado © (27.02.07 19:14) [2]
ПС. да в любом случае passport_pn можно удалить

← →
Gero © (2007-02-27 19:18) [4]

Тени убери, они только перегружают картинку. Заголовки выделяй, например, жирным.

← →
Gero © (2007-02-27 19:20) [5]

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

← →
AntiUser © (2007-02-27 20:18) [6]

> Empleado © (27.02.07 19:14) [2]

Да, может. О том, какой активный - не подумал, возможно рационально.

> Empleado © (27.02.07 19:18) [3]

На каком основании? А как же описать связь?

> oldman © (27.02.07 19:07) [1]
> Замечание №1: Мне не понравился зелененький цвет.
> Gero © (27.02.07 19:18) [4]
> Gero © (27.02.07 19:20) [5]

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

Интересуют мнения по поводу содержания.

> oldman © (27.02.07 19:07) [1]
> Замечание №2: А можно хоть какое-то объяснение, что это за нафиг..

Это небольшая БД, типа кадры. Человек - данные (проживание, образование, паспорт, должность, приказы), все они (кроме некоторых приказов) завязаны на человека

← →
default © (2007-02-27 20:23) [7]

ты прогу пишешь типа ERwin?
можно поговорить
я тоже такую пишу

← →
Petr V. Abramov © (2007-02-27 20:26) [8]

А зачем все NAME выделены в отдельные таблицы?
а по мелочи - все таблицы названы по-английски, а OTDEL - по-непонятному :)

← →
AntiUser © (2007-02-27 20:31) [9]

> default © (27.02.07 20:23) [7]
> ты прогу пишешь типа ERwin?

Нет не пишу. Я пытаюсь создать базу данных. Эта картинка описывает таблицы, поля и их связи. Поскольку я делаю такую задачу в первый раз, поэтому и спросил мнение.

По поводу картинки. Она создана с помощью PowerDesigner 11, а саму базу делал в PLSQL Developer"e.

← →
AntiUser © (2007-02-27 20:35) [10]

> Petr V. Abramov © (27.02.07 20:26) [8]
> А зачем все NAME выделены в отдельные таблицы?а по мелочи

Предполагается наличие нескольких имен, за сим связь ...

> - все таблицы названы по-английски, а OTDEL - по-непонятному
> :)

Да фиг знает =) Как-то получилось само собой. Пока это прототип, поэтому и советуюсь. Наверное переделаю, а то действительно, как-то не так ;)

← →
Petr V. Abramov © (2007-02-27 20:38) [11]

> Предполагается наличие нескольких имен, за сим связь ...
у паспорта и у адреса? ну тебе видней предметную облать

← →
AntiUser © (2007-02-27 20:49) [12]

> Petr V. Abramov © (27.02.07 20:38) [11]
> > Предполагается наличие нескольких имен, за сим связь .
> ..у паспорта и у адреса? ну тебе видней предметную облать

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

← →
Knight © (2007-02-27 20:49) [13]

> [11] Petr V. Abramov © (27.02.07 20:38)

Местный, Загран, временный, спёртый...
По прописке, фактический, возможные (квартиры для... , явки и пр.)

← →
Petr V. Abramov © (2007-02-27 21:02) [14]

> AntiUser © (27.02.07 20:49) [12]
дык то, что адресов и паспортов может быт несколько - понятно. Но как у конкретного экземпляра паспорта(адреса) может быть несколько названий? Или это ТИП адреса? тогда что значит стрелка - откуда она растет, там "один" или "много"?

← →
Knight © (2007-02-27 21:14) [15]

> Но как у конкретного экземпляра паспорта(адреса) может быть
> несколько названий

Да... заюзано не так..

← →
AntiUser © (2007-02-27 21:29) [16]

То есть? Стрелки не в ту сторону? А я, вроде, сначала так и сделал, но потом мне показалось это не совсем верным.
Я, как бы предполагаю так.
Есть PASSPORT имеет свой ID и PASS_NAME_ID, который указвает на запись с названием паспорта.
А как должно быть?

← →
Petr V. Abramov © (2007-02-27 21:35) [17]

> который указвает на запись с названием паспорта.
что такое "название". если "местный", "заграничный", тогда это ТИП, и так и назови, не смущай народ. Если "первый загранпаспорт Васи" - тогда нечего отдельную таблицу городить (в данном случае, изредка полезно из соображений перфоменса).
А куда стрелки - дело вкуса, главное, чтоб везде одинаково. Но, ИМХО, обычно стрелка растет от "один" указывает на "много"

← →
AntiUser © (2007-02-27 21:42) [18]

> Petr V. Abramov © (27.02.07 21:35) [17]

Ну да, все как Вы говорите. Стрелки растут куда надо =)
Ну раз ТИПЫ, так пусть будут ТИПЫ, это принципиально? Надо ли это отразить в базе? Например, вместо PASSPORT_NAME сделать PASSPORT_TYPE и поле соответственно?

← →
Petr V. Abramov © (2007-02-27 21:49) [19]

> Ну раз ТИПЫ, так пусть будут ТИПЫ, это принципиально?
да можно и горшки, только непонятно, NAME больно заезженное слово, вот сразу не въехал, что имлось в виду.
> Стрелки растут куда надо =) да откуда я знаю, куда им надо? Конец стрелки (куда она указывает) - это "один" или "много"?

← →
AntiUser © (2007-02-27 21:57) [20]

> Petr V. Abramov © (27.02.07 21:49) [19]
> Конец стрелки (куда она указывает) - это "один" или "много"?

Это "один". Если я все правильно понимаю, т.е. PASSPORT_NAME.NAME = "Российский паспорт", а PASSPORT - их много, по крайней мере, подразумевается, что все сотрудники имеют паспорта российского образца.
Т.е. у меня, что-то не так? Я правильно понимаю?

← →
AntiUser © (2007-02-27 21:58) [21]

На самом деле меня больше беспокоит этот огород с должностями, отделами и приказами.

← →
AntiUser © (2007-02-27 22:01) [22]

Что-то интуиция мне подсказывает, что там что-то не так =(

← →
Knight © (2007-02-27 22:03) [23]

А почему бы не добавить поле ИмяПаспорта к ПАСПОРТ_ПН ?

← →
Knight © (2007-02-27 22:06) [24]

И действительно для чего нужны эти PASSPORT_PN и ADDRESS_NA ?

← →
AntiUser © (2007-02-27 22:07) [25]

> Knight © (27.02.07 22:03) [23]
> А почему бы не добавить поле ИмяПаспорта к ПАСПОРТ_ПН ?

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

← →
AntiUser © (2007-02-27 22:09) [26]

> Knight © (27.02.07 22:06) [24]
> И действительно для чего нужны эти PASSPORT_PN и ADDRESS_NA
> ?

Я тоже над этим думал, не нравились они мне, но решил оставить.

Значит, все-таки лучше убрать?

← →
Knight © (2007-02-27 22:09) [27]

Имена адресов и паспортов пусть в справочниках, а сами паспорта и адреса сделать по принципу телефонов.. а к телефонам привязать справочник типов телефонов (рабочий, домашний, сотовый...)

← →
Knight © (2007-02-27 22:11) [28]

То же самое по отношению к верху (FORMATION)... %)

← →
Knight © (2007-02-27 22:16) [29]

Переведите названия таблиц правого-верхнего сектора... чё-т я не въезжаю..

← →
AntiUser © (2007-02-27 22:18) [30]

> Knight © (27.02.07 22:09) [27]

Понял. Но с телефонами сознательно, поскольку в TELEPHONE будут содержаться только те, которые не относятся к адресам (в ADDRESS есть спец. поле), рабочих телефонов не будет. Остаются только сотовые, поэтому справочник типов для телефонов делать не стал.

← →
AntiUser © (2007-02-27 22:24) [31]

> Knight © (27.02.07 22:16) [29]
> Переведите названия таблиц правого-верхнего сектора... чё-
> т я не въезжаю..

Да, там фигня, сам путаюсь, потом переделаю.
FORM_PROFESSIONS ... ща в коментах посмотрю =)

А вот посмотрел, там действительно ошибка.
FORMATION - справочник типов образований (среднее, высшее и т.д.).
FORM_PROFESSIONS - профессия по образованию.

← →
Knight © (2007-02-27 22:26) [32]

Это левый-верхний... а я спрашивал ПРАВЫЙ... похоже не мне одному спать пора... :)))

← →
wicked © (2007-02-27 22:36) [33]

общие замечания:
1) язык, на котором именованы обьекты БД - все таки хорошо бы использовать один, английский либо русский (транслитом ;))
2) "число" в названиях обьектов - employee и address - в одиночном, orders - во множественном.... это приведет к сложностям при запоминании имен обьектов - не все время ж в схему подглядывать?
3) длинные названия обьектов (как по мне) - telephone вполне можно сократить до phone;
и еще - система только телефоны будет хранить? а емейлы, аськи, скайпы, пейджеры? и на каждый из них новую таблицу?
4) выбор типов данных для некоторых полей - зачем в passport числовое значение num? предполагается выбор sum(), min(), max(), avg() по этому полю?
есть такое правило - числовые типы нужно назначать только аттрибутам-значениям, а не аттрибутам свойствам
и зачем для поля job.deleted выделять аж 5 символов?
5) разбивка по полям - зачем в address вынесены отдельно поля korpus, house и street? мы будем искать всех тех, кто живет в "корпусе 2"? аналогично с series и num в passport
6) связки между таблицами - смущает меня что то двойная связка orders и employee через таблицы orders_on и emp_additions - здесь надо что то пересмотреть
7) повальное использование автоинкрементных числовых ключей даже там, где можно обойтись символьными не-автоинкрементными; например, связки между address и address_name, passport и passport_name
но этот пункт уж больно сомнительный

пока вроде всё - это еще не все замечания, а только часть, которая пришла в голову

← →
Knight © (2007-02-27 22:42) [34]

Имхо... упразднить OTDEL_JOB, ORDER_ON и связку OTDEL-ORDERS

← →
Knight © (2007-02-27 22:47) [35]

Что такое EMP_ADDITIONS тоже не совсем понял... поэтому, предлагаю тоже можно зарезать :)

← →
AntiUser © (2007-02-27 23:23) [36]

> Knight © (27.02.07 22:42) [34]
> Имхо... упразднить OTDEL_JOB, ORDER_ON и связку OTDEL-ORDERS

OTDEL_JOB нельзя, там совмещение, а вот связь надо переписать на ORDERS
ORDER_ON нельзя, приказы напрямую связанные с сотрудником, например, выговор, поощрение, награждение и т.д.
OTDEL-ORDERS нельзя, при расформировании/создании отдела, должен быть приказ.

> Knight © (27.02.07 22:47) [35]
> Что такое EMP_ADDITIONS тоже не совсем понял... поэтому,
> предлагаю тоже можно зарезать :)

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

> wicked © (27.02.07 22:36) [33]

1. Согласен. Обсуждалось выше.
2. Согласен. Исправлю.
3. ИМХО субъективно. Только телефоны.
4. Number зарезервированное слово, пришлось обойтись его сокращением, а как еще обозначить номер паспорта?
есть такое правило - числовые типы нужно назначать только аттрибутам-значениям, а не аттрибутам свойствам
Если честно, не понял. Не могли бы сформулировать доступнее.
и зачем для поля job.deleted выделять аж 5 символов?
В Oracle нет boolean"а поэтому пишу False default или True, конечно можно и 0-1 и еще как, но так мне нагляднее.
5. Возможно будем ;)
6. Ответил выше в этом посте Knight"у
7. Тоже кажется субъективным.

Обязательно жду дальнейших замечаний. Серьёзно. Поскольку уже достаточно много прояснилось и завтра будет изменено.

← →
Knight © (2007-02-27 23:35) [37]

Чтобы прояснилось ещё лучше... начни с самого начала... с ТЗ, а то окажется, что там ещё куча ограничений и перспектива борьбы за часть рынка 1С-ЗиК ;)

← →
wicked © (2007-02-27 23:49) [38]

> AntiUser © (27.02.07 23:23) [36]

> 4. Number зарезервированное слово, пришлось обойтись его
> сокращением, а как еще обозначить номер паспорта?

имелось в виду то, зачем полю "номер паспорта" числовой тип?
я бы обьединил их с серией и сделал одним varchar-ом

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

вкратце - "если над полем по правилам предметной области НЕ ПРЕДУСМАТРИВАЮТСЯ арифметические действия, то тип поля нужно делать символьным"
например:
поле "номер дома", "номер накладной" нужно делать символьным
поле "коэффициент надбавки", "процент скидки" - числовым

> и зачем для поля job.deleted выделять аж 5 символов?
> В Oracle нет boolean"а поэтому пишу False default или True,
> конечно можно и 0-1 и еще как, но так мне нагляднее.

например, сделать его char(1) и проверять на "Y", "N"
либо, если есть в оракле enum-ы (наподобие enum-ов в mysql или перечислимых типов в паскале), то использовать их

← →
AntiUser © (2007-02-27 23:50) [39]

Да нет ТЗ. Сижу без работы =( И чтобы не терять навыки и приобрести новые - пишу, но с оглядкой. Если получится удачно, то для малого предприятия (я пишу на основе последнего места работы) может и сгодится.

← →
Knight © (2007-02-27 23:54) [40]

Вот и говорю.. начни с ТЗ... Много чего прояснится для тебя самого %)

← →
AntiUser © (2007-02-27 23:55) [41]

> wicked © (27.02.07 23:49) [38]
> я бы обьединил их с серией и сделал одним varchar-ом
> вкратце - "если над полем по правилам предметной области НЕ ПРЕДУСМАТРИВАЮТСЯ
> арифметические действия, то тип поля нужно делать символьным"например:
> поле "номер дома", "номер накладной" нужно делать символьнымполе
> "коэффициент надбавки", "процент скидки" - числовым

Возможно вы и правы, может объединю.

Спасибо за разъяснение. А это негласное правило?

← →
AntiUser © (2007-02-27 23:57) [42]

> Knight © (27.02.07 23:54) [40]
> Вот и говорю.. начни с ТЗ...

=)
Ну вот, я несколько недель потратил на создание этой БД, а вы мне в середине разработки предлагаете ТЗ написать.

← →
Petr V. Abramov © (2007-02-28 00:01) [43]

> AntiUser © (27.02.07 23:55) [41]
> А это негласное правило?
фактически да. потому что в номерах чего угодно обязательно повится что-либо типа "1а" или "123/испр"

← →
Knight © (2007-02-28 00:04) [44]

> а вы мне в середине разработки

Это ещё несколько недель? Тогда точно проще начать с ТЗ ;)

← →
Petr V. Abramov © (2007-02-28 00:06) [45]

> В Oracle нет boolean"а поэтому пишу False default или True, конечно можно и 0-1 и еще как, но так мне нагляднее.
и будешь по жизни в своем True ошибаться с регистром.

← →
Petr V. Abramov © (2007-02-28 00:10) [46]

> Knight © (28.02.07 00:04) [44]
фигня это все, в данном случае ТЗ умещается в голове, в виде четкого понимания, чего нужно от приложения, а чего нет. А ради базы из 15 табличек бумагу марать не стОит, тем более, что человек один пишет.

← →
Knight © (2007-02-28 00:18) [47]

> [46] Petr V. Abramov © (28.02.07 00:10)

Часто небольшой набросок того что требуется... пусть даже на один-два листа.. и даёт это самое чёткое поимание, особенно в случае "Почему интересуюсь, потому что это мой первый..." :)

← →
AntiUser © (2007-02-28 00:19) [48]

> Petr V. Abramov © (28.02.07 00:06) [45]
> > В Oracle нет boolean"а поэтому пишу False default или
> True, конечно можно и 0-1 и еще как, но так мне нагляднее.
> и будешь по жизни в своем True ошибаться с регистром.

Уговорили =) Потому, что уже один раз столкнулся =)

> Petr V. Abramov © (28.02.07 00:10) [46]
> > Knight © (28.02.07 00:04) [44] фигня это все, в данном
> случае ТЗ умещается в голове, в виде четкого понимания,
> чего нужно от приложения, а чего нет. А ради базы из 15
> табличек бумагу марать не стОит, тем более, что человек
> один пишет.

Во! Действительно! А я тут сижу и думаю как отмазаться =)

Если еще не все потеряли интерес, то с удовольствием выслушаю все точки зрения.
Да же за эти 50 постов, я открыл для себя больше чем за последнюю неделю, работая над этим проектом.

← →
AntiUser © (2007-02-28 00:22) [49]

> Knight © (28.02.07 00:18) [47]

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

Ну да... с таким пониманием, можно и не такого накрутить %)

Шутка... не обижайся ;)

> Но с таким переплетением связей (особенно как в правом верхнем
> углу) - первый.

Бывает и такое:
http://patrony-na.front.ru/img/nightmare.jpg

:) Это мое (в соавторстве) творение.

> Knight © (28.02.07 00:23) [50]
> Ну да... с таким пониманием

Ну с каким - таким? Я-то все это понимаю и для чего связи и с чем, и зачем они связаны - тоже. Но при этом я еще попутно думаю как/какие классы буду создавать, что они будут делать и т.д. Вот и решил здесь спросить перед написанием интерфейса. И, как показала практика, не зря. Опытные глаза сразу выявили ненужные таблицы, про "аттрибутам-значениям, а не аттрибутам свойствам" узнал попутно, связь неверную обнаружил.
Так что, с пониманием - нормуль, главное, чтобы было кому это понимание мне донести, а это и есть эти опытные глаза, которые не одну такую (или примерно) бд слопатили.

Глянул схемку... Попробую дать совет. Как делается у нас. Для полей в каждой таблице выбирается префикс и имя каждого поля в таблице начинается с префикса. Ну, например, для таблицы Employee логичным выглядит префикс emp. То есть в Вашем примере поля назывались бы:

emp_ID
emp_Surname
emp_Name
...
и т.д.
Что это дает?
1. одно и то же по смыслу поле всегда называется одинаково (у Вас сейчас ID в таблице Employee и EMP_ID в таблицах, которые ссылаются на Employee).
2. Если делаются объединения таблиц, то поля не нужно переименовывать в запросе (в Вашем случае, если делается соединение двух таблиц, содержащих, например, поле Name, одно из полей придется переименовать в запросе).
3. Следствие из (2). Когда Вы глядите на результат запроса, сразу понятно, из какой таблицы поле пришло (префиксы часто легко оседают в памяти).

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

Почитал по диагонали все предыдущие советы, так что может быть повторю кого-нибудь.
1. Я не увидел иерархической зависимости подразделений и людей. Для кадров это важно.
2. Писать "от нечего делать" на Оракле кадры для малого предприятия - это, ИМХО, полная утопия. Просто кадры (как самостоятельная задача) малому предприятию не нужны - на 10-20 человек никто и не будет это вести. Если предполагается зарплата, то это не отражено и все равно кажется сомнительным нужда в кадровой подзадаче - достаточно списка работников. Ну и юзать Оракл для малого предприятия - тоже ИМХО слишком уж круто. Т.е. налицо явный маркетинговый просчет. А для большого предприятия - там все несколько сложнее устроено (насколько я помню - я курировал подобную задачу) и этой схемки будет явно недостаточно. Т.е. все это нормально (с учетом замечаний) для курсового проекта или просто экзерсисов для самосовершенствования, но явно недостаточно для какого-либо реального внедрения.

> AntiUser © (27.02.07 20:18) [6]
> > Empleado © (27.02.07 19:14) [2]
> Да, может. О том, какой активный - не подумал, возможно
> рационально.

Возможно стоит указать obsolete, т.к. активных паспортов может быть несколько.
Например, у Гусинского их теперь три :)

> > Empleado © (27.02.07 19:18) [3]
> А как же описать связь?

Добавить emp_id и соответствующую связь в таблицу passport?

Возможно повторюсь, т.к. возможно пропустил что-то из уже сказанного выше:

1) таблица passport_name. Я так понимаю, что это passport_type?

2) таблица emp_additions
Если никакие другие таблицы на нее не ссылаются, может сделать PK из (emp_id; ord_id), а id совсем выбросить?
Смотри по аналогии orders_on, где id нужен; а вот уже в otdel_job - id фактически не нужен, и можно сделать PK из трех полей;
и т.д. для всех подобных ситуаций

3) orders_name - это orders_type? :))

4) таблицы job, otdel, orders;
Зачем нужен ord_id в otdel? По данному смыслу: он показывает к какому Заказу принадлежит Отдел - что не имеет смысла.
Можно добавить еще одну таблицу отношений между otdel и orders, например: orders_per_otdel (otdel_id, ord_id; PK = [otdel_id, ord_id]), и сослаться на эту таблицу из otdel и orders. Тогда ord_id можно убрать из otdel.
Если уж надо оставить так по каким-то соображениям, то: С подобной связью не всегда удобно программировать.

5) address: Адрес не имеет номера телефона. В общем случае телефон прикреплен к человеку (НО, возможно я ошибаюсь!)

6) Если уж идет растасовка на адреса (домашний, рабочий, адрес доставки товара, временный и т.д.), то почему нет подобного для communication devices, например? Т.е. Один человек может иметь: сотовый (а иногда и два), факс, е-mail, телефон жены/тещи, skype account и т.д....

7) что показывает связь между job и orders?

Всего доброго.

Пересмотреть связку таблиц: employee - otdel_job - job - otdel

Дано:
Работнички (одна таблица)
(Q: Один работник может быть одновременно в двух и более отделах?(PS. у нас в конторе - может))
Должности (одна таблица)
(Q: Один работник может занимать две и более должности?)
Отделы (одна таблица)
(Q: Список должностей по отделам - так ли он необходим?)
Заказы (одна таблица)
(Q: От чего зависят заказы?)

Остальное - отношения между ними, описанные, в общем случае, отдельными таблицами (но необязательно - зависит от смысла), ссылающимися на эти четыре.

ПС. "Q:" - вопрос на обдумку :))

Всего доброго.

Писал "Кадры" 2 года назад для организации 450 сотрудников, структура значительно сложнее - 74 таблицы. Времени ушло почти год (долго придумывал саму концепцию), но заказчик очень доволен, потому что прога специфическая, под конкретное учреждение. Цена вопроса 250$, больше она и не стоит.

Начни с изучения документов, в первую очередь Трудовой кодекс РФ, ОКИН, ОКСО и т.д. Очень помогло изучение аналогичного ПО от "ОАЗИС" и 1С, журнал "Справочник кадровика", инструкция МО "О постановке на воинский учет" и др. ведомственные документы.

Все отделы в одну таблицу с ID, Parent_ID.

Имена полей лучше русские транслит. т.к., могут быть сложные термины, перевести и коротко записать которые проблематично.

Есть такая штука "Личная карточка", знаешь?

> Sergey13 © (28.02.07 08:54) [57]
> 1. Я не увидел иерархической зависимости
> подразделений и людей. Для кадров это важно.

Возможно вы и правы. А ка это лучше оформить? В виде поля с приоритетом 1,2,3 и т.д.?

> Empleado © (28.02.07 11:36) [58]

С этим ясно.

> Empleado © (28.02.07 12:10) [59]

1. Да.
2. В общем, может вы и правы. Подумаю. Спасибо.
3. Да.
4. ORDERS, это приказы.
5. В общем случае телефон прикреплен к человеку (НО, возможно я ошибаюсь!)
Да, скорее всего, то что в скобках ;)
6. За допонительные телефоны отвечает таблица TELEPHONE. Об этом выше обсуждалось.
7. Приказы по должности.

> Empleado © (28.02.07 12:28) [60]
> Пересмотреть связку таблиц: employee - otdel_job - job -
> otdelДано: Работнички (одна таблица) (Q: Один работник
> может быть одновременно в двух и более отделах?(PS. у нас
> в конторе - может))Должности (одна таблица) (Q: Один работник
> может занимать две и более должности?)Отделы (одна таблица)
> (Q: Список должностей по отделам - так ли он необходим?)Заказы
> (одна таблица) (Q: От чего зависят заказы?)

На все Q - да, кроме последнего, это не заказы, а приказы.

> DrAndrey © (28.02.07 15:22) [61]
> Есть такая штука "Личная карточка", знаешь?

Про прочтение, это хорошо, но не сейчас, т.к. задача стоит проще и (в основном) пишется дляприобретения навыков создания БД.

Про "Личная карточка" незнаю. Что это?

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

>Про прочтение, это хорошо, но не сейчас...

После того как сотряпаешь базу по своей чудовищной схеме, читать уже будет поздно. А если <для приобретения навыков создания БД>, то на мой взгляд, задача слишком сложная. Поверь мне, когда я начинал свои "Кадры", то тоже думал, что все так просто и быстро.

> DrAndrey © (28.02.07 18:23) [63]

Так у вас БД была под заказ, ха деньги, по ГОСТ"ам, а у меня для освоения принцыпов бд.

> [62] AntiUser © (28.02.07 18:14)

> А ка это лучше оформить? В виде поля с приоритетом 1,2,3 и т.д.?
Нет. Классический способ - поля Id и Parent_Id. Второе ссылается на первое. В Оракле такая структура на ура раскручивается через запросы с connect by.

>4. ORDERS, это приказы.
ОК.
Тогда получается, что отношение otdel --> orders указывает на Приказ, на основании которого отдел был создан? (т.к. возможна ссылка из Отдела только на один Приказ)

Есть приказы. А дальше - все, что ссылается на них: кем выдан, на кого распространяется и т.д.
Есть отделы....

>>7) что показывает связь между job и orders?
>7. Приказы по должности.

Переименовать ВСЕ таблицы!!! :)) Не шучу!

А вот еще автору ветки вопрос на "подумать".
Ситуация: Приказом A работник B переведен с должности C на должность D. Что делать будете?

> Sergey13 © (01.03.07 08:35) [65]

Т.е. дерево?

> Empleado © (01.03.07 11:32) [66]
> Переименовать ВСЕ таблицы!!! :)) Не шучу!

На счет приказов по отделу - да. Но типы приказов могут быть разные. В общем надо подумать.

Про переименовать. И как вы себе это видите?

> vuk © (01.03.07 12:07) [67]

Обязательно отвечу.

Просто сейчас 39 температура, не до этого, извиняйте.

> vuk © (01.03.07 12:07) [67]
> А вот еще автору ветки вопрос на "подумать".Ситуация: Приказом
> A работник B переведен с должности C на должность D. Что
> делать будете?

А чего думать-то, работника А снимаем с должности С на основании приказа А и назначаем на должность D на основании того же приказа.
А как вы это видите?

Покритикуйте, посоветуйте. Найти похожие ветки