Проектирование информационно-поисковой системы "Регламенты НИУ ВШЭ-Пермь"
Анализ работы учебного офиса с регламентирующими документами. Моделирование бизнес-процессов TO-BE. Формулировка требований к информационной системе. Описание сущностей и связей между ними. Проектирование базы данных и пользовательского интерфейса.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | дипломная работа |
| Язык | русский |
| Дата добавления | 21.09.2018 |
| Размер файла | 2,6 M |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
- «Группа». Это поле является внешним ключом для связи «один-ко-многим» с таблицей «Группы». Имеет тип VARCHAR.
- «Должность». Это поле является внешним ключом для связи «один-ко-многим» с таблицей «Группы». Имеет тип TEXT, так как полное наименование должности может состоять более, чем из 255 символов. Является частью составного ключа.
Создав все описанные таблицы и установив между ними все связи, получаем схему данных, представленную на рисунке 2.5.
Рисунок 2.5. Физическая схема данных
Полученная схема позволяет реализовать хранение всех необходимых для работы информационной системы данных в файле базы данных на базе СУБД MySQL.
2.4. Проектирование прототипа пользовательского интерфейса
Проектируемую информационную систему можно условно разделить на два основных компонента: дерево кейсов с их наборами операций, и форум - площадку для обсуждения регламентных несогласованностей и неясных формулировок. Это стоит учесть при проектировании пользовательского интерфейса.
Для входа в систему будет использоваться пара логин-пароль, где логином будет являться адрес электронной почты сотрудника. Содержимое экрана входа может выглядеть как показано на рисунке 2.6.
Рисунок 2.6. Экран входа в систему
После авторизации пользователю предоставляется возможность выбрать кейс, чтобы ознакомиться с последовательностью операций для его решения. Для этого он может либо прокрутить список кейсов вниз, либо воспользоваться поиском.
Каждый кейс может быть представлен в виде карточки с его названием. Кейсы самого верхнего уровня могут быть по умолчанию развернуты и представлены как разделы, названия которых совпадают с названиями кейсов верхнего уровня. Карточки кейсов в каждом из кейсов-разделов могут иметь контур одного цвета. Строка поиска может располагаться над всеми карточками кейсов.
Макет страницы выбора кейса показан на рисунке 2.7.
Рисунок 2.7. Экран навигации по кейсам
За основу структуры навигации по кейсам для создания макета интерфейса была взята структура раздела «Студентам» Справочника учебного процесса корпоративного портала НИУ ВШЭ [11]. Это обосновано тем, что, как было выяснено в процессе интервьюирования сотрудников учебного офиса, процессы, рассмотренные в данном разделе, составляют большую часть их работы.
По клику по карточке одного из кейсов на экран должны выводиться его внутренние кейсы, если они существуют. Вид экрана с внутренними кейсами должен быть подобен виду экрана с навигацией по кейсам: он должен включать строку поиска и карточки кейсов. Кроме этого, над заголовком, содержащим название кейса, внутренние кейсы которого в данный момент отображаются на экране, должен отображаться путь по иерархии кейсов с верхнего уровня. Каждый элемент этого пути является гиперссылкой на страницу соответствующего ему кейса.
Фрагмент макета такой страницы показан на рисунке 2.8.
Рисунок 2.8. Вложенные кейсы
Если пользователь кликнул по карточке кейса, который не имеет вложенных кейсов, а содержит только список операций, должен отображаться экран с таблицей операций, которая должна включать все поля таблицы «Операции» базы данных. Также там может отображаться дополнительная к таблице информация, если такая имеется. В заголовке экрана отображается название кейса; над ним также отображается путь к текущему кейсу по иерархии кейсов. Пример такого экрана приведен на рис. 2.9.
Рисунок 2.9. Операции кейса
По клику на одну из операций (строк таблицы) в пустом блоке в правой части экрана должен отображаться список всех пунктов всех документов, которые регулируют выбранную операцию. Строка при этом должна подсвечиваться; в правой части должны выводиться названия документов, под ними списком тексты релевантных пунктов, в конце списка пунктов должна быть ссылка на страницу документа в разделе «Официальные документы» портала НИУ ВШЭ-Пермь. Справа от каждого пункта должен отображаться маркер наличия на форуме обсуждения этого пункта в привязке к выбранной операции.
Если обсуждения никогда не создавалось, маркер должен выглядеть как светло-серая выносная цитатная рамка со значком «+» внутри: . По наведении она становится черной, по клику ссылает на экран инициации нового обсуждения.
Если на форуме имеется обсуждение пункта, но ни одно из сообщений в нем не помечено модератором как решение, маркер справа от этого пункта должна выглядеть как выносная цитатная рамка оранжевого цвета со знаком многоточия внутри: . По клику она ссылает на экран соответствующего обсуждения на форуме.
Если на форуме имеется обсуждение пункта, и одно из сообщений помечено как решение, маркер должен выглядеть как выносная цитатная рамка зеленого цвета с «галочкой» внутри: . По клику он также ссылает на экран соответствующего обсуждения на форуме.
Макет экрана списка операций с выбранной операцией представлен на рисунке 2.10.
Когда пользователь переходит на экран инициации нового обсуждения пункта документа, на экран выводится блок для набора текста вопроса по этому пункту. Доступны возможности изменения кегля, начертания, цвета текста.
В следующем блоке на этом же экране должен быть реализован поиск сотрудников по части имени, фамилии, отчества или должности.
Рисунок 2.10. Операции кейса с выбранной кликом операцией
Также допускается ввод фрагмента названия группы должностей, в этом случае выводятся все должности этой группы. Из выдачи по поисковому запросу пользователь должен выбрать людей для добавления в обсуждение в качестве участников. Для этого предусмотрены кнопки справа от строк с найденными людьми, которые по клику добавляют людей в обсуждение и меняют вид с синей окружности на белую галочку в синем круге. Добавленные участники отображаются в строках в следующем блоке, расположенном справа от блока поиска и добавления людей в обсуждение. Справа от каждой записи в этом блоке предусмотрены кнопки для присвоения участнику роли модератора и для отмены выбора сотрудника в качестве участника обсуждения.
При пометке участника как модератора внешний вид кнопки выбора участника как модератора меняется с зеленой окружности на белую корону в зеленом круге.
При отмене выбора сотрудника в качестве участника строка с его именем исчезает из блока списка участников, также снимается соответствующая отметка в левом блоке, если сотрудник все еще отображается как один из найденных по запросу.
Макет этого экрана представлен на рисунке 2.11.
Когда текст вопроса введен, выбраны участники обсуждения и назначен(-ы) модератор(-ы), пользователь может создать обсуждение нажатием кнопки «Отправить» в блоке ввода вопроса.
Рисунок 2.11. Экран инициации диалога
При невыполнении хотя бы одного из вышеописанных условий попытка создать обсуждение приводит к выводу диалогового окна с предупреждением. По нажатии кнопки «Отмена» в блоке ввода текста вопроса пользователь возвращается на экран навигации по кейсам.
Когда обсуждение создано, пользователь попадает на страницу форума с этим обсуждением.
В верхнем блоке этого экрана находится текст вопроса, заданного при инициации обсуждения, автор вопроса, количество времени, прошедшего с момента публикации вопроса, название кейса и операции, к которым относится заданный вопрос и количество комментариев (сообщений), написанных на странице этого обсуждения с момента его создания (публикации на форуме).
Ниже располагается блок ввода текста сообщения, которое можно опубликовать комментарием к заданному вопросу. В верхней части данного блока указывается, от чьего лица будет опубликовано сообщение. Это определяется тем, под чьей учетной записью выполнен вход в информационную систему. Имеется возможность форматирования текста, аналогичная блоку ввода текста вопроса при создании обсуждения.
Макет страницы обсуждения на форуме с несколькими комментариями на разных уровнях представлен на рисунке 2.12.
Рисунок 2.12. Страница обсуждения
Под блоком ввода сообщения располагаются сообщения, написанные остальными участниками. Для удобства в этой части работы будем называть их комментариями. Каждый комментарий может быть оставлен либо непосредственно к заданному инициатором обсуждения вопросу, либо к одному из ранее оставленных участниками комментариев. В первом случае комментарий попадает в первый, самый внешний уровень. Комментарии одного уровня располагаются в блоках друг под другом; комментарии, находящиеся на внутренних по отношению к определенному комментарию уровнях, располагаются внутри блока этого комментария. Такие вложенные комментарии имеют тем больший сдвиг вправо относительно комментария внешнего уровня, чем на более глубоком уровне относительно него они находятся.
При нехватке для сдвига комментариев места на экране предусмотрено сворачивание блоков, содержащих комментарии на внутренних уровнях.
По нажатии на пустое место в верхней части комментария рядом с ФИО его автора комментарий со всеми вложенными в него комментариями сворачивается в узкий блок, содержащий только автора и время с момента публикации. При повторном нажатии действие отменяется.
В блоке каждого комментария подобно блоку с текстом вопроса содержится фамилия, имя и отчество (ФИО) сотрудника, оставившего комментарий, и время, прошедшее с момента публикации. ФИО создателя обсуждения в блоках его комментариев отображаются синим цветом и помечаются синим значком микрофона рядом справа от отчества. Под текстом комментария расположена кнопка «Ответить» и численный рейтинг комментария.
Кнопка «Ответить» предназначена для оставления ответа на рассматриваемый комментарий на внутреннем по отношению к нему уровне. По нажатии этой кнопки под его текстом отображается блок ввода комментария, над которым указывается, на чей комментарий пишется ответ, и от чьего лица он будет опубликован.
Слева и справа от рейтинга комментария расположены кнопки добавления балла к рейтингу или отнятия балла от него. Они имеют вид стрелок, направленных вверх и вниз соответственно. При нажатии на стрелку «вверх» рейтинг увеличивается на единицу, а стрелка окрашивается в красный цвет и становится неактивна. При нажатии на стрелку «вниз» рейтинг уменьшается на единицу, она окрашивается в синий цвет и также становится неактивна, при этом стрелка вверх принимает свой исходный вид. Аналогично стрелка «вниз» принимает свой исходный вид при нажатии на стрелку «вверх». Один пользователь может изменить рейтинг комментария только либо на единицу вверх, либо на единицу вниз.
Комментарии в обсуждении сортируются по рейтингу в пределах каждого уровня вложенности. При этом, если в результате изменения пользователем рейтинга комментария этот комментарий стал должен занимать другую позицию в списке, пересортировка происходит только при перезагрузке страницы. Это обеспечит постоянство положения комментариев относительно друг друга в рамках одной сессии просмотра обсуждения.
Если сотрудник, просматривающий обсуждение, является его модератором, для него предусмотрены дополнительные функциональные возможности. Его ФИО отображаются текстом зеленого цвета и помечаются зеленой иконкой в виде короны как для него самого над блоком для ввода комментария, так и для всех пользователей над текстом его комментариев в обсуждении (рис. 2.13).
Рисунок 2.13. Выделение ФИО модератора в комментариях
Кроме кнопки «Ответить» под всеми комментариями модератору также видна зеленая кнопка «Принять это решение» (рис. 2.14).
Рисунок 2.14. Кнопка принятия решения, доступная модератору
При принятии сообщения в качестве решения статус сообщения в базе данных меняется на «Решение», блок комментария выделяется зеленой рамкой и закрепляется выше всех остальных комментариев в обсуждении независимо от рейтинга (рис. 2.15). Кнопка «Принять это решение» сменяется красной кнопкой «Отменить решение», по нажатии на которое сообщению возвращается статус «Обычный» и снимается приоритет размещения и выделение зеленой рамкой.
Рисунок 2.15. Приоритет сообщения в статусе «Решение»
В том случае, когда модератору требуется агрегировать несколько сообщений с разных уровней, чтобы оформить решение заданного в заголовке обсуждения вопроса, ему следует самостоятельно написать комментарий, вставив в него необходимые выдержки из комментариев других участников, после чего пометить этот комментарий как решение.
Если комментарий, который модератор помечает как решение, находится не на внешнем уровне, он не меняет уровня, но содержащий его внешний блок занимает верхнее положение в списке комментариев независимо от рейтинга.
Со страницы любого обсуждения пользователь может вернуться на главную страницу форума. Для этого предусматривается кнопка «Назад», не показанная на макетах. На главной странице форума в отдельных блоках друг под другом отображаются заголовки (вопросы) всех созданных обсуждений, сопровождаемые ФИО инициатора обсуждения, количеством комментариев, прошедшим с момента публикации времени. Над списком обсуждений расположена строка поиска для отбора обсуждений по фрагменту вопроса в заголовке, ФИО автора, дате, названию операции или кейса. Макет основной страницы форума со списком обсуждений представлен на рисунке 2.16.
Рисунок 2.16. Главная страница форума
Также пользователь должен иметь возможность с любой страницы ИС попасть на страницу навигации по кейсам по нажатии на кнопку «Кейсы», также не показанную на макетах.
На странице навигации по клику по пустой карточке со знаком «+» должен отображаться экран добавления кейса. На нем пользователь вводит название кейса, затем либо заполняет таблицу операций в рамках него, либо сохраняет кейс пустым для дальнейшего добавления в него вложенных кейсов. В случае заполнения таблицы операций пользователь также должен прикрепить к операциям релевантные пункты регулирующих их документов. Добавленные кейсы, операции, связи между операциями и пунктами заносятся в базу данных. Макет страницы с добавлением кейса в этой работе не представлен, но он должен иметь вид, аналогичный виду экрана инициации обсуждения.
Заключение
В работе был описан процесс проектирования информационно-поисковой системы НИУ ВШЭ-Пермь.
В процессе работы были выполнены поставленные задачи:
1. Проведен анализ предметной области, в ходе которого был проведен анализ работы учебного офиса, проведено интервьюирование сотрудников и выделены бизнес-процессы, подлежащие автоматизации. Была создана модель процесса AS-IS и выявлены ее недостатки.
2. Определены требования к информационной системе, а именно: уточнены функции, которые должна выполнять система, разработана модель процесса TO-BE
3. Выполнено проектирование базы данных и пользовательского интерфейса системы.
Таким образом, была достигнута цель работы - спроектирована информационная система для решения регламентных противоречий.
Спроектированная информационная система может быть применена не только на базе НИУ ВШЭ-Пермь, но и в других организациях, использующих регулирующие документы в своей работе.
Для того, чтобы обеспечить поддержание данных в актуальном состоянии, возможно добавить функции импорта в спроектированную ИС актуальных данных о сотрудниках и других сущностях предметной области из внутренних информационных систем организаций.
бизнес информационный интерфейс
Библиографический список
1. Библиографическая ссылка. Общие требования и правила составления. ГОСТ Р 7.0.5-2008.
2. Дерево каталогов NESTED SETS (вложенные множества) и управление им.
3. Критерии выбора СУБД при создании информационных систем.
4. Модели данных.
5. Модели и их представления.
6. Официальные документы Высшей Школы Экономики.
7. Попов Ф.А., Максимов А.В. Подходы к проектированию баз данных для автоматизированных систем // Известия АлтГУ. 2003. №1.
8. Подходы к построению БД.
9. Подходы к проектированию базы данных.
10. Реляционная модель данных.
11. Справочник учебного процесса НИУ ВШЭ. Студентам.
12. Строим Nested Set дерево без рекурсии.
13. Хранение деревьев в MySQL.
14. Access specifications.
15. Adjacency List Model vs Nested Set Model for MySQL hierarchical data
16. MySQL what is the maximum size of a database?
Приложение А
Модель процесса TO-BE
Рисунок А.1. Общая модель процесса TO-BE
Приложение B
Диаграмма последовательностей: поведение ИС
Рисунок B.1. Поведение ИС
Приложение С
Результаты анализа связей модели ERD
Таблица C.1. Связи модели ERD
|
Сущность 1 |
Смысл связи |
Сущность 2 |
Тип связи |
Комментарий |
|
|
Сотрудник |
Занимает |
Должность |
(1,N:1,M) |
Один сотрудник может занимать много должностей, и на одной должности может работать несколько сотрудников. |
|
|
Сотрудник |
Пишет |
Сообщение |
(1,1:0,N) |
Сотрудник не обязан писать сообщения и может писать их много, но у любого сообщения должен быть автор, и только один. |
|
|
Сотрудник |
Принимает |
Решение |
(1,1:0,1) |
Сотрудник (модератор обсуждения) может принять одно и только одно решение либо не принять ни одного, и любое решение в обсуждении может быть принято только одним сотрудником (модератором). |
|
|
Сотрудник |
Участвует |
Обсуждение |
(1,N:0,M) |
Сотрудник может участвовать в одном или нескольких обсуждениях либо не участвовать в них, но в любом обсуждении должен участвовать хотя бы один сотрудник. |
|
|
Сотрудник |
Модерирует |
Обсуждение |
(1,N:0,M) |
Сотрудник может модерировать одно или несколько обсуждений либо не модерировать ни одного, но у любого обсуждения должен быть хотя бы один модератор. |
|
|
Группа должностей |
Включает |
Должность |
(0,N:1,M) |
Должность не обязана принадлежать к какой-либо группе, может принадлежать к нескольким; в любой группе должна быть хотя бы одна должность. |
|
|
Документ |
Содержит |
Пункт |
(1,1:0,N) |
Документ может содержать один или несколько пунктов либо не содержать их вообще, но любой существующий пункт документа должен быть привязан к документу. |
|
|
Документ |
Включает |
Приложение |
(1,1:0,N) |
Документ может включать одно или несколько приложений либо не включать их, но у любого приложения есть единственный документ, к которому оно привязано. |
|
|
Приложение |
Содержит |
Пункт |
(1,1:0,N) |
Приложение может содержать один или несколько пунктов либо не содержать их вообще, но любой существующий пункт приложения должен быть привязан к приложению. |
|
|
Пункт |
Регулирует |
Операция |
(1,N:0,M) |
Один пункт может регулировать одну или несколько операций либо не регулировать ни одной, но у любой операции должен быть хотя бы один регулирующий ее пункт. |
|
|
Пара пункт-операция |
Включает |
Пункт |
(1,1:0,N) |
Не любой пункт числится в паре, но любая пара должна включать один и только один пункт. |
|
|
Пара пункт-операция |
Включает |
Операция |
(1,1:0,N) |
Не любая операция числится в паре, но любая пара должна включать одну и только одну операцию. |
|
|
Обсуждение |
Создается для |
Пара пункт-операция |
(1,1:0,1) |
Для пары может быть создано максимум одно обсуждение, и всякое созданное обсуждение привязано к одной и только одной паре. |
|
|
Обсуждение |
Содержит |
Сообщение |
(1,1:1,N) |
Любое обсуждение содержит хотя бы одно сообщение, и любое сообщение принадлежит одному и только одному обсуждению. |
|
|
Обсуждение |
Содержит |
Решение |
(1,1:0,1) |
Любое обсуждение содержит только одно решение либо не содержит ни одного, и любое решение принадлежит одному и только одному обсуждению. |
|
|
Сообщение |
Является |
Решение |
(1,1:0,1) |
Любое сообщение может либо не являться решением проблемы, либо являться им, но решением может быть одно и только одно сообщение в обсуждении. |
|
|
Кейс |
Содержит |
Кейс |
(1,1:0,N) |
Любой кейс может содержать в себе один или несколько кейсов либо не содержать ни одного, но у любого вложенного кейса есть один и только один внешний по отношению к нему кейс. |
|
|
Кейс |
Содержит |
Операция |
(1,1:0,N) |
Кейс может содержать одну или несколько операций либо не содержать ни одной, но любая операция проходит в рамках одного и только одного кейса. |
Размещено на Allbest.ru
...Подобные документы
Выделение сущностей базы данных и связей между ними. Организация ее объектов. Логическая и физическая модель БД. Определение требований к информационной системе. Проектирование транзакций и пользовательского интерфейса. Разработка отчетов и запросов.
курсовая работа [2,4 M], добавлен 17.10.2014Анализ предметной области, сущностей и связей между ними. Составление требуемых запросов к базе данных. Анализ разрешений и запретов на операции с табличными данными для различных пользователей. Проектирование пользовательского интерфейса системы.
курсовая работа [2,2 M], добавлен 13.10.2022Анализ бизнес-процессов предприятия. Определение сущностей и связей между ними. Создание таблиц, запросов, отчетов и форм. Построение логической модели информационной системы. Разработка программного обеспечения. Инструкция по использованию базы данных.
дипломная работа [3,1 M], добавлен 16.08.2015Описание особенностей функционирования магазина. Проектирование системы: инфологическое моделирование и построение диаграммы потоков данных. Моделирование и программная реализация информационной системы. Проектирование пользовательского интерфейса.
курсовая работа [1,6 M], добавлен 18.02.2013Создание автоматизированной информационной системы, предназначенной для отслеживания текущих бизнес-процессов фирмы: построение диаграммы декомпозиции, выделение ключевых сущностей и установление связей между ними. Моделирование интерфейса системы.
курсовая работа [1,1 M], добавлен 23.05.2012Выявление сущностей и связей, атрибутов сущностей и назначение первичных ключей при разработке базы данных. Реляционная модель данных. Описание стадий жизненного цикла информационной системы: анализ, проектирование, реализация, внедрение, сопровождение.
курсовая работа [152,2 K], добавлен 11.05.2014Характеристика основных методов проектирования: в SADT, UML. Техническое задание на информационную систему. Создание модели в стандарте SADT (IDEF0). Декомпозиция родительской модели. Создание таблиц базы данных и связей между ними, бизнес логики.
курсовая работа [1,0 M], добавлен 14.11.2017Анализ предметной области. Разработка генетического алгоритма для оптимизации инвестиций. Спецификация требований и прецедентов. Проектирование пользовательского интерфейса информационной системы. Модели данных, используемые в системе и их взаимодействие.
дипломная работа [2,1 M], добавлен 24.08.2017Выявление классов-сущностей (диаграмма классов) и вариантов использований системы. Моделирование видов деятельности, взаимодействий, состояний, пользовательского интерфейса и архитектуры системы (диаграмм развертывания) на основе выявленных требований.
дипломная работа [2,1 M], добавлен 24.01.2016Создание информационной системы, содержащей сведения о продаже авиабилетов, работающей в локальной сети организации и имеющей клиентский веб-интерфейс. Моделирование бизнес процессов на языке UML. Проектирование структуры базы данных в MS Access.
курсовая работа [2,8 M], добавлен 20.07.2011Информационные технологии: современное состояние, роль в бизнесе и тенденции развития. Анализ информационной культуры предприятия. Разработка базы данных "Base" и программного обеспечения, обслуживающего базу. Описание интерфейса информационной системы.
дипломная работа [1,8 M], добавлен 02.11.2015Инфологическое моделирование предметной области. Построение диаграммы потоков данных. Обоснование выбора СУБД. Проектирование пользовательского интерфейса. Комплект поставки и порядок установки системы. Описание функционирования приложения и таблиц.
курсовая работа [3,2 M], добавлен 23.08.2014Разработка информационно-логической модели проектируемой информационной системы. Алгоритм функционирования информационной системы. Описание базы данных. Описание входной, промежуточной и выходной информации. Техническое и программное обеспечение.
реферат [28,1 K], добавлен 09.01.2009Анализ деятельности складского учета, внедрение информационных технологий в процесс работы склада. Создание информационной системы учета движения материалов на складе. Моделирование бизнес-процессов. Проектирование физической структуры базы данных.
курсовая работа [4,1 M], добавлен 22.06.2014Разработка структуры информационной системы с использованием СУБД MS Access. Моделирование бизнес-процессов с помощью IDEF0-диаграмм. Проектирование приложения в среде Delphi. Физическая реализация структуры базы данных. Создание интерфейса системы.
отчет по практике [3,4 M], добавлен 07.01.2015Возможности программы DBDesigner. Проектирование и реализация информационно-поисковой системы с помощью CASE-средства DBDesigner в среде Intranet. Этапы проектирования базы данных, установление соединения с базой данных на сервере, синхронизация.
лабораторная работа [1,5 M], добавлен 18.08.2009Выбор методологии проектирования информационной системы, сбор требований, их моделирование. Архитектурное проектирование, разработка пользовательского интерфейса и модулей. Реализация и аттестация информационной системы. Методика работы с приложением.
дипломная работа [2,9 M], добавлен 25.05.2014Схема принятого в компании бизнес-процесса планирования организационно-технических мероприятий. Проектирование пользовательского интерфейса и главного меню, основных форм входной и выходной информации, структуры базы данных информационной системы.
дипломная работа [2,4 M], добавлен 26.05.2012Исследование программных продуктов на туристическом рынке. Разработка информационной системы для менеджера туристической фирмы, отвечающей современному стандарту. Проектирование и структурирование базы данных. Моделирование бизнес-процессов в турфирме.
дипломная работа [4,0 M], добавлен 23.09.2013Требования, предъявляемые к базе данных "Публикации в СМИ". Выбор инструментальных средств для разработки. Проектирование базы данных: выявление необходимого набора сущностей, обоснование требуемого набора атрибутов, определение связей между объектами.
курсовая работа [1,2 M], добавлен 18.04.2014
