Инфологическая модель базы данных: рабочее место регистратуры поликлиники
Построение инфологической модели базы данных записей регистратуры поликлиники. Описание предметной области. Инфологическое моделирование. Инфологическое проектирование. Модель "сущность-связь". Моделирование связей между сущностями предметной области.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | курсовая работа |
| Язык | русский |
| Дата добавления | 27.02.2009 |
| Размер файла | 410,5 K |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
СОДЕРЖАНИЕ
- Введение 3
- 1. Системный анализ предметной области 5
- 1.1 Краткая характеристика предметной области 5
- 1.2 Описание предметной области 7
- 2. Инфологическое моделирование 11
- 2.1 Модель «сущность-связь» 11
- 2.2 Связи между сущностями инфологической модели 17
- Заключение 21
- Список литературы 23
- Введение
- В настоящее время практически во всех сферах человеческой деятельности используются базы данных. В том числе решение перечисленных задач позволит достигнуть цели, поставленной в курсовой работе, а именно, реализовать базу данных для обеспечения учета деятельности отдела закупок, что позволит следить за работой отдел, вести учет клиентов, заказчиков, поставщиков, видов товара более точно, с меньшими временными затратами, регулярным обновлением данных. Данная база данных может применяться в различных школах.
- Основными задачами, поставленными в ходе работы, являлись:
- § сбор, анализ и сортирование документов с целью описания предметной области;
- § отбор необходимых документов для создания базы данных;
- § выявление сущностей инфологической модели и моделирование связей между ними.
- В общем смысле термин «база данных» (БД) можно применить к любой совокупности связанной информации, объединенной вместе по определенному признаку, т.е. к набору структурированных данных (организованных определенным образом). При этом большинство БД использует табличный способ представления, где данные располагаются по строкам (которые называются записями) и столбцам (которые называются полями), все записи должны состоять из одинаковых полей и все данные одного поля должны иметь один тип.
- В настоящее время существует множество систем управления базами данных (СУБД) и других программ, выполняющих похожие функции, преобладающей является реляционная база данных. В компьютерном варианте в реляционной БД информация хранится, как правило, в нескольких таблицах-файлах, связанных между собой посредством одного или нескольких совпадающих в этих таблицах полей (в некоторых компьютерных системах все таблицы одной базы помещаются в один файл). Каждая строка в таблице реляционной БД должна быть уникальна (т.е. не должно быть одинаковых строк-записей). Такие уникальные столбцы (или уникальные группы столбцов), используемые, чтобы идентифицировать каждую строку и хранить все строки отдельно, называются первичными ключами таблицы.
- Таким образом, выбор реляционной БД открывает широкие возможности для пользователя, позволяя легко создать БД, удовлетворяющую требованиям организаций самого разного пользовательского профиля, выполняющих разные по значимости задачи и использующих неравнозначные объемы информации в своей деятельности.
1. Системный анализ предметной области
1.1 Краткая характеристика предметной области
В каждой поликлинике существует регистратура, которая занимается оформлением пациентов на прием к врачу. Оформлением пациента занимается работник регистратуры, которому необходимы следующие сведения о пациенте: фамилия, имя и отчество. Время приема каждого врача ограничено и составляет пять часов. Продолжительность приема одного пациента составляет двадцать минут. В течение рабочего дня врач имеет возможность принять пятнадцать пациентов.
При посещении поликлиники пациент должен оформиться в регистратуре на прием к врачу необходимой специализации на определенную дату и время. Талон на прием к врачу выдается только по наступлению даты приема.
Цель работы: автоматизировать процесс регистрации пациента на прием к врачу.
Назначение: сокращение ручного труда работника регистратуры при поиске информации о враче.
Разрабатываемая система является автоматизированной информационной системой «Регистратура» и решает задачу автоматизации основных операций в деятельности оператора отвечающего за оформление записей на прием к врачам.
При создании нового врача оператор вносит в БД всю информацию о нем, которая включает:
§ Фамилию врача;
§ Имя врача;
§ Отчество врача;
§ Специализация врача;
§ Номер кабинета;
§ Время приема.
Пользователь впоследствии может просмотреть список врачей, после чего он имеет возможность отредактировать данные выбранного врача либо совсем удалить его из системы.
При оформлении нового пациента работник регистратуры вносит в БД всю информацию о нем, которая включает:
§ Фамилия пациента;
§ Имя пациента;
§ Отчество пациента;
Работник регистратуры может просмотреть список пациентов, после чего он имеет возможность отредактировать данные выбранного пациента либо совсем удалить его из системы.
В дальнейшем оператор может просмотреть список пациентов оформленных на прием к врачам на текущую дату и выдать талон.
Для обработки данных в локальной сети предлагается клиент/серверная технология, позволяющая:
освободить клиентскую часть системы от громоздких вычислений;
выполнять параллельные вычисления на сервере;
эффективно организовать поддержку целостности БД;
эффективно организовать защиту БД.
Последовательности используются для автоматической генерации уникальных кодов при добавлении новых записей в таблицы, в режиме параллельного ввода данных с нескольких компьютеров, объединенных в локальную сеть.
Целостность данных и ссылочная целостность обеспечивается заложенными во время создания таблиц ограничениями на тип, размер и диапазон допустимых значений данных, а также посредством триггеров, обеспечивающих каскадное удаление связанных записей. Триггеры также обеспечивают регистрацию информации об изменении в БД.
1.2 Описание предметной области
В общем случае существуют два похода к выбору состава и структуры предметной области:
· Функциональный подход - он реализует принцип движения «от задач» и применяется тогда, когда заранее известны функции некоторой группы лиц и комплексов задач, для обслуживания информационных потребностей которых создается рассматриваемая СУБД. В этом случае мы можем четко выделить минимальный необходимый набор объектов предметной области, которые должны быть описаны.
· Предметный подход - когда информационные потребности будущих пользователей БД жестко не фиксируются. Они могут быть многоаспектными и весьма динамичными. Мы не может точно выделить минимальный набор объектов предметной области, которые необходимо описывать. В описание предметной области в этом случае включаются такие объекты и взаимосвязи, которые наиболее характерны и наиболее существенны для нее. БД, конструируемая при этом, называется предметной, то есть она может быть использована при решении множества разнообразных, заранее не определенных задач. Конструирование предметной БД в некотором смысле кажется гораздо более заманчивым, однако трудность всеобщего охвата предметной области с невозможностью конкретизации потребностей пользователей может привести к избыточно сложной схеме БД, которая для конкретных задач будет неэффективной.
Чаще всего на практике рекомендуется использовать некоторый компромиссный вариант, который, с одной стороны, ориентирован на конкретные задачи или функциональные потребности пользователей, а с другой стороны, учитывает возможность наращивания новых приложений.
Системный анализ должен заканчиваться подробным описанием информации об объектах предметной области, которая требуется для решения конкретных задач и которая должна храниться в БД, формулировкой конкретных задач, которые будут решаться с использованием данной БД с кратким описанием алгоритмов их решения, описанием выходных документов, которые должны генерироваться в системе, описанием входных документов, которые служат основанием для заполнения данными БД.
Базы данных (БД) составляют в настоящее время основу компьютерного обеспечения информационных процессов, входящих практически во все сферы человеческой деятельности.
Действительно, процессы обработки информации имеют общую природу и опираются на описание фрагментов реальности, выраженное в виде совокупности взаимосвязанных данных. Базы данных являются эффективным средством представления структур данных и манипулирования ими. Концепция баз данных предполагает использование интегрированных средств хранения информации, позволяющих обеспечить централизованное управление данными и обслуживание ими многих пользователей. При этом БД должна поддерживаться в среде ЭВМ единым программным обеспечением, называемым системой управления базами данных (СУБД). СУБД вместе с прикладными программами называют банком данных.
Одно из основных назначений СУБД - поддержка программными средствами представления, соответствующего реальности.
Предметной областью называется фрагмент реальности, который описывается или моделируется с помощью БД и ее приложений. В предметной области выделяются информационные объекты - идентифицируемые объекты реального мира, процессы, системы, понятия и т.д., сведения о которых хранятся в БД.
В мире существует множество систем управления базами данных. Несмотря на то, что они могут по-разному работать с разными объектами и предоставляют пользователю различные функции и средства, большинство СУБД опираются на единый устоявшийся комплекс основных понятий. В качестве такого объекта мы выберем СУБД Microsoft Access, входящую в пакет Microsoft Office.
Программное обеспечение для работы с базами данных используется на персональных компьютерах уже довольно давно. К сожалению, эти программы либо были элементарными диспетчерами хранения данных и не имели средств разработки приложений, либо были настолько сложны и трудны, что даже хорошо разбирающиеся в компьютерах люди избегали работать с ними до тех пор, пока не получали полных, ориентированных на пользователя приложений.
Microsoft Access - это функционально полная реляционная СУБД. В ней предусмотрены все необходимые вам средства для определения и обработки данных, а также для управления ими при работе с большими объемами информации. Что касается легкости использования, то Microsoft Access совершил здесь настоящий переворот, и многие для создания своих собственных баз данных и приложений обращаются именно к нему.
Система управления базами данных предоставляет вам возможность контролировать задание структуры и описание своих данных, работу с ними и организацию коллективного пользования этой информацией. СУБД также существенно увеличивает возможности и облегчает каталогизацию и ведение больших объемов хранящейся в многочисленных таблицах информации. СУБД включает в себя три основных типа функций: определение (задание структуры и описание) данных, обработка данных и управление данными. Все эти функциональные возможности в полной мере реализованы в Microsoft Access. В практике, как правило, необходимо решать и задачи с использованием электронных таблиц и текстовых процессоров. Например, после подсчета или анализа данных необходимо их представить в виде определенной формы или шаблоны. В итоге пользователю приходится комбинировать программные продукты для получения необходимого результата. В этом смысле все существенно упростят возможности, предоставляемые Microsoft Access.
Базы данных (БД) составляют в настоящее время основу компьютерного обеспечения информационных процессов, входящих практически во все сферы человеческой деятельности.
Действительно, процессы обработки информации имеют общую природу и опираются на описание фрагментов реальности, выраженное в виде совокупности взаимосвязанных данных. Базы данных являются эффективным средством представления структур данных и манипулирования ими. Концепция баз данных предполагает использование интегрированных средств хранения информации, позволяющих обеспечить централизованное управление данными и обслуживание ими многих пользователей. При этом БД должна поддерживаться в среде ЭВМ единым программным обеспечением, называемым системой управления базами данных (СУБД). СУБД вместе с прикладными программами называют банком данных.
2. Инфологическое моделирование
2.1 Модель «сущность-связь»
Процесс проектирования БД на основе принципов нормализации представляет собой последовательность переходов от неформального словесного описания информационной структуры предметной области к формализованному описанию объектов предметной области в терминах некоторой модели.
В общем случае можно выделить следующие этапы проектирования:
1. Системный анализ и словесное описание информационных объектов предметной области.
2. Проектирование инфологической модели предметной области - частично формализованное описание объектов предметной области в терминах некоторой семантической модели, например, в терминах ER-модели.
3. Даталогическое или логическое проектирование БД, то есть описание БД в терминах принятой даталогической модели данных.
4. Физическое проектирование БД, то есть выбор эффективного размещения БД на внешних носителях для обеспечения наиболее эффективной работы приложения.
Если мы учтем, что между вторым и третьим этапами необходимо принять решение, с использованием какой стандартной СУБД будет реализовываться наш проект, то условно процесс проектирования можно представить последовательностью выполнения пяти соответствующих этапов (см. схему 1).
Схема. 1. Этапы проектирования БД
С точки зрения проектирования БД в рамках системного анализа, необходимо осуществить первый этап, то есть провести подробное словесное описание объектов предметной области и реальных связей, которые присутствуют между описываемыми объектами. Желательно, чтобы данное описание позволяло корректно определить все взаимосвязи между объектами предметной области.
Системный анализ должен заканчиваться подробным описанием информации об объектах предметной области, которая требуется для решения конкретных задач и которая должна храниться в БД, формулировкой конкретных задач, которые будут решаться с использованием данной БД с кратким описанием алгоритмов их решения, описанием выходных документов, которые должны генерироваться в системе, описанием входных документов, которые служат основанием для заполнения данными БД.
Инфологическая модель применяется на втором этапе проектирования БД, то есть после словесного описания предметной области. Процесс проектирования длительный и требует обсуждений с заказчиком и со специалистами в предметной области. Наконец, при разработке серьезных корпоративных информационных систем проект базы данных является тем фундаментом, на котором строится вся система в целом, и вопрос о возможном кредитовании часто решается экспертами банка на основании именно грамотно сделанного инфологического проекта БД. Следовательно, инфологическая модель должна включать такое формализованное описание предметной области, которое легко будет «читаться» не только специалистами по базам данных. И это описание должно быть настолько емким, чтобы можно было оценить глубину и корректность проработки проекта БД, и конечно, оно не должно быть привязано к конкретной СУБД. Выбор СУБД - это отдельная задача, для корректного ее решения необходимо иметь проект, который не привязан ни к какой конкретной СУБД.
Цель инфологического моделирования - обеспечение наиболее естественных для человека способов сбора и представления той информации, которую предполагается хранить в создаваемой базе данных. Поэтому инфологическую модель данных пытаются строить по аналогии с естественным языком (последний не может быть использован в чистом виде из-за сложности компьютерной обработки текстов и неоднозначности любого естественного языка). Основными конструктивными элементами инфологических моделей являются сущности, связи между ними и их свойства (атрибуты).
Сущность - любой различимый объект (объект, который мы можем отличить от другого), информацию о котором необходимо хранить в базе данных. Сущностями могут быть люди, места, самолеты, рейсы, вкус, цвет и т.д. Необходимо различать такие понятия, как тип сущности и экземпляр сущности. Понятие тип сущности относится к набору однородных личностей, предметов, событий или идей, выступающих как целое. Экземпляр сущности относится к конкретной вещи в наборе.
Сущность имеет имя, уникальное в пределах модели. При этом имя сущности - это имя типа, а не конкретного экземпляра.
Сущности подразделяются на сильные и слабые. Сущность является слабой, если ее существование зависит от другой сущности - сильной по отношению к ней. Например, сущность «Подчиненный» является слабой по отношению к сущности «Сотрудник»: если будет удалена запись, соответствующая некоторому сотруднику, имеющему подчиненных, то сведения о подчинении также должны быть удалены.
Сущность может быть расщеплена на два или более взаимоисключающих подтипов, каждый из которых включает общие атрибуты и/или связи. Эти общие атрибуты и/или связи явно определяются один раз на более высоком уровне. В подтипах могут определяться собственные атрибуты и/или связи. В принципе выделение подтипов может продолжаться на более низких уровнях, но в большинстве случаев оказывается достаточно двух-трех уровней.
Сущность, на основе которой определяются подтипы, называется супертипом. Подтипы должны образовывать полное множество, то есть любой экземпляр супертипа должен относиться к некоторому подтипу. Иногда для полноты множества надо определять дополнительный подтип, например, «Прочие».
Атрибут - поименованная характеристика сущности. Его наименование должно быть уникальным для конкретного типа сущности, но может быть одинаковым для различного типа сущностей. Атрибуты используются для определения того, какая информация должна быть собрана о сущности.
Абсолютное различие между типами сущностей и атрибутами отсутствует. Атрибут является таковым только в связи с типом сущности. В другом контексте атрибут может выступать как самостоятельная сущность.
Ключ - минимальный набор атрибутов, по значениям которых можно однозначно найти требуемый экземпляр сущности. Минимальность означает, что исключение из набора любого атрибута не позволяет идентифицировать сущность по оставшимся.
Связь - ассоциирование двух или более сущностей. Если бы назначением базы данных было только хранение отдельных, не связанных между собой данных, то ее структура могла бы быть очень простой. Однако одно из основных требований к организации базы данных - это обеспечение возможности отыскания одних сущностей по значениям других, для чего необходимо установить между ними определенные связи. А так как в реальных базах данных нередко содержатся сотни или даже тысячи сущностей, то теоретически между ними может быть установлено более миллиона связей. Наличие такого множества связей и определяет сложность инфологических моделей.
Справочник врачей хранится в таблице VRACH, структура и правила поддержки целостности данных которой приводятся в таблицах.
Таблица 1
Таблица VRACH
|
Название |
Тип данных |
Размер |
Ограничения |
Назначение |
|
|
CODE_VRACH |
Integer |
Primary Key |
Код врача |
||
|
FAM_VRACH |
Char |
25 |
Not NULL |
Фамилия врача |
|
|
IMYA_VRACH |
Char |
25 |
Not NULL |
Имя врача |
|
|
OTCH_VRACH |
Char |
25 |
Отчество врача |
||
|
CODE_DOLGN |
Integer |
Код специализации |
|||
|
CODE_KABINET |
Integer |
Код занимаемого кабинета |
|||
|
CODE_TIME |
Integer |
Код времени приема |
Справочник пациентов хранится в таблице STUD, структура и правила поддержки целостности данных которой приводятся в табл. 2.
Таблица 2
Таблица STUD
|
Название |
Тип данных |
Размер |
Ограничения |
Назначение |
|
|
CODE_STUD |
Integer |
Primary Key |
Код пациента |
||
|
FAM_STUD |
Char |
25 |
Not NULL |
Фамилия пациента |
|
|
IMYA_STUD |
Char |
25 |
Имя пациента |
||
|
OTCH_STUD |
Char |
25 |
Отчество пациента |
||
|
CODE_VRACH |
Integer |
Not NULL |
Код врача |
||
|
CODE_DATE |
Integer |
Код даты приема |
Данные о специализации врачей хранятся в таблице DOLGN, структура и правила поддержки целостности данных которой приводятся в табл. 3.
Таблица 3
Таблица DOLGN
|
Название |
Тип данных |
Размер |
Ограничения |
Назначение |
|
|
CODE_DOLGN |
Integer |
Primary Key |
Код специализации |
||
|
DOLGN |
Char |
25 |
Название специализации |
Для хранения данных о номерах кабинетов заполняется таблица KABINET, структура и правила поддержки целостности данных которой приводятся в табл. 4.
Таблица 4
Таблица KABINET
|
Название |
Тип данных |
Размер |
Ограничения |
Назначение |
|
|
CODE_KABINET |
Integer |
Primary key |
Код кабинета |
||
|
KABINET |
Integer |
Номер кабинета |
|||
|
SUMMATOR |
Integer |
Not NULL |
Количество врачей в кабинете |
||
|
CODE_DOLGN |
Integer |
Код специализации |
|||
|
POLOJENIE |
Char |
25 |
Положение кабинета( свободен или занят) |
Для хранении данных о времени приема врача заполняется таблица TIME, структура и правила поддержки целостности данных которой приводятся в табл. 5.
Таблица 5
Таблица TIME
|
Название |
Тип данных |
Размер |
Ограничения |
Назначение |
|
|
CODE_TIME |
Integer |
Primary key |
Код времени приема |
||
|
TIME |
Char |
25 |
Время приема |
Для хранения информации о дате приема к врачу создана таблица DATE_PRIEM , структура и правила поддержки целостности данных которой приводятся в табл. 6.
Таблица 6
Таблица DATE_PRIEM
|
Название |
Тип данных |
Размер |
Ограничения |
Назначение |
|
|
CODE_DATE |
Integer |
Primary Key |
Код даты |
||
|
DATE_PR |
Date |
Дата приема |
|||
|
CODE_VRACH |
Integer |
Not NULL |
Код врача |
||
|
SUMMATOR |
Integer |
Количество пациентов |
2.2 Связи между сущностями инфологической модели
Разработку информационного обеспечения АРМ проведем на базе системы управления базами данных (СУБД) Access XP из состава выбранного интегрированного пакета Microsoft Office XP.
СУБД Access предназначена для разработки баз данных реляционного типа для локального их использования на персональных компьютерах и для работы с этими базами.
При проектировании базы данных, в первую очередь, необходимо определить, что именно нужно хранить.
Данная СУБД была выбрана по следующим причинам:
§ простота средств реализации,
§ легкость освоения инструментарием разработчика (VBA),
§ наглядность визуализации информации.
Также «Microsoft Access» предоставляет большое количество внутренних средств по оптимизации работы проектируемого приложения. К ним относятся:
§ загрузка модулей по требованию;
§ оптимизация дерева вызовов;
§ использование файлов MDE;
§ автоматическая поддержка компилированного состояния;
§ использование библиотек Windows API;
§ индивидуальная настройка системы;
§ эффективное использование индексов;
§ встроенный оптимизатор запросов.
Система управления базами данных (СУБД) обычно поддерживает 4 основных типа отношений между таблицами:
- один-к-одному (одной записи в первой таблице соответствует одна запись во второй);
- один-ко-многим (одной записи в первой таблице соответствует много записей во второй);
- много-к-одному (многим записям в первой таблице соответствует одна запись во второй);
- много-ко-многим (одной записи в первой таблице соответствует много запией во второй и одной записи во второй таблице соответствует много записей в первой).
Инфологическая модель применяется после словесного описания предметной области.
Между сущностями могут быть установлены связи - бинарные ассоциации, показывающие, каким образом сущности соотносятся или взаимодействуют между собой. Связь может существовать между двумя разными сущностями или между сущностью и ей же самой (рекурсивная связь). Она показывает, как связаны экземпляры сущностей между собой. Если связь устанавливается между двумя сущностями, то она определяет взаимосвязь между экземплярами одной и другой сущности
Связи делятся на три типа по множественности: один-ко-одному (1:1), один-ко-многим (1:М), многие-ко-многим (М:М).
Связь один-ко-одному означает, что экземпляр одной сущности связан только с одним экземпляром другой сущности.
Связь один-ко-многим (1:М) означает, что один экземпляр сущности, расположенный слева по связи, может быть связан с несколькими экземплярами сущности, расположенными справа по связи.
Связь «многие-ко-многим (М:М) означает, что несколько экземпляров первой сущности могут быть связаны с несколькими экземплярами второй сущности, и наоборот. Между двумя сущностями может быть задано сколько угодно связей с разными смысловыми нагрузками.
Связь любого из этих типов может быть обязательной, если в данной связи должен участвовать каждый экземпляр сущности, необязательной - если не каждый экземпляр сущности должен участвовать в данной связи. При этом связь может быть обязательной с одной стороны и необязательной с другой стороны.
Проведем инфологическое проектирование базы данных технологического процесса.
Заключение
Процесс проектирования БД на основе принципов нормализации представляет собой последовательность переходов от неформального словесного описания информационной структуры предметной области к формализованному описанию объектов предметной области в терминах некоторой модели.
Инфологическая модель применяется на втором этапе проектирования БД, то есть после словесного описания предметной области. Процесс проектирования длительный и требует обсуждений с заказчиком и со специалистами в предметной области. Наконец, при разработке серьезных корпоративных информационных систем проект базы данных является тем фундаментом, на котором строится вся система в целом, и вопрос о возможном кредитовании часто решается экспертами банка на основании именно грамотно сделанного инфологического проекта БД. Следовательно, инфологическая модель должна включать такое формализованное описание предметной области, которое легко будет «читаться» не только специалистами по базам данных. И это описание должно быть настолько емким, чтобы можно было оценить глубину и корректность проработки проекта БД, и конечно, оно не должно быть привязано к конкретной СУБД. Выбор СУБД - это отдельная задача, для корректного ее решения необходимо иметь проект, который не привязан ни к какой конкретной СУБД.
Инфологическое проектирование прежде всего связано с попыткой представления семантики предметной области в модели БД. Реляционная модель данных в силу своей простоты и лаконичности не позволяет отобразить семантику, то есть смысл предметной области.
Главным результатом проведенной этой курсовой работы является создание функционирующей БД, а также освещению методов построения форм и отчетов на примере построения программы ведения электронной документации кадрового отдела.
В результате анализа базы данных было выполнено:
- выявлена сущность инфологической модели и моделирование связей между ними;
- построение набора таблиц базы данных и нормализация базы;
- описание внешних моделей в терминах выбранной СУБД;
- реализация базы данных и организация запросов в выбранной СУБД;
- реализация программного интерфейса к базе данных.
Программный интерфейс максимально облегчает работу по обращению с базой данных (вплоть до выбора из предложенного числа вариантов). Даже обращение к базе данных со сложными запросами осуществляется в таком виде, что структура возвращаемых данных видна еще до его исполнения. СУБД самостоятельно тестирует находящиеся в базе данных записи и производит приведение базы данных к целостному состоянию, устраняя возможные ошибки.
Список литературы
1. Бекаревич Ю.Б., Пушкина Н.В. Самоучитель Microsoft Access 2002. - СПб.: БХВ-СПб., 2003. - 720 с.
2. Виноградова И.А., Грибова Е.А., Зубков В.Г. Практикум на ЭВМ. MS Access: Учебное пособие для студентов заочной (дистанционной) формы обучения. - М.: ГИНФО, 2000. - 124 с.
3. Голицина О.Л., Максимов Н.В., Попов И.И. Базы данных: Учебное пособие. - М.: ФОРУМ: ИНФРА-М, 2003. - 352 с.
4. Информатика. Базовый курс. /Под ред. С.В.Симоновича. - СПб.: Питер, 1999. - 640 с.
5. Карпова Т.С. Базы данных: модели, разработка, реализация. - СПб.: Питер, 2002. - 304 с.
6. Петров В.Н. Информационные системы. - СПб.: Питер, 2003. - 688 с.
7. Тихомиров Ю.В. MS SQL Server 2000: разработка приложений. - СПб.: БХВ-Петербург, 2000. - 368 с.
Подобные документы
Анализ и описание предметной области. Функции программы "Прокат", которая работает на одном или нескольких компьютерах операторов пункта проката. Инфологическое моделирование, типы и экземпляры сущностей. Связи между сущностями и модель "сущность-связь".
курсовая работа [305,2 K], добавлен 27.02.2009Системный анализ и краткая характеристика предметной области. Функции для работы с буферизованной таблицей. Описание предметной области и инфологическое моделирование. Модель "сущность-связь". Проектирование баз данных на основе принципов нормализации.
курсовая работа [112,9 K], добавлен 27.02.2009Анализ и описание предметной области. Программа "Абитуриент АГПК" как основа реляционной модели управления БД. Инфологическое моделирование и проектирование. Связи между сущностями. Создание подсистемы, отвечающей за обработку личных дел абитуриентов.
курсовая работа [78,4 K], добавлен 27.02.2009Построение инфологической модели тестовой программы по электронному учебнику для проверки знаний учащихся. Инфологическое моделирование и семантическое представление предмета в базе данных. Модель "сущность-связь" и связи между выявленными сущностями.
курсовая работа [63,0 K], добавлен 27.02.2009Исследование основных требований, предъявляемых к инфологической модели. Методы представления предметной области. Инфологическое описание предметной области. Модель "сущность-связь". Типы бинарных связей. Отражение объектов в информационной системе.
презентация [397,3 K], добавлен 29.09.2013Процесс проектирования с использованием принципов нормализации. Определение сущности "Группа" в модели ER. Моделирование связи между сущностями "Студент" и "Группа" и предметной области "Учебный процесс". Применение инфологической модели в проекте.
курсовая работа [33,8 K], добавлен 27.02.2009Характеристика сущностей инфологической модели и проектирование модели базы данных технологического процесса. Описание предметной области и основы инфологического моделирования. Особенности проектирования и обеспечение выполнения объявленных функций.
курсовая работа [22,5 K], добавлен 27.02.2009Проектирование базы данных для работников регистратуры поликлиники. В БД должны храниться сведения о больных: ФИО, адрес, диагноз, дата заболевания; сведения о врачах: кабинет, участок, время приема; описание болезней: диагноз, симптомы, лекарство.
курсовая работа [1,0 M], добавлен 23.04.2011Процесс проектирования базы данных на основе принципов нормализации. Применение инфологической модели на втором этапе проектирования. Семантика предметной области в модели базы данных. Оформление, выдача и обмен паспорта. Модель "сущность-связь".
курсовая работа [67,9 K], добавлен 27.02.2009Операции обработки, преобразования, упорядочения отношений базы данных для оптимизации её ответов на запросы пользователя. Инфологическое моделирование предметной области. Анкеты описания сущностей, атрибутов и связей. SQL-скрипт схемы базы данных.
курсовая работа [1,4 M], добавлен 03.03.2015
