Разработка базы данных "Аптека"
Анализ предметной области, потребности различных категорий пользователей разрабатываемой базы данных. Описание концептуальной схемы и преобразование ее в реляционную БД. Создание ER-модели в среде ER-Win. Генерация файлов, разработка запросов в SQL.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | курсовая работа |
| Язык | русский |
| Дата добавления | 15.12.2013 |
| Размер файла | 786,4 K |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru/
Курсовой проект
по дисциплине: «Управление Данными»
на тему: «Разработка базы данных «Аптека»
Общие понятия и определения
Существует несколько моделей данных, полагаемых в основу информационных систем. Наиболее часто используются следующие три: иерархическая, сетевая и реляционная. Недавно появился четвертый тип: объектно-ориентированные системы управления базами данных (ООСУБД), которые соединяют традиционную технологию проектирования баз данных с объектной моделью. Реляционная модель весьма популярна, обладает рядом достоинств и может сочетаться с объектно-ориентированным подходом. Именно это сочетание присутствует в Microsoft Access, ведь Microsoft Access является реляционной СУБД. К тому же, многие существующие информационные системы построены на основе реляционной модели.
Чтобы понять, насколько проста и, вместе с тем, выразительна реляционная модель, необходимо изучить основные понятия и терминологию, относящиеся к ней.
Информационная система (information system) -- это приложение, предназначенное для хранения и обработки данных. Основой информационной системы является база данных с информацией, хранящейся в одной или нескольких связанных таблицах.
База данных (data base) представляет собой совокупность связанных таблиц (в предельном случае - одну таблицу), предназначенных для хранения определенной информации. Термином "база данных" часто называют приложение, использующее базу данных и обладающее интерфейсом просмотра и правки, а также средствами обработки хранящейся в базе данных информации. Однако такое приложение лучше называть информационной системой.
Базами данных являются файлы Microsoft Access, а также совокупность таблиц, объединенных в одно целое, хранящаяся в логических устройствах на SQL Server.
Реляционная модель (relational model). Основными элементами реляционной модели являются таблицы, представляющие сущности, в которых столбцы представляют атрибуты сущностей, а строки описывают экземпляры сущностей. Модель данных также подразумевает наличие операторов для генерации новых таблиц на основе существующих (называемых запросами (query)), именно таким способом' пользователи могут манипулировать данными и получать необходимую информацию.
Сущность (entity) --множество однотипных объектов, называемых экземплярами (instance). Каждый экземпляр характеризуется набором свойств, называемых атрибутами сущности (attribute). Каждый экземпляр индивидуален и отличается от всех остальных экземпляров во множестве.
Таблица (table) - множество ячеек с данными, образующих строки и столбцы прямоугольной таблицы. Таблица реализует сущность в понятии реляционной модели данных. Строки таблицы представляют экземпляры сущности и называются записями (records). Столбцы таблицы представляют атрибуты сущности и называются полями (fields).
Атрибут* (attribute) представляет собой определенное свойство (характеристику) данной сущности. Рекомендуется в качестве атрибутов выделять атомарные свойства сущности.
Поле таблицы (table field) - столбец в прямоугольной таблице. Поле таблицы реализует атрибут в понятии реляционной модели, при этом данные, хранятся в ячейках одного столбца, должны принадлежать одному домену. Домен определяет набор допустимых значений и операций над данными. То есть данные в ячейках одного столбца должны быть одного типа.
Первичный ключ - атрибут или группа атрибутов (тогда это составной первичный ключ), однозначно идентифицирующих каждый экземпляр сущности.
Одно из сильных ограничений реляционной модели состоит в том, что любая таблица имеет первичный ключ, т.е. не бывает одинаковых записей. Но модель одно, а жизнь другое, и даже Access позволяет уклониться от классической реляционной модели и создавать таблицы, не имеющего первичного ключа.
Ключевое поле (key field) -- поле, представляющее первичный ключ или являющееся частью составного первичного ключа.
Альтернативный ключ (alternative key) -- обычные поля или комбинации атрибутов, отличающиеся от первичного ключа сущности, но также претендующие на эту роль.
Связь (relationship) - это логическое отношение между сущностями, выражающее некоторое ограничение или правило. В реляционной модели вводится понятие реляционной связи (relation) -- это связь между записями, основанная на совпадении (или ином предикате) значений атрибутов, по которым устанавливается связь.
Основные объекты Access - таблицы, формы, запросы, отчеты, макросы, модули. Таблица является основой БД, в ней хранится вся информация.
Процесс создания отдельной таблицы в составе БД состоит из следующих этапов:
1) Создание структуры таблицы (задание имен и типов полей, задание ключевого поля);
2) Ввод данных в таблицу. Установить связи по общим полям методом ДД перетаскивая их от главной таблицы к связанной.
3) Сохранить схему данных, закрыть окно.
Анализ заданной предметной области, потребности различных категорий пользователей разрабатываемой БД
база данные реляционный запрос
Каждая база данных предназначена, прежде всего, для отображения данных по какой-то конкретной предметной области. Предметная область отображает сведения о каких-либо взаимосвязанных объектах. Каждый объект может быть охарактеризован вполне определенными свойствами, которые могут иметь сложную структуру, эти свойства могут отображаться количественно, то есть в виде цифрового значения или качественно (характер связи с другими объектами данной предметной области). Все эти свойства обычно в базу данных отображаются определением атрибуты объекта. Структура всех данных отображаемых базой данных, должна представлять собой самый главный элемент Б.Д., так как она отображает предметную область б.д. и все логические связи между данными и всю структуру свойств. Эта структура носит название концептуальная схема, общая схема или схема б. д.
Все данные входящие в Б.Д., хранятся в виде реальных физических данных о конкретных объектах (во внешней памяти на малых дисках).
Для более эффективной обработки данных исходную схему разбивают на несколько более мелких. Каждая часть охватывает некоторую смысловую область исходной схемы. Эти части должны обязательно иметь общие поля (с одинаковыми именами и данными), по которым осуществляется связь между отдельными подсхемами.
Разработка и описание концептуальной схемы и подсхем БД
Структуру данных необходимо описывать формальным образом. Описания логической и физической структур базы данных используются программными средствами управления базами данных при обработке требований пользователей на получение той информации, которую содержит база данных. Описание общей логической структуры базы данных называют схемой. Ее называют иногда общей моделью данных, концептуальной моделью или концептуальной схемой. Эти термины примерно равнозначны. Схема представляет собой таблицу типов используемых данных. Она содержит имена объектов и их атрибуты и определяет существующую между ними связь. Схема представляет собой структуру, в которой могут быть помещены значения элементов данных.
Изображения схем и записей можно представлять в виде расположенных одного за другим прямоугольников так, чтобы они определяли все значения каждого элемента данных.
Термин схема используется для определения полной таблицы всех типов элементов данных и типов записей, хранимых в базе данных. Термином подсхема определяют описание данных, которое использует прикладной программист. На основе одной схемы можно составить много различных подсхем.
Прикладной программист или конечный пользователь необязательно должен знать о схеме базы данных в целом, так как обычно она очень сложна. Иногда такая неосведомленность объясняется соображениями безопасности. Программист или пользователь должен иметь дело только с теми конкретными приложениями и записями, которые ему нужны.
Программы управления базой данных автоматически получают данные, соответствующие подсхеме, на основе данных, описанных в схеме, и передают их прикладной программе.
Ни схемы, ни подсхемы не отражают способов физического хранения данных. Можно показать, что для заданной логической структуры возможны различные формы физической организации данных. Итак, существует три различных вида описания данных:
1. Подсхема - таблица, описывающая ту часть данных, которая ориентирована на нужды одной или нескольких прикладных программ (организация файлов программиста). Реализуется в программах - запросах пользователей.
2. Глобальное описание логической структуры базы данных, или схема, - таблица, логически описывающая всю базу данных. Она отражает представление о данных администратора данных или тех системных аналитиков, которые работают со всей базой данных.
3. Описание физической организации базы данных - таблица физического расположения данных на носителях информации. Это представление о данных нужно системному программисту или системному разработчику, которые занимаются вопросами эффективности работы системы, расположения данных на носителях, их индексирования или поиска, а также вопросами использования методов сжатия данных.
Подсхему иногда называют частным представлением. Одна подсхема может обслуживать несколько прикладных программ и может быть определена отдельно от программ. Для определения подсхемы используется также термин подмодель.
Схема базы данных
Размещено на http://www.allbest.ru/
Схемы и подсхемы представляют собой диаграммы, изображающие типы элементов данных и связи между ними. Существуют различные способы изображения связей. Связи между двумя элементами данных могут быть двух типов.
Первый тип - связь “один к одному”, т. е. одной записи при этой связи в главной таблице должна соответствовать одна запись в подчиненной таблице. Такие БД используются довольно редко. С помощью таких связей выделяют отдельно редко используемую информацию.
Второй тип - связь “один ко многим”, наиболее часто используется это отношение. В данном случае одной записи главной таблице могут соответствовать несколько записей подчиненной таблицы. Различают две разновидности связи “один ко многим”. В первом случае предъявляются жесткие требования на обязательное наличие записей во вторичной таблице. Во втором случае такие требования отсутствуют.
Третий тип - связь “многие ко многим”. Многие реляционные СУБД эту связь не поддерживают. Для реализации таких связей таблицы связанные таким отношением следует преобразовать таким образом, чтобы в них были только связи 1:М, для этой цели вводятся дополнительные таблицы, которые отображают связи между отображаемыми таблицами связанными первоначально по типу М:М.
Подсхемы базы данных
Размещено на http://www.allbest.ru/
Размещено на http://www.allbest.ru/
Размещено на http://www.allbest.ru/
Преобразование схемы и подсхем в реляционную БД
В реляционной модели данных связывание таблиц осуществляется по принципу: главное - подчиненная. Для связи связанные таблицы должны иметь одинаковые столбцы, по которому осуществляется связь. Одна и та же таблица может быть главной по отношению к одной таблице и подчиненной по отношению к другой таблице.
Табличное представление данных имеет отношение только к логике данных, физически они могут быть размещены по другим принципам. Если в разных таблицах повторяется один и тот же атрибут (для связи таблиц) это не значит, что эти данные соберутся в физических записях.
В каждой таблице БД должны быть первичные ключи, которые представляют собой одно или несколько полей таблицы, однозначно идентифицирующих запись. Значение первичного ключа в таблице должно быть уникальным.
Иногда в качестве первичного ключа выбирают специально формируемое поле, которое называется индексом, он формируется автоматически, обычно представляет собой порядковый номер записи.
Первичный ключ позволяет осуществить доступ к конкретной записи (так как однозначно идентифицирует конкретную запись). Кроме того, первичный ключ используется для установления связи между таблицами.
Вторичные ключи так же используются для поиска данных, они устанавливаются для полей, для атрибутов, по которым часто производится поиск данных.
Значение вторичных ключей может быть не уникальным, и они не используются для однозначной идентификации конкретных записей. Они используются для поиска записей, удовлетворяющим конкретным условиям поиска записей по значению вторичного ключа.
Создать структуру таблицы «Лекарства»,
В окне БД CL закладку «Таблицы», CL кнопку «Создать»
CL пункт «Конструктор», CL кнопку «ОК»
В появившемся окне в столбце «Имя поля» ввести имена полей
В столбце «Тип данных» CL и выбрать нужный тип.
Задать ключевое поле - RCL на имени поля, в меню CL пункт «Ключевое поле» (в левой части строки появится изображение ключа)
Сохранить структуру таблицы - CL кнопку «Сохранить» на панели инструментов, ввести имя таблицы, CL кнопку «ОК»
Рисунок 1 - Создание таблицы «Лекарства» в режиме конструктора
Создать схему данных (указать связи)
CL кнопку Схема Данных
RCL, выбрать пункт «Показать таблицу», CL
выделить таблицы, CL кнопку. Добавить, CL Закрыть
Установить связи по общим полям методом ДД перетаскивая их от главной таблицы Предприятие к связанной.
Сохранить схему данных, закрыть окно.
Если необходимо отредактировать структуру таблицы - в окне БД выделить таблицу (CL), CL кнопку «Конструктор». В режиме отображения таблицы ширина столбцов меняется методом ДД на разделителе. Изменение порядка полей: выделить поле, CL на его заголовке, методом ДД перетащить в нужное место. Как скрыть столбец: выделить столбец, RCL, CL пункт «Скрыть столбцы». Как вернуть столбец: CL пункт главного меню Формат, пункт «Показать столбцы», CL, поставить галочки около тех столбцов, которые хотим видеть на экране.
Рисунок 2 - Схема данных
Нормализация реляционной БД
Нормализация - это такой способ описания данных, который:
понятен пользователю, не имеющему особых навыков в программировании;
позволяет подсоединять новые элементы данных, записи, связи без изменения существующих подсхем и, следовательно, прикладных программ;
допускает максимальную гибкость при обработке непредсказуемых или случайных запросов с терминалов.
Сам процесс нормализации проводится по следующей схеме:
1 шаг. Приведение таблиц к первой нормальной форме.
2 шаг. Приведение ко второй нормальной форме.
3 шаг. Приведение к третьей нормальной форме.
На практике обычно останавливаются на третьей нормальной форме, но в теории используются 4,5 и ряд других нормальных форм.
Заданную таблицу “Лекарства” нужно привести к 1, 2, 3 нормальной форме.
1-я Нормальная форма
1-я нормальная форма требует, чтобы каждое поле таблицы было неделимым и не содержало повторяющихся групп, но она не обеспечивает однозначной зависимости всех данных от первичного ключа.
Данная таблица полностью отвечает всем требованиям первой нормальной формы.
|
Наименование поставщика |
Групповая принадлежность |
Фирма |
Цена |
Страна/Производитель |
Международное Наименование |
Лекарственная форма |
2-я Нормальная форма
Эта форма требует, чтобы все поля таблицы зависели от первичного ключа. Те поля, которые зависят от первичного ключа (когда он сцеплен) должны быть выделены в отдельную таблицу.
Выделим первичный ключ - это поле “Наименование поставщика“. Оно в совокупности полностью определяют отдельную запись. Затем отдельно выделим все остальные таблицы. Заносим в эти таблицы свойства (атрибуты), которые относятся только к данному объекту.
Получаем следующую схему БД:
3-я Нормальная форма
Она требует, чтобы не имелось транзитивных зависимостей между не ключевыми полями. В таблицах 2-й нормальной формы нет транзитивных связей между полями. Следовательно, таблицы 2-й нормальной формы удовлетворяют и 3-й нормальной форме.
Создание ER-модели в среде ER-Win
Запустить ERWin и выбрать режим создания новой модели (Create a new model) или открытия существующей (Open an existing file).
Выбрать тип новой модели (New model type): логическая, физическая или модель, которая допускает преобразование одной в другую. Поскольку нужно спроектировать БД, следует выбрать логико-физическую модель.
Для построения ER-моделей используется инструментальная панель, состав которой зависит от выбранного стандарта представления моделей и типа модели: логическая или физическая. В данной работе рекомендуется использовать стандарт IDEF1X (Integration DEFinition for information modeling), в котором используются представленные в таблице обозначения.
Прежде всего, следует разместить диаграммы блоки сущностей. Выбрать блок сущности (Entity) на панели главного меню с помощью щелчка левой клавишей (рис. 3) и разместить в поле проектирования модели (переместить курсор и щелкнуть левой клавишей); в результате в поле проектирования будет размещен блок сущности с именем по умолчанию «E/1».
С помощью пункта главного меню «Model / Entities» или пункта всплывающего меню (по щелчку правой клавишей в поле блока сущности) «Entity Properties» («Свойства сущности») открыть окно для редактирования свойств сущности: название (Name), определение (Definition), примечания (Note, Note2, Note3), определяемые пользователем свойства (UDP - User definition properties) и др.
С помощью пункта «Object Font & Color» всплывающего меню установить параметры шрифта названия сущности и цвет заполнения поля блока.
При разработке ER-модели можно установить параметры шрифтов и цветовое оформление так, чтобы облегчить обзор и понимание модели.
Можно изменить установки шрифтов по умолчанию для всех объектов, для отдельных объектов или для групп выделенных объектов.
Когда добавляется объект в окно диаграммы, ERWin автоматически назначает шрифт по умолчанию. Для изменения параметров шрифтов, задаваемых по умолчанию, используется диалоговое окно «Default Fonts & Colors», которое вызывается из всплывающего меню (после щелчка правой клавишей на поле диаграммы).
Параметры шрифта можно установить с помощью главного меню, аналогично установкам, выполняемым в офисных программах.
С помощью пункта «Attributes …» всплывающего меню и соответствующих форм ввести данные об атрибутах выбранной сущности:
нажать кнопку «New»;
заполнить поля «Attribute Name» и «Column Name» (не обязательно) формы «New Attribute», предварительно выбрав тип данных для атрибута. Названия атрибутов можно задавать с помощью шрифтов типа «Кириллица» или «Латиница» (при этом следует учитывать возможности СУБД, которые будут использоваться для сопровождения БД; при использовании СУБД типа Access можно использовать имена сущностей и атрибутов на русском языке);
создать три сущности; например, «Студент», «Текущая успеваемость», «дисциплина»;
установить отношения «1: М» между сущностями «Студент» и «Текущая успеваемость» и «Дисциплина» и «Текущая успеваемость»
Рисунок 3 - Логическая модель данных
Рисунок 4 - Физическая модель данных
Генерация файлов БД
Для последующей генерации файла (файлов) БД создать с помощью заданной СУБД (в данном случае, Access) пустой файл БД (эта операция может быть выполнена до разработки ER-модели).
Выбрать сервер или СУБД, которая будет использоваться для работы с создаваемой БД через пункты главного меню «Database / Choose Database» и окно «Target server» («целевой сервер») с переключателями.
Рисунок 5 - окно «Target server».
С помощью меню «Database / Database Connection» открыть окно для ввода параметров связи ER-модели с БД следует ввести имя пользователя «admin», затем выбрать с помощью клавиши «Browse» и диалогового окна путь и имя файла БД, нажать клавишу «Connect» (будет выполнена связь ER-модели с файлом БД).
Рисунок 6. - Диалоговое окно «Access Connection»
С помощью меню «Tools / Forward Engineer/Schema Generation» открыть окно для проверки и изменения параметров генерации файлов БД
Рисунок 7. - Окно «Main Subject Area»
Нажать клавишу «Generate»; в окне будут выведены операторы, выполненные при генерации файлов БД.
Рисунок 8. - Диалоговое окно «Generate Database Schema»
В случае успешного окончания процесса генерации файлов БД («Schema Generation Complete» - «Генерация схемы выполнена») в ранее созданной БД будут находиться соответствующие таблицы и схема БД.
Рисунок 9. - Сгенерированная база данных
Заполнение таблиц
Рисунок 10. - Таблицы «Лекарства» и «Поставщики»
Рисунок 11. - Таблицы «Учёт лекарств»
Разработка запросов в SQL
Хранимые в БД данные обычно требуют множественной обработки. Для этого применяют запросы, которые представляет собой специальным образом описанные требования, определяющие состав производимых над БД операций по выборке, удалению, модификации данных.
Для подготовки запросов в различных СУБД чаще всего используются два основных языка:
Язык QBE (Query By Example) - язык запросов по образцу,
Язык SQL (Structured Query Language) - структурированный язык запросов.
По возможностям манипулирования данными в запросах указанные языки практически эквивалентны. Главное отличие заключается в способе формирования запросов: язык QBE предполагает ручное или визуальное формирование запроса, а SQL использует программирование запроса.
Теоретической основой языка QBE является реляционное исчисление с переменными - доменами. Язык позволяет задавать сложные запросы к БД заполнением запросной формы, имеющей вид таблицы, имена и названия полей которой совпадают с именами и названиями полей соответствующих исходных таблиц. Наглядными являются запросные формы в Access.
Язык SQL предназначен для выполнения операций над таблицами (создание, удаление, изменение структуры) и над данными таблиц (выборка, изменение, добавление, удаление), и некоторых сопутствующих операций. SQL является непроцедурным языком и не содержит операторов управления, организации подпрограмм, ввода-вывода и т.п. В связи с этим SQL обычно встраивается в СУБД (например, СУБД ACCESS, FoxPro СУБД.).
В современных СУБД с интерактивным интерфейсом можно создавать запросы, как было сказано, например, с помощью языка QBE. Однако применение SQL часто позволяет повысить эффективность обработки данных. Так, при подготовке запроса в ACCESS можно перейти из окна Конструктора запросов (формулирование запроса по образцу на языке QBE) в окно с эквивалентным оператором SQL. Новый запрос можно создать путем редактирования уже имеющегося запроса или программированием нового.
Язык SQL не обладает функциями полноценного языка программирования, а ориентирован на доступ к данным, поэтому его включают в состав средств разработки программ. В этом случае его называют встроенным SQL.
При построении запроса в окне конструктора система Access работает в фоновом режиме, записывая эквивалентные инструкции SQL. Для просмотра программы SQL в меню Вид выберите команду Режим SQL.
Перекрестный запрос «Кол-во оставшихся лекарств из кол-ва поставляемых»:
Запрос выдает данные о размерах кредитов выданных в разных банках различным клиентам.
Инструкция SELECT извлекает Код_клиента из таблицы «Банк_клиенты»
параметры FROM и GROUP BY являются запросами на выборку; они указывают, какие таблицы содержат поля, приведенные в инструкции SELECT.
Операция GROUP BY производит группировку всех полей списка SELECT.
Рисунок 12. - Перекрестный запрос
Рисунок 13. -Результат работы перекрестного запроса
Рисунок 14. - После создания таблицы
Создание отчетов
Отчет -- это гибкое и эффективное средство для организации данных при выводе на печать. С помощью отчета имеется возможность вывести необходимые сведения в том виде, в котором требуется.
Пользователь имеет возможность разработать отчет самостоятельно или создать отчет с помощью мастера. Мастер по разработке отчетов Microsoft Access выполняет всю рутинную работу и позволяет быстро разработать отчет. После вызова мастера выводятся диалоговые окна с приглашением ввести необходимые данные, и отчет создается на основании ответов пользователя. Мастер окажется полезным даже для опытных пользователей, так как позволяет быстро разработать макет, служащий основой создаваемого отчета. После этого можно переключиться в режим конструктора и внести изменения в стандартный макет.
Создание отчета с помощью мастера
В окне базы данных выберите вкладку Отчеты.
Нажмите кнопку Создать.
В диалоговом окне Новый отчет выберите нужного мастера. Описание действий, выполняемых мастером, выводится в левой половине диалогового окна.
Выберите имя таблицы или запроса, содержащих данные, по которым строится отчет.
Microsoft Access по умолчанию использует эту таблицу или запрос как базовый источник данных для отчета. Однако мастер позволяет изменить источник данных, а также выбрать поля из других таблиц или запросов.
Нажмите кнопку OK.
Если на шаге 3 выбран мастер отчетов, мастер диаграмм или мастер наклеек, выполняйте инструкции мастера, выводящиеся в диалоговом окне. Если выбран один из мастеров автоотчетов, отчет создается автоматически
Если созданный мастером отчет требует внесения изменений, сделайте это в режиме конструктора отчета.
Рис. 15. - Отчет «А дреса поставщиков».
Рис. 16. - Отчет «информация о лекарствах».
Создание пользовательского интерфейса
В Access 2000 можно создавать кнопочные формы, позволяющие обычному пользователю разрабатывать достаточно серьезные приложения, не прибегая при этом к программированию.
Между простой БД и приложением существует два отличия:
1) Задачи, которые в БД выполняются вручную (например, запуск запроса и распечатка результата), в приложении автоматизированы;
2) Для приложения разрабатывается специальный интерфейс, позволяющий сделать обслуживание БД максимально удобным для пользователя.
Разработка приложения начинается с анализа методики работы с БД: составляется список основных задач, которые должно решать создаваемое приложение и проводится анализ отношений между задачами.
После составления списка основных задач выделяют категории, на основании которых будут создаваться кнопки для главной кнопочной формы приложения. Кнопочные формы, по существу являются системой вложенных меню, представленных в виде кнопок.
Схематично последовательность действий при создании кнопок формы может быть следующей:
в режиме конструктора без указания источника данных создать формы, содержащие нужные кнопки;
в свойствах каждой кнопки определить подпись и событие «нажатой кнопки»;
событие - это действие, распознаваемое объектом (например, щелчок мышью, нажатие кнопки), для которого можно запрограммировать отклик. Событие возникает в результате действий пользователя или программы, или они могут быть вызваны системой;
для обработки события создать для каждой кнопки макрос в режиме построителя, который будет открывать нужный объект.
Заключение
В ходе выполнения данного курсового проекта были приобретены и закреплены навыки по созданию баз данных в среде Microsoft Access.
Была проанализирована заданная предметная область. Разработана концептуальная схема и подсхемы БД. Затем была произведена нормализация концептуальной схемы до второй и третьей нормальной формы (в моем курсовом проекте 2-я НФ является и 3-й НФ) и на их основе был создан проект базы данных в среде Access. В среде ER-Win была создана ER-модель БД.
Также осуществлена разработка SQL и QBE запросы. Созданы главная и вспомогательные формы, отчеты.
Список литературы
Михеева В.Д., Харитонова И.А. Microsoft Access 2000. - БХВ - Изд. «Санкт-Петербург», 2000
С.В. Симонович «Информатика. Базовый курс»
Размещено на Allbest.ru
Подобные документы
Проектирование базы данных для автоматизированной системы "Склад". Разработка концептуальной модели (ER-диаграмма). Преобразование в реляционную модель и ее нормализация. Разработка запросов к базе данных на языке SQL. Скрипт для создания базы данных.
курсовая работа [161,8 K], добавлен 07.10.2013Построение инфологической концептуальной модели предметной области. Структура базы данных Microsoft Office Access. Формы, запросы и отчеты. Создание форм, запросов и отчетов в базах данных. Схема данных физической и логической сущности в Erwin 4.0.
курсовая работа [5,1 M], добавлен 13.12.2011Разработка базы данных для компании, занимающейся авиагрузоперевозками, снабженной средствами идентификации пользователей. Описание ее предметной области и функций. Разработка интерфейса программы. Построение концептуальной и реляционной модели БД.
курсовая работа [2,1 M], добавлен 15.06.2014Анализ предметной области. Проектирование концептуальной модели. Разработка логической структуры базы данных. Выделение информационных объектов. Создание глобальной схемы связей. Поддержка целостности данных. Структура и назначение существующих форм.
курсовая работа [1,4 M], добавлен 23.09.2016Описание проектирования базы данных обувного магазина "Престиж". Преобразование концептуальной модели базы данных в реляционную модель; описание процесса создания таблиц, форм, отчетов, запросов. Разработка рекламы для магазина в виде HTML-страницы.
курсовая работа [3,9 M], добавлен 04.02.2013Осуществление анализа предметной области и определение модели базы данных. Реализация базы данных в среде Microsoft Access. Создание и исследование формы ввода информации, запросов с условиями выбора, диаграмм по результатам вычислений и отчетов.
курсовая работа [246,1 K], добавлен 19.10.2013Разработка базы данных с информацией о сотрудниках, товарах, со справочником типов товаров средствами системы управления базами данных MySQL с помощью SQL-запросов. Разработка инфологической модели предметной области. Структура таблиц, полей базы данных.
контрольная работа [648,7 K], добавлен 13.04.2012Создание базы данных для информационной системы "Грузоперевозки". Анализ предметной области, разработка концептуальной и логической модели базы данных, с использованием средства MS Micrоsоft SQL Server 2005, реализация физического проектирования базы.
курсовая работа [1,3 M], добавлен 01.07.2011Изучение реляционной модели данных. Выявление потребности задач в данных и определение состава и структуры информационных объектов. Построение концептуальной модели предметной области. Создание форм, запросов и отчетов с помощью конструктора запросов.
курсовая работа [6,3 M], добавлен 09.10.2021Назначение базы данных. Выполняемые базой данных функции, категории пользователей. Разработка концептуальной инфологической модели. Учет специфики предметной области. Вкладки "Организация", "Путевка", "Страна", "Сотрудник", "Турист", "ТуристМаршрут".
курсовая работа [3,1 M], добавлен 17.01.2013
