ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 29.04.2024
Просмотров: 13
Скачиваний: 0
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
Изменение концептуальной модели в логическую модель, как правило, осуществляется по формальным правилам. Данный этап может быть в значительной степени автоматизирован.
На этапе логического проектирования учитывается специфика конкретной модели данных, а может не учитываться специфика конкретной СУБД.
Физическое проектирование - создание схемы базы данных на конкретной СУБД. Специфика конкретной СУБД может включать в себя ограничения на именование объектов базы данных, ограничения на поддерживаемые типы данных и т. Кроме того, специфика конкретной СУБД при физическом проектировании включает выбор решений, объединенных с физической средой хранения данных (выбор методов управления дисковой памятью, разделение БД по файлам и устройствам, методов доступа к данным), создание индексов и т.
2.3. Требования к приложению
Процесс проектирования базы данных охватывает несколько ключевых областей. Проектировать объекты базы данных (таблицы, представления, индексы, триггеры, хранимые процедуры, функции, пакеты) для представления данных предметной области в базе данных.
Разработка интерфейсов для взаимодействия с базой данных (формы, отчеты и т. д.), т. е. разработка приложений, которые будут сохранять данные в базе данных и реализовывать отношения ответов для этих данных.
Проектирование базы данных для конкретного компьютера или вычислительной среды (архитектура клиент-сервер, параллельная архитектура, распределенная вычислительная среда).
Проектирование баз данных для нужд системы (интеллектуальный анализ данных, OLAP, OLTP и т. д.).
Приложения базы данных разрабатываются с учетом физической схемы базы данных, а не отдельно! Компьютерная среда часто используется в качестве исходных данных для проектирования, но иногда проектирование должно выполняться с возможностью переноса на другую аппаратную платформу или технологию в будущем.
2.4. Основные модели данных
Модель данных (DM) — это набор правил создания структур данных в базе данных, действий над ними, а также ограничений целостности, определяющих отношения данных и значения, разрешающих, предписывающих изменять их.
Базы данных создаются для достижения определенных исследовательских целей, и в зависимости от изменения или расширения целей модель базы данных может измениться. Развитие теории и практики проектирования и эксплуатации баз данных сопровождается углубленной разработкой моделей данных. Первой DM, использованной для построения концептуальных карт, была иерархическая модель. Затем появились сетевые модели. Затем появились ER-модели, а в результате их развития — реляционные и постреляционные модели. Каждая из этих моделей имеет свои преимущества и недостатки.
Свойство проявляется, когда логика представления предметной области полностью описывается выбранной моделью данных.
Глава 3. Проектирование и разработка базы данных по регистрации и учету юридических и физических лиц в налоговых органах РФ.
3.1. Описание предметной области
Муниципальная налоговая инспекция создает базу данных юридических лиц с указанием всех их реквизитов и видов деятельности, причем у юридического лица может быть несколько видов деятельности. Должна быть возможность просматривать как список юридических лиц по каждому виду деятельности, так и перечень видов деятельности по каждому юридическому лицу, а также обеспечить формирование запросов-выборок по различным условиям. Юридические лица могут иметь несколько фирм.
3.2. Анализ реквизитного состава и установление функциональных зависимостей между реквизитами
Анализ реквизитного состава проведем на основании описанной предметной области.
3.2.1. Определение функциональных зависимостей между реквизитами в соответствии с требованиями первой нормальной формы(1НФ)
Проведем анализ реквизитного состава и определим функциональные зависимости. В рамках решаемой задачи все реквизиты содержат простые (атомарные) данные, следовательно, отношения находятся в 1НФ форме.
Анализ функциональных зависимостей показал, так как одно юридическое лицо может занимать несколько видов деятельности, а вид деятельности может иметь нескольких юридических лиц, то нужно ввести добавочные коды. Ключевыми полями будут Код юридического лица- КодЮридическогоЛица, Код вида деятельности- КодВидаДеятельности.
3.2.2. Определение функциональных зависимостей между реквизитами в соответствии с требованиями второй нормальной формы(2НФ)
По определению отношение находится во второй нормальной форме тогда, когда оно находится в первой нормальной форме и не содержит неполных функциональных зависимостей не первичных атрибутов от атрибутов первичного ключа. Во всех отношениях ключевые поля простые, следовательно, отношения автоматически находятся во второй нормальной форме.
3.2.3. Определение функциональных зависимостей между реквизитами в соответствии с требованиями третьей нормальной формы(3НФ)
По определению отношение находится в третьей нормальной форме тогда, когда оно находится во второй нормальной форме и не содержит транзитивных зависимостей не первичных атрибутов от атрибутов первичного ключа. Для представления отношений в 3НФ функциональные зависимости в них должны выглядеть так как представлено в Таблице 1.2.
3.3. Образование информационных объектов установим для каждого описательного реквизита ключевые реквизиты.
В таблицу не включаются повторы соответствия описательных и ключевых реквизитов. Образование информационных объектов происходит на основании объединения реквизитов.
Сгруппируем описательные реквизиты, одинаково зависимые от ключевых реквизитов, и объединим их с ключевыми в один информационный объект.
Сгруппируем описательные реквизиты, одинаково зависимые от ключевых реквизитов, и объединим их с ключевыми в один информационный объект. Связи между информационными объектами осуществляется через внешние ключи. Информационные объекты сключами связи и типом отношения.
3.4. Создание информационно-логической модели предметной области в каноническом виде
Информационно-логическая модель настоящей области в каноническом виде демонстрирует иерархию подчинения информационных объектов по уровням, характеризуемым количеством связей в наиболее длинном пути через вершины модели к объекту. На уровне 0 распределяются информационные объекты, что не содержат внешних ключей. На уровне 1 находятся информационные объекты, что содержат только внешние ключи объектов, располагающиеся на уровне 0. На уровне 2 размещаются информационные объекты, которые содержат внешние ключи объектов, расположенных на уровне 0, 1.
3.5. Создание даталогической модели реляционной базы данных
Даталогическая модель реляционной базы данных определяется совокупностью логически с объединённых реляционных таблиц. Каждая таблица имеет структуру, определяемую реквизитным составом информационного объекта информационно-логической модели. Логические связи между таблицами соответствуют структурным связям между информационными объектами и устанавливаются на уровне ключей связи (внешним ключом подчиненной таблицы и первичным ключом главной таблицы). налоговый инспекция база данные Логическая структура реляционной базы данных (схема данных), построенная на основе информационно-логической модели предметной области. Логическая структура реляционных таблиц зависит от СУБД, с помощью которой будет разрабатываться база данных.
Разные СУБД поддерживают разные типы данных, имеют разные ограничения на длину имени поля и символы, используемые в имени, свойства поля могут быть разными и т.д. В таблицах представлена логическая структура реляционных таблиц базы данных MS Access.
3.6. Программные разработки
Для реализации исследованной информационной системы подобрана СУБД MS Access, что является реляционной СУБД функционирующей в среде Windows. Как и иные продукты этой категории, она предназначена для хранения и поиска данных, представления информации в комфортном виде и автоматизации часто повторяющихся операций. С помощью Access можно проектировать простые и удобные формы ввода данных, а также реализовывать обработку данных и выдачу сложных отчетов. В системе Access предусмотрены: контекстно-зависимая справка; простые в применении профессионалы и конструкторы; импортирование, экспортирование и связывание внешних файлов; формы и отчеты, конструируемые по принципу WYSIWYG (What You See Is What You Get - что видишь, то и получишь); многотабличные запросы и отношения; разработка графиков и диаграмм; и многое другое. СУБД MS Access ориентирована на работу с объектами, к которым относятся: таблицы, запросы, формы, отчеты, страницы доступа к данным, макросы и модули. В Access все объекты находятся в одном файле. Документ баз данных имеет оформленное в Windows расширение. Таблица - главный структурный элемент системы управления реляционной базы данных. В Microsoft Access таблицей называется объект, в котором данные хранятся в формате записей (строк) полей (столбцов). Данные в отдельной таблице используются в определенной категории, например, сведения о сотрудниках или заказах. Запросы - этотребования на разбор данных, хранящиеся в таблицах, или требование на выполнение поставленных действий с данными. Запрос разрешает создать набор записей из данных, находящихся в различных таблицах, и использовать этот набор как источник данных для формы или отчета. Формы - это объект базы данных Microsoft Access, в котором разработчик раставляет элементы управления, принимающие действия пользователей или служащих для ввода, отображения или изменения данных в полях. Отчет - это объект базы данных Microsoft Access, нужный для отображения данных, созданных и отформатированных в соответствии со спецификациями пользователя. С помощью отчетов оформляются коммерческие сводки, различные списки. Макрос - макрокоманда или набор макрокоманд, используемый для автоматического выполнения определенных операций. Модуль - это описания, инструкций и процедур, сохраненная под общим именем. В Microsoft Access имеются модули двух типов: стандартный модуль и модуль класса. Модули форм и отчетов являются модулями классов и содержат программы, являющиеся локальными для этих объектов. Процедуры обычного модуля, если они явно необъявлены локально в содержащем их модуле, распознаются и могут вызываться процедурами других модулей той же базы данных или базы данных, на которую ссылаются. Создание новой базы данных выполняется по ее структуре, полученной в результате проектирования.
3.6.1. Разработка структур БД
Создание новой базы данных производится в соответствии с ее структурой, полученной проектом. Реляционная модель данных представляет собой комплекс взаимосвязанных таблиц. Таким образом, таблицы являются основным объектом реляционной базы данных и предназначены для хранения данных в домене. Создание таблицы в базе данных — это двухэтапный процесс. Сначала описывается структура таблиц и устанавливаются связи между ними. На втором этапе таблицы заполняются данными.
Схема данных определяет логическую структуру базы данных. Он устанавливает отношения между таблицами и поддерживает целостность связанных данных. Схема данных позволяет упростить проектирование многотабличных форм, запросов и отчетов при построении схемы, СУБД MS Access автоматически определяет тип связи между таблицами. Если поле, по которому устанавливается связь, является уникальным ключом, как в главной таблице, так и в подчиненной, Access устанавливает связь 1:1. Если поле связи является уникальным ключом в главной таблице, а в подчиненной таблице является неключевым или входит в состав составного первичного ключа, Access устанавливает связь 1:М от главной таблицы к подчиненной.
Обеспечение целостности означает выполнение для взаимосвязанных таблиц следующих условий:
a) в подчиненную таблицу не может быть добавлена запись с несуществующим в главной таблице значением ключа связи;
b) в главной таблице нельзя удалить запись, если не удалены связанные с ней записи в подчиненной таблице в главной таблице нельзя изменить значение ключа связи, если в записях подчиненной таблицы используется значение ключа связи.
При попытке нарушения этих условий в операциях обновления или удаления данных СУБД отменяет выполнение этих операций.
3.6.2 Ввод данных
Форма — это настраиваемое интерактивное окно, дозволяющее организовать интуитивно простой и удобный пользовательский интерфейс для работы с данными. Назначение форм: внесение записей в таблицу; тип записей в таблице: добавлять и удалять записи, изменять значения в полях; представление и анализ информации; Сгенерированная база данных может иметь четыре формы ввода данных и одну форму основного узла.
Формы для ввода Авто, Водитель, Авто-водитель, День созданы на основе одноименных таблиц. Для отображения или выбора значений полей, содержащих коды наружных ключей использован мастер подстановки. Главная форма связывает все объекты между собой, обеспечивая удобство работы с БД.
