2.2. Этапы проектирования банка данных.
Как отмечалось выше, структуру банка данных определяют конкретный состав баз данных в банке и их связи между собой. Спроектировать структуру банка означает определить все информационные единицы (базы данных, состав полей) и связи между ними; задать их имена. Рассмотрим этапы предварительного проектирования структуры банка данных. Их последовательное выполнение позволит Вам грамотно спроектировать структуру банка данных.
Совет. Для того чтобы научиться правильно проектировать структуру банков данных, возможно, Вам следует посетить специальные семинары, проводимые НПК «Кронос-Информ». Так же НПК «Кронос-Информ» предоставляет услуги по индивидуальному проектированию банков данных. Более подробную информацию Вы можете получить по телефону 450-11-79 и 450-67-43 или в Интернет по адресу http://www.cronos.ru/.
Этап 1: Исследование предметной области. Прежде всего, следует решить, для чего создается банк данных. Т.е. какие задачи он должен решать, и какая информация в нем будет храниться. Исходя из этого, можно определить, какие базы данных будут входить в банк данных. И из каких полей должны состоять эти базы данных. Таким образом, для определения структуры банка данных необходимо сначала исследовать предметную область.
Банк данных создается в первую очередь для автоматизации работы с информацией. Возможно, Вы уже используете данную информацию, но хотите упростить работу, посредством создания банка данных. В такой ситуации будет полезно собрать все документы, в которых сейчас накапливается информация, и определить алгоритмы ее обработки в сегодняшнем (ручном) варианте.
Или же Вы создаете банк данных, что называется «с нуля». В любом случае, попробуйте поставить вопросы, на которые должен давать ответ Ваш банк данных. Возможно, Вам следует побеседовать с людьми, которые уже работают с банками данных
Вся собранная Вами информация о предметной области понадобится на следующих этапах проектирования банка данных. Чем больше информации о задачах, которые будут поставлены перед банком данных, Вы соберете, тем лучше.
Пример. Предположим, требуется создать банк данных, который будет использоваться в кадровом агентстве (дадим ему название «Primer»). В нем будет накапливаться информация о лицах, ищущих работу (соискателях). Данные, которые будут заноситься в банк, поступают в самом различном виде. Это может быть анкета, выписка из трудовой книжки, ксерокопия диплома об образовании, справки и свидетельства об окончании курсов. Все поступающие данные, проверяются сотрудниками кадрового агентства. Таким образом, соискатель должен указывать полную информацию о предыдущих местах работы (не только название организации и должность, но и адрес, и телефон организации, сфере деятельности и основном виде деятельности). Сотрудник кадрового агентства наводит справки об этой организации. Затем о том, действительно ли соискатель занимал в ней указанную должность, причинах увольнения, отзывах начальника и коллег. Это делается, для того чтобы информация о лицах, ищущих работу, была достоверной, т.к. агентство дорожит своей репутацией.
В отношении уровня образования соискателя, такой строгий контроль не проводится. Во-первых, потому что общие знания играют меньшую роль при устройстве на работу, чем профессиональные навыки (работодателя интересует в первую очередь опыт работы, а во вторую образование). А во-вторых, каждый соискатель, обратившийся в данное агентство, проходит тестирование. Оно включает в себя психологический тест, тест на уровень владения иностранными языками и тест на профпригодность, в соответствии с должностью, на которую претендует соискатель. Результаты тестирования также заносятся в банк данных.
Этот банк создается, для того чтобы упростить поиск информации о конкретном лице, когда это понадобится. А также, для того чтобы при необходимости определить потенциальных работников, отвечающих заданным требованиям (например, тех, кто может занять освободившуюся должность). Причем, в качестве требований могут выступать наличие опыта работы, пол, возраст, образование, гражданство, район проживания, владение иностранными языками и.д. Однако в реальной ситуации, требования работодателя могут оказаться непредсказуемыми. Поэтому чем больше данных о лицах, ищущих работу, имеется в банке, тем лучше.
Следует отметить, что информация о соискателе не уничтожается после того, как он определен на работу. Это означает, что размеры банка данных постоянно увеличиваются, и количество записей в банке со временем может достигать нескольких десятков или даже сотен тысяч.
Совет. Не стоит «держать в голове» информацию, собираемую в процессе проектирования. Записывайте все полученные данные, а также свои идеи. Результаты последующих этапов будет удобнее не только записывать, но и фиксировать в виде схем. Ниже (см. Рис. 2.7) Вы найдете схематичное изображение результатов проектирования для приведенного примера.
Этап 2: Определение баз данных. На этом этапе Вы должны решить, какие базы данных будут входить в банк, и дать им названия. Ранее Вы определили содержимое банка данных. Теперь его следует разбить на несколько разделов, такие как «Лицо, ищущее работу», «Организация», «Трудовая деятельность» и т.д. Каждый такой раздел станет отдельной базой данных в проектируемом банке.
Это наиболее сложный этап проектирования. Вам следует ориентироваться на то, какие результаты должны быть получены при использовании банка данных. Но дело в том, что подобный подход не всегда дает точный ответ на вопрос, какие базы данных будут входить в проектируемый банк. Подобным образом можно узнать какую информацию вообще следует включить в банк данных. Однако вопрос о том, как эту информацию следует распределить по базам данных, остается открытым.
Возможно, Вам не удастся сразу же правильно выделить базы данных в банке. Не расстраивайтесь, это обязательно выяснится на следующих этапах проектирования. И Вы сможете исправить допущенные ошибки.
Пример. Мы знаем, что в банк данных «Primer» следует включить информацию о лицах, ищущих работу (соискателях). Известно, какого рода критерии (требования) важны для работодателей. Это означает, что банк будет содержать информацию, которая позволяет узнать не только общие данные о соискателе, но и о его личных особенностях, знаниях и умениях. Попробуем разбить эту информацию на несколько разделов. Для начала можно определить три раздела: личные данные, уровень образования и профессиональная (трудовая) деятельность. Т.е. выделить в проектируемом банке три базы данных. Назовем их «Лицо, ищущее работу», «Образование» и «Трудовая деятельность», соответственно.
Первая база данных («Лицо, ищущее работу») будет содержать информацию общего характера: фамилию, имя, отчество, пол, адрес и т.д. Вторая («Образование») – сведения о получении высшего образования, окончании курсов, знании языков, результатах тестирования в агентстве и т.д. А третья («Трудовая деятельность») – данные обо всех предыдущих местах работы соискателя, занимаемых должностях, причинах увольнения и т.д.
Однако возможна такая ситуация, когда несколько соискателей одновременно или в разные периоды работали в одной организации. Как было указано выше, для того чтобы можно было навести справки, соискатель указывает полную информацию о предыдущих местах работы. Т.е. потребуется для каждого соискателя дублировать данные об одной и той же организации. Поэтому для хранения данных об организациях будет целесообразно выделить четвертый раздел. Значит, в банке появляется еще одна база данных – «Организация».
Так как агентство стремится к достижению максимального уровня достоверности информации, нельзя упускать из виду проблему адресов. Если какой-то адрес изменился (например, переименовали улицу или город), то соответствующую информацию обо всех соискателях и организациях потребуется проверить и обновить. Если же выделить отдельный раздел для хранения адресов, проблема значительно упростится. Во-первых, даже если несколько соискателей будут проживать по одному адресу, данные об адресах не будут дублироваться. Т.е. уменьшится количество записей, которые необходимо проверить, и, следовательно, вероятность ошибки. А во-вторых, поиск упростится, т.к. нужно будет просмотреть только одну базу данных, а не две. Таким образом, следует добавить в банк еще одну базу данных «Адрес». И теперь информация об адресе соискателя и адресе организации будет храниться здесь, а не в базах «Лицо, ищущее работу» и «Организация».
Примечание. Следует отметить, что описанное выше разбиение банка на разделы (базы данных) является только примером. Если немного изменить предметную область, возможно, будут выделены другие разделы, хотя содержание банка вообще не изменится. Например, если бы в описании предметной области не было указано, что требуется проверка данных о местах работы. Тогда было бы достаточно хранить в базе «Трудовая деятельность» название организации, в которой ранее работал соискатель, а не выделять отдельную базу «Организация». Или если бы в агентстве не проводилось тестирование соискателей, а проверка уровня образования осуществлялась бы аналогично проверке фактов трудовой деятельности, возможно, потребовалось бы выделить дополнительную базу для хранения сведений о местах получения образования (например, «Образовательные учреждения»).
Таким образом, проектируя свой банк и выделяя в нем базы данных, Вы можете руководствоваться приведенным примером. Однако следует помнить, что он не является универсальным. И что, ответ на вопрос о том, из каких баз данных будет состоять банк, зависит в первую очередь от предметной области.
Этап 3:Определение полей.3 На этом этапе следует определить, какую информацию должна содержать каждая база данных, т.е. из каких полей она должна состоять. Для этого необходимо решить, какие именно сведения будут храниться в этой базе. Каждое поле должно соответствовать общей смысловой направленности базы данных. Например, в базе данных «Трудовая деятельность» будет неуместным поле «Знание языков». Это поле лучше поместить в другую базу, например, в базу «Образование». Если несколько баз содержат одинаковые поля, это означает, что некоторые базы дублируют данные других баз.
В предыдущей главе были описаны важнейшие свойства полей (тип поля, его обязательность для заполнения, а также является ли оно множественным). Вам следует учитывать возможность того, что определяемые поля будут иметь эти или другие свойства. Т.е., если Вы видите, что поле следует определить как множественное (кратное), сделайте для себя соответствующую пометку. Задавать свойства полей Вы будете позднее, при непосредственном проектировании банка данных в ИСУБД «CronosPlus». Поэтому, полное перечисление и описание свойств полей приведено ниже, в главе 4 (см. раздел 4.3).
Старайтесь, чтобы информация, хранящаяся в поле, соответствовала одному, логически неделимому элементу информации. Хранение нескольких элементов информации в одном поле, затрудняет извлечение и обработку отдельных элементов из этого поля. Не стоит, например, хранить в одном поле фамилию, имя и отчество клиента. Лучше разбить эту информацию на три поля: «Фамилия», «Имя» и «Отчество».
Совет. После того как Вы определите состав полей каждой базы, вернитесь к информации, собранной на первом этапе проектирования. Убедитесь, что все данные, которые требуются для решения задач, поставленных перед банком, включены в базы данных.
Пример. Определим поля базы данных «Лицо, ищущее работу» банка «Primer». На предыдущем этапе было решено, что эта база будет содержать информацию общего характера. Теперь следует уточнить, какие именно данные будут храниться в конкретных полях. Безусловно, следует выделить поля «Фамилия», «Имя», «Отчество», «Дата рождения», «Пол», «Гражданство». Причем необходимо отметить, что все эти поля следует сделать обязательными. Соискатель может иметь, например, двойное гражданство. Следовательно, поле «Гражданство» нужно определить как кратное.
Возвращаясь к результатам, полученным на первом этапе, следует учитывать возможность появления нестандартных требований работодателей. Т.е. чем больше данных о лицах, ищущих работу, имеется в банке, тем лучше. Поэтому мы включим в базу «Лицо, ищущее работу» поля «Фотография» и «Дополнительная информация» (это поле также имеет смысл сделать кратным).
Теперь определим поля базы «Образование». В отношении полученного соискателем образования, нас интересует где, в какой период и чему учился соискатель. Поэтому в базу «Образование» мы включаем следующие поля: «Учебное заведение», «Дата начала обучения», «Дата завершения обучения» и «Направление (специальность)». Однако на предыдущем этапе было решено, что база «Образование» должна содержать сведения не только о получении высшего образования и окончании курсов, но и о результатах тестирования в агентстве. Если добавить в базу «Образование» поля, содержащие информацию о результатах тестирования, придется дублировать эти данные для всех записей, соответствующих одному соискателю. При этом будет совершенно непонятно, какое отношение, например, окончание курсов машинописи, имеет к знанию иностранных языков. Ведь если данные хранятся в одной базе данных, значит они связаны между собой по смыслу.
Все это приводит к мысли, что данные о результатах тестирования еще на предыдущем этапе следовало выделить в отдельный раздел и хранить в отдельной же базе данных. Т.е. была допущена ошибка при определении баз данных. Однако, т.к. ее удалось вовремя выявить, ничего страшного не произошло. Этот факт лишний раз доказывает, что при проектировании можно и нужно возвращаться к результатам предыдущих этапов и, при необходимости, исправлять их.
Теперь мы знаем, что следует выделить еще одну базу данных. Назовем ее «Результаты тестирования» и определим, какие поля будут входить в эту базу. Это поле, содержащее информацию о том, на какую должность претендует соискатель (ведь тестирование проводится в соответствии с должностью), назовем его «Претендует на должность». И поля, в которых будут храниться результаты тестирования: «Сумма баллов по психологическому тесту», «Сумма баллов по тесту на профпригодность» и «Сумма баллов по тесту на знание языков». Причем последнее поле следует определить как кратное, т.к. соискатель может владеть не одним, а несколькими иностранными языками.
Этап 4: Определение связей между базами данных. Добавление сложных полей. Прежде чем говорить об установлении связей, необходимо дать соответствующее определение. Возможно, оно покажется Вам слишком сложным. Поэтому далее приведены пояснения, которые дают более четкое понимание того, что же такое связь.
Две записи, двух различных баз данных, называют связанными, если записи одной базы поставлена в соответствие запись другой базы. Что значит «поставлена в соответствие»? Представьте себе человека. Он имеет фамилию Иванов и проживает по некоторому адресу. Можно сказать, что Иванову соответствует этот адрес. А также, что этому адресу соответствует человек по фамилии Иванов. Теперь представьте, что Вам требуется описать эту ситуацию в банке данных. Банк состоит из двух баз данных: «Лицо» и «Адрес». В базе «Лицо» Вы найдете запись об Иванове, а в базе «Адрес» запись о данном адресе. Для того чтобы указать, что Иванов проживает по данному адресу, Вы должны поставить в соответствие две найденные записи. Т.е. установить между ними связь. После того как связь установлена, говорят, что эти записи связаны между собой или, иначе, ссылаются друг на друга.
Встает вопрос, почему говорят о связи двух баз, если связывают не базы, а их записи. Дело в том, что в действительности нельзя просто взять и связать две любые записи. Для этого структура соответствующих баз должна позволять устанавливать связи между их записями. Под структурой базы данных мы понимаем в первую очередь состав полей, входящих в каждую запись базы. В ИСУБД «CronosPlus» существует специальный, ссылочный тип поля. Поле такого типа не предназначено для хранения обычных данных, оно содержит информацию о том, с записями каких баз данных могут быть связаны записи данной базы. Эта информация называется ссылкой(ами) на базу(ы) данных.
Итак, подводя итог сказанному, следует различать понятия «связанные базы» и «связанные записи». На уровне определения структуры базы данных говорят, что эта база связана с некоторыми другими базами. Когда же речь идет о заполнении ссылочных полей в какой-то записи базы данных, говорят об установлении связи между записью данной базы и записями другой базы.
Условимся называть ссылочные поля сложными, а информационные поля, т.е. те которые предназначены для хранения обычных данных, – простыми.
Сложное поле, как и простое, должно иметь имя. Рекомендуется давать таким полям имена, отражающие смысловую окраску связей, которые они содержат.
Таким образом, в нашем примере, для того чтобы связать запись об Иванове базы данных «Лицо» и запись об адресе базы «Адрес», обе эти базы должны кроме прочих иметь сложные (ссылочные) поля. Причем сложное поле базы «Лицо» (назовем его «Проживает по адресу») должно содержать ссылку на аналогичное сложное поле (назовем его «Является адресом лица») базы «Адрес», и наоборот. Т.е. связь обязательно должна быть двусторонней! Графически данный пример изображен на Рис. 2.1.
-
-
База «Лицо»
|
|
База «Адрес»
|
Фамилия
|
|
Город
|
Имя
|
|
Улица
|
Отчество
|
|
№ дома
|
…….
|
|
…….
|
П роживает по адресу
|
|
Является адресом лица
|
Рис. 2.1. Связь между двумя базами данных.
Возможна ситуация, когда две базы имеют не одну связь, а две. Например, нас интересует не только сегодняшнее место жительство лица, но и предыдущее. В этом случае, базы «Лицо» и «Адрес» будут иметь не одну пару взаимосвязанных сложных полей, а две: «Проживает по адресу»/«Является адресом лица» (см. предыдущий пример) и «Ранее проживал по адресу»/«Ранее являлся адресом лица». Данная ситуация показана на Рис. 2.2.(а).
Следует отметить, что одно сложное поле базы данных не может ссылаться одновременно на два разных поля (сложных) другой базы. Такое (неверное) установление второй связи показано на Рис. 2.2.(б).
База «Лицо»
|
|
База «Адрес»
|
|
База «Лицо»
|
|
База «Адрес»
|
Фамилия
|
|
Город
|
|
Фамилия
|
|
Город
|
Имя
|
|
Улица
|
|
Имя
|
|
Улица
|
Отчество
|
|
№ дома
|
|
Отчество
|
|
№ дома
|
…….
|
|
…….
|
|
…….
|
|
…….
|
Р   анее проживал по адресу
|
|
Ранее являлся адресом лица
|
|
Проживает (или проживал ранее) по адресу
|
|
Ранее являлся адресом лица
|
Проживает по адресу
|
|
Является адресом лица
|
|
|
Является адресом лица
|
а) Верно установленная связь.
|
|
б) Неверно установленная связь.
|
Рис. 2.2. Двойная связь между базами данных.
Примечание. Однако если сложное (ссылочное) поле сделать кратным, запись одной базы данных может быть связана с несколькими записями другой базы. Т.е., если Иванов проживает одновременно по двум адресам (в двух разных квартирах по очереди, например), запись, содержащая информацию об Иванове, будет ссылаться на две записи базы данных «Адрес».
Связать между собой можно не только две базы данных. Как Вы уже поняли, в базе может быть не одно, а несколько сложных полей. Это означает, что одну базу данных можно связать с двумя, тремя и более другими базами (см. Рис. 2.3). Главное, чтобы в базе было соответствующее количество сложных полей, содержащих ссылки на связанные базы. А в связанных базах, в свою очередь, были сложные поля, содержащие ссылку на эту базу.
Несмотря на то, что одно сложное поле базы данных не может ссылаться на два сложных поля другой базы, возможна ситуация, когда такое поле имеет две ссылки. Но это должны быть ссылки на сложные поля двух разных баз данных. На Рис. 2.3. Вы видите, что поле «Является адресом лица или организации» ссылается на два сложных поля: «Проживает по адресу» базы «Лицо» и «Находится по адресу» базы «Место работы».
База «Место работы»
|
|
База «Лицо»
|
|
База «Адрес»
|
Название организации
|
|
Фамилия
|
|
Город
|
Телефон
|
|
Имя
|
|
Улица
|
Сфера деятельности
|
|
Отчество
|
|
№ дома
|
…….
|
|
…….
|
|
…….
|
О тносится к лицу
|
|
Место работы лица
|
|
Является адресом лица или организации
|
Н    аходится по адресу
|
|
Проживает по адресу
|
|
Р ис. 2.3. Связь между тремя базами. Сложное поле имеет две ссылки на разные базы.
В отдельных случаях устанавливают связь базы с самой собой. Это означает, что записи одной базы данных могут ссылаться друг на друга. Например, нас интересует, являются ли лица, информация о которых содержится в базе, родственниками. Для этого в базе «Лицо» введем сложное поле «Является родственником» (так как родственников может быть несколько, поле будет кратным). Это поле будет содержать ссылку само на себя (см. Рис. 2.4). Таким образом, на уровне записей, две записи которые ссылаются друг на друга, соответствуют лицам, являющимся родственниками.
-
-
-
-
-
-
База «Лицо»
|
Фамилия
|
Имя
|
Отчество
|
…….
|
Я  вляется родственником
|
Рис. 2.4. Сложное поле базы данных ссылается само на себя.
Если усложнить этот пример и фиксировать не только факт, но и степень родства, ситуация будет несколько иной. Если учитывать только два варианта, т.е. близкие родственники и дальние родственники, достаточно ввести два сложных поля, вместо одного: «Является близким родственником» и «Является дальним родственником» (см. Рис. 2.5).
На уровне записей, это будет означать, что для записи базы данных «Лицо» поле «Является близким родственником» будет содержать ссылки на записи, в которых содержится информация о близких родственниках. А поле «Является дальним родственником», соответственно, на записи, содержащие информацию о дальних родственниках.
-
-
-
-
-
База «Лицо»
|
Фамилия
|
Имя
|
Отчество
|
…….
|
Я вляется близким родственником
|
Является дальним родственником
|
Рис. 2.5. Два сложных поля базы данных ссылаются сами на себя.
Однако если для нас важно точно знать, кем приходятся друг другу два лица, мужем и женой или братом и сестрой и т.п., потребуется ввести дополнительную базу, предназначенную специально для связи. Т.е. база данных «Лицо» будет ссылаться сама на себя не напрямую, а через дополнительную базу «Степень родства». Между двумя этими базами будет установлено две связи. При этом база «Степень родства» будет состоять всего из трех полей: одного простого поля «Степень родства» и двух сложных. Подобные ситуации встречаются довольно редко, и использовать такой «механизм» связи, в общем, не рекомендуется. Тем не менее, Вы должны знать о том, что в ИСУБД «CronosPlus» реализована и такая возможность.
На уровне записей это означает, что, например, некоторая запись базы данных «Лицо», содержит информацию об Иванове Сергее. Известно, что в этой базе данных, также имеются данные об Ивановой Ольге, которая приходится Иванову Сергею женой. Запись об Иванове Сергее в поле «Состоит в родстве с …» будет содержать ссылку на поле «Является родственником» некоторой записи базы «Степень родства». Последняя, в простом поле «Степень родства», содержит значение «жена». А в сложном поле «Состоит в родстве с …» ссылку на сложное поле «Является родственником» записи базы «Лицо», которая в свою очередь содержит данные об Ивановой Ольге.
-
-
База «Лицо»
|
|
|
Фамилия
|
|
|
Имя
|
|
|
Отчество
|
|
База «Степень родства»
|
… ….
|
|
Является родственником
|
Состоит в родстве с …
|
|
Степень родства
|
Является родственником
|
|
Состоит в родстве с …
|
Рис. 2.6. База данных ссылается сама на себя, посредством дополнительной базы.
Итак, для того чтобы определить, как связать между собой базы данных в Вашем банке, изучите каждую базу данных и решите, каким образом данные в ней должны быть связаны с данными в других базах данных. При необходимости, добавьте новые (сложные) поля в существующие базы данных или создайте новые базы данных, предназначенные специально для связи.
Пример. Необходимо определить связи между базами данных в банке «Primer». Ранее мы решили, что этот банк состоит из шести баз данных: «Лицо, ищущее работу», «Образование», «Результаты тестирования», «Трудовая деятельность», «Организация» и «Адрес». Записям базы данных «Лицо, ищущее работу» следует поставить в соответствие записи баз «Образование», «Трудовая деятельность», «Результаты тестирования» и «Адрес». Т.е. установить связь между базой данных «Лицо, ищущее работу» и перечисленными базами. Для этого в структуру базы «Лицо, ищущее работу» к уже имеющимся полям нужно добавить сложные поля «Имеет образование», «Места работы», «Результаты тестирования» и «Проживает по Адресу». Соответственно в базах «Образование», «Трудовая деятельность», «Результаты тестирования» и «Адрес» определяем по одному полю «Относится к лицу».
Записи базы «Трудовая деятельность» нужно связать с записями базы «Организация». Для этого в обе эти базы добавим сложные поля «Конкретное место работы» и «Является местом работы лица» соответственно. Т.к. в базе «Адрес» содержатся адреса не только соискателей, но и организаций, кроме связи с базой «Лицо, ищущее работу» следует добавить связь с базой «Организация». Т.к. в базе «Адрес» уже есть сложное поле, мы просто переименуем его в «Относится к лицу, организации». А в базе данных добавим новое сложное поле «Адрес».
Результаты первых четырех этапов проектирования для приведенного примера Вы можете увидеть на Рис. 2.7.
База «Образование»
|
|
База «Лицо, ищущее работу»
|
|
База «Адрес»
|
Учебное заведение
|
|
Фамилия
|
|
Страна
|
Дата начала
|
|
Имя
|
|
Район
|
Дата окончания
|
|
Отчество
|
|
Область
|
Направление (специальность)
|
|
Дата рождения
|
|
Населенный пункт
|
Пол
|
Улица
|
О тносится к лицу
|
|
Гражданство
|
|
№ дома
|
|
|
Проживает по Адресу
|
|
№ квартиры
|
   
|
|
Места работы
|
|
Относится к лицу, организации
|
Имеет образование
|
Б аза «Результаты тестирования»
|
|
Результаты тестирования
|
|
|
Фотография
|
Балл по психологическому тесту
|
|
Дополнительная информация
|
|
База «Организация»
|
Претендует на должность
|
|
|
|
Название
|
Тип организации
|
Балл по тесту на профпригодность
|
|
База «Трудовая деятельность»
|
|
Сфера деятельности
|
Основной вид деятельности
|
Балл по тесту на знание иностранных языков
|
|
Относится к лицу
|
|
|
Должность
|
|
Телефон
|
Относится к лицу
|
Дата начала
|
Адрес
|
|
|
Дата окончания
|
|
Является местом работы лица
|
З/п в начале
|
|
|
З/п в конце
|
|
|
|
|
Причина увольнения
|
|
|
|
|
Конкретное место работы
|
|
|
Рис. 2.7. Результаты проектирования для банка данных «Primer».
|
